网站性能审计：修复分数背后的延迟

1. 分别理解实验室与现场测量

Lighthouse运行可重复的实验场景，帮助诊断页面。CrUX在数据充分时汇总符合条件的真实用户体验。两者的人群、设备、网络和时间窗口不同，数值可能不一致。PageSpeed Insights文档解释了两种来源。

阅读每项指标旁的来源。报告可能某项使用现场值，另一项回退到实验室值。确认现场证据属于具体URL还是整个来源。没有现场数据意味着样本不足，不是Core Web Vitals失败，也不证明网站没有访客。

2. 理解三项Core Web Vitals

现场评估按设备类别分别检查访问的第75百分位，参见Web Vitals。单次实验室数值不能标成现场通过。首字节时间和首次内容绘制是有用诊断，但不是额外的Core Web Vitals。

3. 把症状与证据对应

下列优先级只是示例。关键任务所受影响比诊断名称更重要。

优化机会的估算不是保证节省。两项建议可能重叠，看似沉重的资源也可能必需。删除功能或更换基础设施前，应确认瓶颈。

4. 修复造成延迟的组件

主要内容出现晚：先确定LCP元素。服务器响应慢时检查后端工作和缓存；主图发现晚时让它更早出现在文档中，避免对首屏突出图片使用懒加载，并交付合适尺寸。LCP优化指南拆解了加载阶段。

交互响应慢：检查昂贵事件处理、同步渲染和第三方工作。拆分长任务，减少动作附近的不必要计算。Total Blocking Time有助于实验室诊断，但不是INP。结合INP指南和真实交互记录调查。

布局移动：在图片、嵌入和横幅出现前预留空间。正确修复取决于哪个元素移动以及原因。

5. 做受控的前后对比

1. 记录准确URL、设备策略、测试时间和数据来源。
2. 针对观察到的瓶颈做一次一致的变更。
3. 运行多次可比较实验，查看趋势，不挑最好看的一次。
4. 目视检查页面并完成主要交互。
5. 确认共享组件未使其他模板回归。
6. 之后再观察现场数据，汇总窗口不会立刻反映新部署。

保留诊断证据，而不只是分数截图。图片修复改善加载却引入布局位移时，工作尚未完成。重新检查窄屏以及Cookie提示、字体和嵌入组件等延迟内容。

6. 了解测试无法告诉你的事情

一次导航不能覆盖复杂应用的所有状态。页面可以加载很快，却在长时间编辑后变得迟钝。实验室测试可能没有遇到与真实客户相同的同意状态、账户或内容。

Sitelemetry托管报告标明所选策略和可用来源。Local Agent用独立且有限的方法检查本地交付，不应与公开Lighthouse分数直接数值比较。PageSpeed不可用时，应解决或重试缺失测量，而不是把空白指标当成零。性能证据必须明确说明实际运行了什么。

7. 把速度纳入产品流程

为真正负责的模板和交互设定预算：图片体积、第三方脚本和昂贵客户端工作都是实用审核目标。添加聊天组件、分析工具或动画时，要做前后测试，不应假设供应商没有成本。

兼顾正确性、无障碍和速度。视觉稳定且能说明进度的表单，比隐藏内容换来高分更有用。优先选择最重要的移动落地页或转化页，运行可用性能审计，再创建一个具备可测验收条件的修复工单。同一组件影响多个领域时，结合无障碍审核和集成审计一起处理。