改动前后各采一次指标、用同一口径比对，才能判断优化是否有效。这份文档规定采集环境、采集对象与指标口径，并给出从结果反推优化项的路径。

一、适用范围

• 适用：站点改版、CDN 调整、资源合并前后的性能对比；LCP、CLS、INP 等核心指标异常时的定位；新页面上线前的性能基线建立。
• 不适用：服务器 CPU、内存、数据库等后端资源监控；单纯的前端视觉走查，见《多端适配检查指南》；CDN 配置本身的正确性检查，见《站点访问链路检查操作说明》。

二、准备工作

项目	要求	检查方法
测试 URL	固定 3—5 个代表页：首页、列表页、内容页	写成清单，前后两次采集必须一致
采集环境	同一网络、同一设备类型、无痕窗口	记录出口 IP 与浏览器版本
采样次数	每页至少 3 次，取中位数	结果表按页记录 3 个数值
工具	npx lighthouse、浏览器性能面板可用	npx lighthouse --version
基线	改动前的指标已归档为 JSON	文件保存在 /srv/axis/metrics/ 下

• 采集前关闭其他占用带宽的程序，避免下载与视频影响结果。
• 移动端与桌面端分别采集，不要混在同一份对比表里。

三、操作步骤

本节拆成三个子步骤，建议按顺序执行；每一步完成后先确认结果，再进入下一步。

3.1 指标采集

按规定环境对固定页面连续采样，输出 JSON 报告并记录 LCP、CLS、TBT、TTFB 等指标。采集参数、页面清单与报告路径一起归档，下一次采集直接复用同一套参数，参数漂移会让前后数据失去可比性。详见 3.1 指标采集。

3.2 结果解读

区分“偏慢但稳定”与“波动很大”两类问题，先判断瓶颈在传输、渲染还是主线程，再决定优化方向。判断顺序是先用 TTFB 区分服务端与前端，再用 LCP 定位首屏资源，最后用长任务与布局位移确认脚本与样式的影响。详见 3.2 结果解读。

3.3 优化项定位

结合资源瀑布图与审计明细，把问题落到具体资源、具体请求或具体脚本上，形成可执行的改动清单。清单里每条都要写明文件路径、目标指标与预期收益，无法落到文件上的条目直接删掉，不要留在文档里充当结论。详见 3.3 优化项定位。

采集、解读、定位三步完成后，把结论、原始报告与改动清单放在同一目录归档。下次复测时按同一清单逐项比对，才能判断优化是否真的生效，而不是只看总分有没有上涨。

四、验证方法

1. 执行 npx lighthouse https://cdn.example.com/ --only-categories=performance --output=json --output-path=/srv/axis/metrics/home.json --chrome-flags="--headless"，预期命令正常结束且 JSON 中 lighthouseResult 存在；命令报错时先解决浏览器与网络，不要直接改参数重试。
2. 用 jq 取出核心指标：jq '.audits | {lcp: .["largest-contentful-paint"].numericValue, cls: .["cumulative-layout-shift"].numericValue}' /srv/axis/metrics/home.json，两项指标均有数值，出现 null 说明采集未完成。
3. 同一页面重复采集 3 次，LCP 波动不超过 15%；超过则说明环境不稳定，需重新采集，波动数据不能作为基线。
4. 优化上线后按同一清单复采，LCP 或 TBT 至少有一项改善且其余指标未明显变差，才算验证通过；只有总分上涨而单项恶化时，按未通过处理。

五、常见问题

现象	可能原因	处理方式
同一页面两次结果差异很大	网络抖动或后台任务干扰	固定出口、关闭其他任务，重采 3 次取中位数
LCP 偏慢但 TTFB 正常	主图过大或首屏资源加载顺序不当	压缩首屏图片，预加载关键资源
CLS 偏高	图片与广告位未预留尺寸	为媒体元素设置宽高或占位
TBT 高	主线程被长任务占用	拆分长任务、延迟加载非关键脚本
本地分数与线上差异大	本地无 CDN 与压缩链路	统一以线上 URL 为采集对象

六、回滚与注意事项

• 回滚：优化改动按构建产物版本回退，回退后重新采集同一组页面，与基线对比确认恢复。
• 注意：指标只在同环境、同页面、同口径下可比，换设备或换网络后的数值不可直接对比。
• 注意：不要只看总分，总分会掩盖单项指标恶化；判断以 LCP、CLS、INP 的具体数值为准。

上一页3.3 回源设置

下一页3.1 指标采集