Core Web Vitals 2026 三层优化策略封面图

GSC 里一片红黄，你装了 WP Rocket，又换了 ShortPixel，连 Cloudflare 都挂上了，打开 PageSpeed Insights 还是 68 分。问题不是你不够努力，是你一直在错误的层次上努力。

我跑着几个中小站，踩过两年 Core Web Vitals 的坑，结论很朴素：达标的瓶颈不是技术，是"把动作匹配到正确的层次"。大约 80% 的红灯能在插件级解决，10% 要换主题，10% 要换主机。按指标乱改顺序，只会把简单的事做复杂。

这篇文章把 LCP、INP、CLS 三个指标拆进三档"改动成本"里，按你能出多少力来组织，而不是按指标顺序教你一遍。

先搞清楚你在看的是哪个分数

你在 PSI 看到的 88 分和 GSC 报告里的"欠佳"状态，不是同一件事。动手之前，先把这点理顺，不然你会朝着错的目标改半天。

PageSpeed Insights 页面有两块：上面的 CrUX 真实用户数据（过去 28 天 Chrome 用户的实测），下面的 Lighthouse 实验室分数（模拟一台中端手机跑一次）。只有 CrUX 那一块影响 Google Search Console 里的 CWV 状态，进而和排名挂钩。Lighthouse 那个 0–100 的彩色圆圈，是参考值。

这意味着两件事。第一，不要追 100 分。Lighthouse 99 分但 CrUX 是红的，你在排名上依然是欠佳；CrUX 全绿但 Lighthouse 只有 75 分，GSC 一样显示良好。绿灯即停，别折腾。第二，新站或流量很低的页面，CrUX 会显示"数据不足"。这时候 GSC 不会给你红黄标记，你真正需要的是先把流量做起来，别急着优化。

具体去哪看？GSC 左侧"体验 → Core Web Vitals"，按移动/桌面分开报表，点进任何一条问题 URL，你会看到"同组网址"——这是 Google 帮你把结构相似的页面聚成一簇。90% 的情况下问题出在模板级（比如文章页模板、分类页模板），你改一个模板就能救一批页面。关于 GSC 的常规用法我写过一篇Google Search Console 使用教程，这里不展开。

指标阈值放在这里，后文直接引用：

指标 Good Needs Improvement Poor
LCP ≤ 2.5 s 2.5–4 s > 4 s
INP ≤ 200 ms 200–500 ms > 500 ms
CLS ≤ 0.1 0.1–0.25 > 0.25

GSC 取三项中最差的那个决定网址状态。换句话说，CLS 一个人红就够让整个页面被标记欠佳。

LCP INP CLS 三大指标阈值对比图

把优化动作分三档，按改动成本决定做什么

优化不是一条线性路径，是一张决策图。动作按你需要付出的改动成本分三档：

  • 插件级（半小时）：装/配置插件、压一批图、在后台勾几个选项。覆盖我经验里约 80% 的红灯。
  • 主题级（半天到一天）：换主题、改 functions.php、按页面停用脚本。INP 红灯多半卡在这里。
  • 主机级（一次性迁移）：升级主机、上 CDN、换 PHP 版本。解决 TTFB 的天花板问题。

正确的顺序是从便宜往贵做，做完一档重新测 CrUX，不要跳档。大多数中小站走完第一档就绿了，第二档是 INP 专治，第三档是最后的硬骨头。

按改动成本分三档的 CWV 优化决策图

第一档·插件级：半小时能完成的 80%

这一档的目标是用最少的动作把 LCP 和 CLS 拉进绿区。INP 也能带一点收益，但主力不在这里。

LCP：把首屏大图搞定，其他都是次要的

打开一篇文章用右键检查，LCP 元素十有八九是文章头图或 Hero 图。先把这一张图治好，LCP 一般就能从 3.5 s 级跌到 1.5 s 级。

