Core Web Vitals 的三个指标——LCP、INP、CLS——门槛分别是 2.5 秒、200 毫秒、0.1。移动端能全部达标的站点仍然只有一半左右。问题通常不在「做得不够多」，而在「改错了地方」。
先对齐门槛。LCP（最大内容绘制）衡量主内容多快出现，好是 2.5 秒以内；INP（交互到下次绘制）衡量点击之后的响应速度，好是 200 毫秒以内，它从 2024 年 3 月起取代了 FID；CLS（累计布局偏移）衡量加载过程中的版面跳动，好是 0.1 以内。
三个指标对应三种完全不同的病因，改法也不一样。所以第一步不是动手，是看是哪个没过。
LCP 没过：八成是首屏那张图
最常见的原因有两类：首屏大图没压缩，或者服务器响应太慢（TTFB 高）。
图片这块，把 JPEG、PNG 换成 WebP 或 AVIF，在 85%质量下基本看不出差别，体积能砍掉一半。但有个反直觉的点：首屏主图不要懒加载。懒加载对首屏图片是负优化——浏览器要等 JS 执行完才去请求，LCP 反而更慢。正确做法是给它 fetchpriority="high"并预加载。
服务器响应这块，先测 TTFB。如果 TTFB 就超过 600 毫秒，后面所有前端优化都是在补救上游。这时候优先级变成：开页面缓存 →换成对象缓存 →考虑换主机。从便宜的共享主机换到配置正常的 VPS，TTFB 从 800 毫秒降到 200 毫秒以下是常见的结果，这是软件优化很难达到的幅度。
INP 没过：JavaScript 太重
INP 差的表现是「点了没反应，过一会儿才动」。原因通常是主线程被长任务占住：第三方脚本（客服组件、统计、广告、A/B 测试）在执行，页面就没空处理你的点击。
处理顺序：先看有哪些第三方脚本，能删的删，不能删的延迟加载；再把非关键的 JS 加 defer或 async；最后拆分长任务。简单展示型站点用重型前端框架，是 INP 差的常见根源。
CLS 没过：没给元素留位置
版面跳动基本都出在同一件事上：某个元素加载出来时，把下面的内容顶下去了。图片没写宽高、广告位没预留空间、字体替换导致文字重排、后加载的横幅把内容推开——都是这一类。
修法很机械：图片和视频都设 width和 height（或者用 aspect-ratio）；广告位和嵌入内容预留固定高度；字体用 font-display: swap，并尽量让后备字体和主字体的字宽接近。
优化的正确顺序
按「投入产出比」排，大致是这样一个次序：
开页面缓存（5 分钟的事，效果最直接）→图片压缩加现代格式（影响最大的单项）→首屏以下懒加载 → PHP 版本更新到受支持的新版 →删掉不用的插件 →延迟非关键 JS →上 CDN →换主机方案。
前四项基本能把大部分站点从「不及格」拉到「及格」。真正需要「换主机」这种大动作的，通常是前面都做完了还是不达标的情况。
几个容易踩的坑
别同时开多个缓存插件。功能重叠会互相冲突，生成重复缓存文件，甚至让页面显示错乱。选一个，配透。
别拿实验室分数当目标。PageSpeed Insights 的分数是模拟环境，真人体感看 Search Console 的 Core Web Vitals 报告（字段数据）。为了 100 分去折腾，往往不如把真实用户的 LCP 从 3.2 秒压到 2.4 秒。
改完别急着看结果。字段数据有 28 天的滚动窗口，今天的改动要等几周才能在报告里体现。想快速验证，用 Lighthouse 或 WebPageTest 测，但那只是参考。
和 AI 搜索的关系
Google 在生成式 AI 优化的指南里提到，AI 功能也建议页面体验达标。道理不难理解：一个要等三秒才出现主内容的页面，爬虫抓取效率也低。速度不是排名的决定性因素，但它是并列条件下的胜负手——而且在 AI 摘要这种「抓取片段」的场景里，能不能被顺利抓到，比排第几更关键。
本文根据公开报道整理，主要参考：SEOYug2026 Core Web Vitals实务指南、TechCoff WordPress提速指南、Cadmin企业站性能报告（2026-10-26）。厂商与项目的后续动作可能继续变化，涉及版本号和漏洞编号请以官方公告为准。
