核心网页指标（Core Web Vitals）衡量的是用户在页面上真实感受到的加载与交互体验。它不直接决定页面是否被收录，但慢加载和布局抖动会实打实地影响点击、跳出与二次访问。把它做成一套固定动作，比偶尔跑一次测速工具有用得多。
三个指标各自在看什么
- LCP（最大内容绘制）：首屏面积最大的那块内容何时渲染完成。常见的拖累项是首图、大尺寸横幅、阻塞渲染的样式文件与字体加载。
- CLS（累计布局偏移）：加载过程中页面元素有没有突然跳动。图片未写宽高、广告位与推荐位没有预留空间、字体替换，都会造成抖动。
- INP（交互到下一次绘制）：用户点击或输入后，页面多久给出反馈。长任务、过多的第三方脚本、频繁的同步计算是主要来源。
三者要分开看。加载快但点不动，和交互流畅但首屏空白，是两类完全不同的问题，混在一起讨论往往找不到下手的地方。
逐层推进的自查顺序
第一步：先看真实用户数据的趋势
实验室跑分只代表某一次、某一台设备、某一条网络的结果。真实用户数据按页面分组看，才能分清是整站性下滑，还是某个模板、某个栏目单独拖后腿。重点关注两类信号：一类是整体指标长期落在需要改进区间；另一类是大部分页面正常，只有少数几个页面明显偏低，这种通常是具体资源或具体组件的问题。
第二步：用实验室数据定位到具体环节
挑一个真实用户数据最差的页面，用浏览器开发者工具重新加载，看瀑布图里谁是关键路径上的长条。同时把 CPU 与网络限速调到中低端移动设备水平，很多在办公网络下看不出来的问题会立刻现形。
第三步：回到资源清单和服务器响应
指标是结果，不是原因。定位到环节之后，再去核对服务器响应时间、静态资源体积、请求数量、渲染阻塞资源、第三方脚本这几项，改动才有落点。
服务器与资源层面最常见的几类原因
- 首字节响应偏慢：动态页面没有缓存、数据库查询未优化、接口串行调用。
- 首屏必要资源被排在后面：关键样式没有内联，脚本缺少异步或延迟属性。
- 图片体积与尺寸不匹配：原图直接输出，或用 CSS 缩小显示，浪费大量传输时间。
- 元素未预留空间：图片、嵌入内容、动态插入的提示条没有固定宽高，加载后挤压正文。
- 第三方脚本无节制：统计、客服、广告、热力图各自加载，主线程被切成碎片。
- 字体处理不当：自定义字体未设置回退策略，文字先隐藏再显示，造成闪烁与偏移。
每周一次的自查动作清单
- 打开真实用户数据面板，按页面与设备分组，记录三个指标里最差的一项，写进站点记录表。
- 挑出两到三个退步最明显的页面，用限速环境重新加载，截下瀑布图。
- 核对这批页面的首图尺寸与文件格式，确认是否按展示尺寸输出。
- 检查模板里图片与嵌入区块是否都写了宽高属性，新上线的组件尤其容易漏。
- 统计第三方脚本数量，问一句：这个脚本现在还有人用吗，能不能换成异步或延后加载。
- 抽一个动态页面看服务器响应时间，确认缓存策略是否生效、有没有回源异常。
- 把本周的结论和上周对比，只改一到两项，改完等几天数据稳定后再评估。
性能优化最容易犯的错，是同时改十件事然后不知道是哪一件起了作用。一次只动一个变量，记录改动日期，数据才有可比性。也别把目标定成“跑分满分”，能稳定落在良好区间、并且在版本迭代中不倒退，就已经足够。
把指标纳入日常流程
指标自查不应该只在出问题时才做。更现实的做法是把它挂到已有的节奏上：新模板上线前跑一次，栏目改版后跑一次，每个季度做一次整站抽样。把每次的结果和当时的改动内容记在同一张表里，几次之后你会大致摸清自己站点的瓶颈集中在哪一层，是渲染、是资源、还是后端响应。
另外要提醒一点：核心网页指标是体验指标，不是排名开关。把它当成用户体验的一部分去经营就好，不要为了追求分数牺牲内容可读性，比如为了减少请求把正文也一起懒加载，反而让内容更难被抓到和看到。