WordPress 核心网页指标：三个指标的标准与 75 分位

同一份测速报告，为什么两个人查出来的"是否达标"完全相反？因为他们看的不是同一个口径。结论先摆在前面：LCP 应在 2.5 秒内、INP 应在 200 毫秒或更低、CLS 应在 0.1 或更低，按第 75 百分位衡量，移动端与桌面端分开统计，三项都达标才算通过。这组数字和这条口径都出自 web.dev 对 Web Vitals 的说明，同一页写明 Web Vitals 是 Google 用来统一体验度量的倡议，目标是让站长不必先成为性能专家，也能判断自己给出的体验好不好。 确认问题属于布局位移后，再按WordPress CLS 排查顺序检查图片尺寸与动态插入内容。

三个指标各自负责什么

LCP 量的是加载：视口里最大的那块内容（图片、文字块或视频）什么时候画到屏幕上。INP 量的是响应：用户点击、点按或按下按键之后，浏览器要多久才把下一帧画出来。CLS 量的是视觉稳定：内容有没有在用户没料到的时刻突然挪位置。三项分别对应加载、交互、稳定，任何一项都不能替另外两项说话。 若瓶颈在最大内容绘制，转到WordPress LCP 三段排查分别检查响应、资源和渲染。

75 分位、两种设备、以及"三项都要过"

第 75 百分位取的是真实访问里表现较好的那 75% 人的共同水平，最差的 25% 被排除在外。移动端和桌面端必须分开统计，因为两端的设备能力和实际拿到的内容都不一样。web.dev 讲阈值怎么定的那一页给出了好与差两档的对照表：

判定规则是：三项在第 75 百分位上都落进"好"这一档才算通过，只过一项不叫达标。这也是为什么很多站"LCP 已经很好"却仍然显示需要改进——短板在另外两项上。

FID 已退场，实验室工具测不出 INP

两处最容易对不上的地方。其一，FID（首次输入延迟）已在 2024 年被 INP 取代，看到还在要求优化 FID 的清单多半是旧资料。其二，Lighthouse 这类实验室工具在没有真实输入的情况下无法测量 INP，只能用 TBT（总阻塞时间）作代理指标；TBT 变好通常意味着 INP 也会变好，但它不是 INP 本身。同一页还把 TTFB（首字节时间）和 FCP（首次内容绘制）列为辅助指标——它们不属于核心网页指标，价值在于帮你定位 LCP 卡在哪一段。

怎么查自己的站点数据

入口是 Search Console 的核心网页指标报告。它按状态（差、需改进、好）、指标类型和 URL 分组（把相似页面归成一组）三层展示，一组 URL 的状态取其中最差的那项指标。Search Console 帮助页对这份报告口径的说明还提醒两点：只有已收录的 URL 会出现在报告里，而且它不是全部已收录 URL 的清单，只是样本；数据记在实际 URL 上，不是规范 URL 上。

1. 先在 URL 分组列表里，把状态最差、页面数量又多的几组圈出来。
2. 点进其中一组，看清是哪一项指标拖后腿，不要三项一起动手。
3. 把移动与桌面分别打开，记下同一组在两端是不是同一个短板。
4. 把这几组页面对应的模板列出来，多数问题会落在同一个模板上，改一处见效一片。

如果连一份可信的清单都还没有，先别急着看分数。哪些插件在拖慢前台、缓存与数据库该按什么顺序处理，站内两篇旧文已经拆过：哪些插件会拖慢速度、缓存、数据库与前端文件的按需优化。

什么时候这套阈值先放一放

三种情况可以先不追数字。一是站点刚上线、真实访问量还撑不起统计，Google 的公开数据集需要站点公开可发现且样本足够，很多站在这个阶段根本没有数据。二是同一组页面在移动与桌面指向完全不同的短板，说明问题出在设备分层而不是模板，先把分层理顺再谈阈值。三是页面本身没有可交互内容，纯图文归档页测不出有意义的 INP，硬凑一个数字没有价值。 如果交互延迟集中在点击后，则改用WordPress INP 的排查方法定位脚本工作。

还有一条边界必须写清楚：Web Vitals 是建议口径。Google 搜索中心对核心网页指标的说明用的措辞是强烈建议站长取得好的指标，并说这与核心排名系统想要奖励的方向一致；官方没有公布达标与排名位置之间的对应关系，也没有公布任何流量变化比例。把阈值当体验目标去做，比当排名开关用更站得住。

怎么确认口径一致

交付前对着五行自查：数字是不是 2.5 秒、200 毫秒、0.1；取的是不是第 75 百分位；移动与桌面是不是分开报的；三项是不是同时达标；报告来源标的是真实用户数据（field）而不是实验室跑分。少了任何一行，两边报的数字就没法直接对话。真实数据与实验室数据的差别值得单独展开，这里先把口径钉死，再谈成因。