为什么要重复检查
性能影响用户加载内容和完成任务的便利程度。请测量对自己受众的影响，不要套用通用转化增长率。Google 在排名系统中使用 Core Web Vitals，但良好数值不保证排名或流量。
跟踪哪些指标
当前 Core Web Vitals 包括：
- LCP（Largest Contentful Paint）：符合条件的最大可见内容元素的显示时点；不超过 2.5 秒为良好。
- INP（Interaction to Next Paint）：点击、触屏轻点和键盘输入到下一次绘制的响应情况；不超过 200 毫秒为良好。
- CLS（Cumulative Layout Shift）：意外的布局偏移；不超过 0.1 为良好，没有单位。
INP 于 2024 年 3 月取代 FID。真实访问应按移动端和桌面端分别评估第 75 百分位数。实验室测试描述选定条件和操作，并不代表所有访客。缺少真实访问数据不等于检查通过。
为什么结果会变化
新增内容、功能、第三方脚本、代码和服务器负载都可能改变表现。浏览器和测量规则也会变化，请记录版本。重复检查有助于发现退化和确定调查优先级，但不保证在用户受影响之前发现问题。
根据风险决定频率
可以将以下频率作为示例起点：很少变化的信息网站每三个月，博客每月，网店每两周。这不是通用标准。重要发布和问题反馈需要额外检查，不应只等日历安排。频繁更新的服务可能需要定时合成测试与真实用户监控。
定期测试按间隔运行。请根据影响和可用资源确定频率、页面、设备配置和地区。“持续监控”不表示测试每个操作或立即发现每次故障。
可复现的审计流程
- 选择有代表性的页面和任务，例如首页、商品或服务、表单和重要交互。记录最终 URL 和条件。
- 收集实验室测量与可用的真实访问数据。在 PageSpeed Insights 中区分两部分，并确认数据对应单个 URL 还是整个源站。
- 根据问题调查 LCP、INP 或 CLS。加载、交互延迟和布局移动可能有不同原因。
- 验证范围有限的修改，例如图片尺寸和格式、昂贵处理、缓存或交付方式。保留必要功能和私有响应的访问规则，不要延迟加载 LCP 图片。
- 发布后，在可比较的条件下重复同一测试。既检查耗时，也检查任务结果，并记录发布日期。
配置自动监控
确认实际计划、告警条件、通知渠道和历史保留期限。区分性能退化、运行失败和测量缺失。测试通知是否送达，并确定处理有效告警的负责人。定时实验室测试与真实用户数据回答不同的问题。
Google Analytics 可以提供已配置的使用和转化数据，Search Console 提供搜索数据与 Core Web Vitals 报告。它们是独立来源；本文不证明它们与速度扫描器自动集成。请比较等长时期，并记录同期其他修改。
保存有用记录
保留初始值、条件、问题说明、修改和复查结果。区分实测改善与假设，再根据风险和发布频率安排下次检查。
先运行一次性速度审计，再配置合适的定期流程。定义和边界见 Web Vitals 指南与 Google 页面体验文档。
