页面在开发电脑上打开很快，不代表真实用户体验好。用户可能在普通手机和移动网络下访问，首屏迟迟不出现、点击后没有反馈，或内容突然跳动误触按钮。
核心网页指标的价值，不是追求一个绿色分数，而是用统一口径发现模板、设备和真实访问中的体验瓶颈。
01 LCP看主要内容何时出现
LCP记录首屏视口中最大图片、文字块或视频封面的呈现时间。官方建议在第75百分位达到2.5秒以内。
常见问题包括服务器响应慢、首屏图片过大、资源发现太晚、字体阻塞和多次重定向。
02 INP看交互是否持续及时
INP观察用户点击、触摸和键盘交互到下一帧反馈的延迟，官方良好阈值是200毫秒以内，并以第75百分位判断。
长JavaScript任务、复杂渲染、第三方脚本和大量同步工作常会拖慢响应。
03 CLS看页面是否意外跳动
CLS衡量生命周期内意外布局移动，良好阈值是0.1以内。未预留图片尺寸、字体替换、动态广告和上方插入内容都可能导致跳动。
用户主动触发的合理变化与意外移动要区分。
04 现场数据和实验室数据作用不同
CrUX和Search Console反映真实用户在过去周期的汇总体验，Lighthouse和本地测试便于诊断单次页面。
实验室分数很高但现场数据差，可能来自设备、地区、缓存和第三方差异。
05 应按模板和用户群定位问题
首页、文章、产品详情和后台可能有不同瓶颈。按URL组、设备、地区和版本分析，比只测首页更有意义。
优先处理流量大、转化关键和问题规模高的模板。
06 优化后要复测业务和视觉
压缩图片、拆分脚本和预留尺寸可能影响清晰度、功能或版式。性能优化不能只在技术层完成，需要设计和产品共同验收。
现场指标更新需要时间，短期可结合日志和监控确认改动是否生效。
Core Web Vitals速查
指标 | 良好阈值 | 主要反映 | 常见根因 |
|---|---|---|---|
LCP | ≤2.5秒 | 主要内容加载 | TTFB、首屏资源、图片、字体 |
INP | ≤200毫秒 | 持续交互响应 | 长任务、脚本、复杂渲染 |
CLS | ≤0.1 | 视觉稳定 | 尺寸缺失、动态插入、字体变化 |
判断口径 | 第75百分位 | 大多数真实用户 | 需区分移动和桌面 |
常见问题
PageSpeed分数等于Core Web Vitals吗？
不等于。Lighthouse分数是实验室综合评分，Core Web Vitals更强调具体指标和真实用户数据。
没有CrUX数据怎么办？
可先使用实验室测试和自建真实用户监控，等访问量达到条件后再结合公开现场数据。
所有页面都必须达到相同数值吗？
目标一致，但优化优先级应结合模板、流量和业务价值。
Core Web Vitals会直接决定排名吗？
Google使用多种信号，页面体验只是其中一部分，优质相关内容仍然重要。
优化多久后Search Console会更新？
现场数据按滚动周期汇总，通常不会即时反映单次部署，需要持续观察。
链接复制成功