三步操作：

  1. 压到合理体积。首屏大图控制在 80–100 KB，内页配图 50–80 KB，超过 150 KB 必须重新处理。装一个 图片 webp 压缩 插件（ShortPixel 或 Imagify 选一个，不要都装），批量转 WebP。
  2. 首屏大图禁止懒加载。缓存插件默认会给所有图片加 loading="lazy"，首屏图必须在排除列表里加一条——否则浏览器等滚动事件才开始下载，LCP 直接崩。
  3. 给首屏图加 fetchpriority="high"。现代浏览器默认给所有图一样的优先级，手动提一档对 LCP 有立竿见影的效果。大多数缓存插件新版本有这个开关。

知乎上有站长把 WP Rocket + Cloudflare 跑到 LCP < 500 ms，动作就是延迟非关键 JS、懒加载非首屏图、CDN 回源。这不是什么黑科技，是把默认值调对了而已。更细的设置我放在 WordPress 速度优化 那篇里。

CLS：给一切会撑开空间的元素写尺寸

CLS 是三项里最容易修的。因为"没有尺寸的东西在加载时撑开了空间"这一条，能覆盖我见过 90% 的 CLS 红灯。

  • 图片必须写 width 和 height。Gutenberg 编辑器默认会写，但从旧版迁移或用外部图床的站经常漏。不写高宽浏览器就占 0 高度，图一加载就往下顶一块，CLS 蹦。
  • 广告位、iframe、嵌入视频必须用 CSS 预留高度。AdSense 响应式广告是 CLS 重灾区，给它的外层 div 写一个 min-height，哪怕等一会儿广告没来也不会塌陷。
  • 自定义字体加 font-display: swap + size-adjust。纯 swap 会导致字体替换时文字宽高变化（典型 FOUT），配合 size-adjust 让备用字体先占和最终字体接近的空间。
  • 首屏的布局错位。这个比较阴，Sukka 博客记录过一个 Hexo 的真实案例：第一次绘制主体在第 1 列，侧栏样式晚到把主体挤到第 2 列，肉眼几乎看不出，但 CLS 报 0.25。用 CSS Grid 或 Flex 把列位置显式声明清楚就行。

定位具体是哪个元素在跳的最快方式：Chrome 装 Web Vitals 扩展，打开 Overlay，刷新页面，抖动的元素会被红框标出来。比在 DevTools 里翻 Performance 面板直观得多。

INP：先把第三方脚本延迟加载

这一档能做的 INP 改进只有一条：把所有非关键 JS 设置为 “Delay JS”（延迟到首次用户交互再执行）。WP Rocket、LiteSpeed Cache、Perfmatters 都有这个开关。

原理是 INP 的"输入延迟"那一段来自主线程被阻塞——把分析脚本、聊天气泡、推荐系统的 JS 全都挤到用户点击之后执行，首屏 INP 立刻好看很多。

如果这一档跑完 INP 还是红，别在插件里继续折腾，往下走。

第二档·主题级：INP 红灯八成卡在这里

插件级改完了，LCP 和 CLS 一般都进绿区了，但 INP 顽固地停在 280 ms。这时候你要承认一个事实：问题不在你，在主题。

中小站站长几乎没人自己写 JS。那 INP 差的 JS 是谁在跑？

  1. 主题自带的 slider、mega menu、动画库。市集上那些卖 59 美元的"多功能"主题，打包了轮播、视差滚动、AJAX 分类过滤，全都是 INP 杀手。
  2. 一个插件在全站加 JS，但你只在一页用到。Contact Form 7 的 JS 挂在整站首页也在加，WooCommerce 的购物车脚本在博客文章里也在跑。
  3. 移动设备上放大的代价。移动 CPU 大约是桌面的 1/4 到 1/8。你桌面测 INP 150 ms 完全没感觉，手机用户那里实际是 400 ms。

所以在 PC 上用 PSI 测 INP 基本没意义，要看 GSC/CrUX 的移动端数据。

动手的三条路径：

路径 A：按页面停用不必要的脚本。 装 Asset CleanUp 或 Perfmatters，进入每个页面模板，把不需要的插件 JS 显式停掉。博客文章页停 WooCommerce，首页停 Contact Form 7，分类页停评论 JS。这一步做完，INP 通常能降 50–100 ms。

路径 B：换掉主题。 如果你现在用的是带 slider 和 mega menu 的市集主题，换成 GeneratePress、Kadence、Astra 里的任何一个。这三个主题在 INP 上的口碑是中小站圈公认好的。换主题确实麻烦，但一次性解决问题。WordPress 主题推荐 那篇里有具体对比。

路径 C：删掉聊天气泡/第三方嵌入。 带 chat widget 的站点 INP 基本没救，这些脚本动辄几百 KB 并且常驻主线程。问问自己：这个聊天框一个月接到几个真实询盘？不值得就删。

有个小技巧能快速判断你的 INP 问题是哪一类：打开 Chrome DevTools → Performance → Record，在页面上点一下你觉得最重的元素（展开菜单、切换标签），停止录制看 Main 线程火焰图。红色的长块写着 evaluateScript 或某个插件名，基本就锁定凶手了。

第三档·主机级：当 TTFB 成了天花板

前两档都做完还没绿，那就该动主机了。

共享主机的 TTFB 典型值是 400–800 ms。LCP 预算只有 2.5 s，TTFB 先吃掉 700 ms，前端实际只剩 1.8 s 来加载 HTML + CSS + LCP 图片。如果你的图再大一点，JS 再卡一下，就是过不了。这种情况下你继续在前端优化，是在拿小刀砍钢板。

三个动作按性价比排序：

  1. 上 Cloudflare 免费 CDN。对中文站的静态资源加速最明显，TTFB 常能改善 30% 以上。开启 “Cache Everything” 规则后，HTML 本身也能被边缘节点命中。CDN 静态资源加速 那篇里有设置细节。
  2. 升级到 PHP 8.2 + 启用 OPcache。很多老站还在跑 PHP 7.4，单就这一步 TTFB 能掉 100–200 ms。主机面板点几下就行。
  3. 换到支持 LiteSpeed 或 NVMe 的主机。预算允许的话，从共享主机跳到一个入门级 VPS 或 LiteSpeed 主机，TTFB 能从 700 ms 级降到 200 ms 级。对中小站这是一次性花钱买永久解决方案。

注意一个陷阱：很多人在共享主机上装 Redis 对象缓存插件，以为能救 TTFB。实际效果在小流量站几乎看不到——因为瓶颈不在数据库查询，在于共享主机本身的 I/O 和 CPU 配额。把钱和时间花在 CDN 和主机升级上更实在。

30 分钟 checklist 和什么时候该停手

按下面这个顺序做完，大多数中小站能从一片红到 CrUX 全绿：

  1. GSC → CWV 报告，找出"同组网址"最多的模板（5 分钟）
  2. 装缓存插件（WP Rocket 或 LiteSpeed Cache 二选一），开启延迟 JS、页面缓存、CSS 合并（5 分钟）
  3. 压图片到 WebP，首屏图加 fetchpriority="high"，从懒加载排除（10 分钟）
  4. 给所有图写 width/height，给广告位/iframe 预留高度（5 分钟）
  5. 装 Asset CleanUp，逐模板停用不必要的插件 JS（5 分钟）
  6. 等 28 天看 CrUX 更新

做完第 6 步还没绿的部分，是进入第二档（主题）和第三档（主机）的信号，不是继续在插件里瞎调的信号。

什么时候该停手？ 三条判断：

  • CrUX 全部进入 good，停手。不用追 100 分。
  • LCP/CLS 绿，INP 卡在"欠佳"（200–500 ms），但你不想换主题——可以接受。GSC 页面状态会是"欠佳"而不是"差"，对排名影响有限，优先把精力放回写内容。
  • 红灯死死不动，但你已经换了主题和主机——去 web.dev/field-data 或者社区求诊，这种情况通常是某个具体第三方脚本的锅，需要定点分析。

最后一个容易被忽略的点：CWV 是长尾指标。你今天改完，GSC 要 28 天才更新完整；你测 CrUX 的时候看到数据还在动，不代表优化没生效，而是真实用户样本还没刷新完。改完标记一下日期，一个月后再下结论。