核心网页指标修复清单

检查清单： 核心网页指标修复。时间盒： 一个工作日用于确认范围和诊断；一个至十个工作日用于典型修复和发布，取决于原因位于资源、共享模板、第三方脚本、源站还是CDN中。实地验证遵循滚动28天数据窗口，另行安排。负责人： 由性能工程师或高级前端工程师负责。技术SEO负责人拥有实地验收标准的决策权；平台、设计、分析和产品负责人审批各自系统中的变更。

本清单将已诊断的性能问题转化为已发布并经实地验证的修复。核心网页指标 是Google衡量加载、响应性和视觉稳定性的真实用户指标：最大内容绘制（LCP）、交互到下次绘制（INP）和累积布局偏移（CLS）。首字节时间（TTFB）和首次内容绘制（FCP）是辅助诊断指标。它们被纳入是因为缓慢的响应或空白屏幕会消耗实现良好LCP的可用时间。

为何使用本清单，以及为何在此处使用

本清单使用来自性能与核心网页指标审计 的修复登记记录。前一阶段识别出存在问题的指标、受影响的URL和模板、真实用户基线、可重复的实验室条件、疑似原因、优先级和负责人。修复仅在这些字段存在后方可开始。否则，开发者只会被要求「让网站更快」，并自然会更改工具首先高亮的内容，而无论其是否导致了实地问题。

诊断必须在采取行动之前缩小至三个层级：哪个指标、哪个模板、以及哪个元素或任务。全站范围的TTFB问题需要平台修复；仅在文章页面上失败的LCP可能来自其主图组件；打开产品筛选后的INP问题可能来自某个事件处理程序；促销页面上的CLS可能来自未预留空间的横幅广告。将它们视为同一问题会导致变更范围过大和职责不清。

修复内部的顺序至关重要。TTFB处于上游：在第一个响应字节到达之前，浏览器无法发现正常的HTML资源也无法绘制页面内容。如果TTFB表现不佳，应首先修复响应生成、缓存、重定向和边缘交付，然后再压缩LCP图片。在响应时间进入预算范围后，按顺序推进：资源发现、资源下载、渲染、交互和布局稳定性。

跳过本清单将使审计沦为一份报告。在诊断前运行本清单会导致症状追逐：在延迟发现占主导时压缩图片，或在源站响应缓慢时推迟脚本。

输入与输出

输出使未来的负责人能够复现问题、识别已发布内容，并区分实验室验收与实地确认。

检查清单

在修改生产环境前完成第1–4项。第5–8项按依赖顺序实施修复。第9–11项将即时发布验收与实地验证区分开。

1. 锁定存在问题的指标、模板和元素

内容： 将诊断结果缩小至一个指标、受影响的模板集合以及命名的元素、请求、任务或服务器区间。原因： 全站评分无法确定可部署的工作，且两个URL可能由于不同原因失败。方法： 将第75百分位失败结果与追踪关联，比较受影响和未受影响的模板；命名LCP元素及延迟、INP交互及任务、CLS元素及触发条件、或TTFB请求路径及缓存状态。工具： CrUX证据、浏览器追踪、瀑布图、服务器时序、模板清单和问题跟踪器。完成条件： 证据支持「指标X在模板Y上失败，因为Z在条件C下造成延迟或移动」。

2. 使用代表性页面确认范围

内容： 对每个受影响模板测试一个典型URL和一个最差情况URL，外加一个未受影响的对照URL。原因： 单页面修复可能隐藏共享缺陷，而全站变更在只有某个内容变体导致问题时可能并不必要。方法： 保持设备、网络、地理位置、同意、登录和缓存条件一致；比较组件使用情况、资源权重、响应时序、第三方活动以及内容长度。工具： 分析工具、模板清单、浏览器性能工具、请求监视器和测试矩阵。完成条件： 每个范围内的模板被标记为受影响或对照，每个模板都有可复现的证据，并且发布范围指明了必须变更的组件、路由、资源族或平台层。

3. 设定预算并保护必需行为

内容： 定义数值目标、回归护栏以及必须保留的功能。原因： 「更快」没有验收边界，删除同意管理器、分析标签、无障碍焦点行为或产品功能可能造成误导性的通过结果。方法： 按下表决策规则设定目标，在重复测试变化较大的情况下增加更严格的内部缓冲值，并列出需要重新测试的关键旅程和非目标指标。工具： 诊断登记表、产品需求、分析方案、无障碍检查和性能预算。完成条件： 工单中明确说明目标指标及值、实验室验收方法、实地验收方法、受保护行为、允许的权衡条件、回滚条件以及指定的审批人。

4. 在前端工作前检查TTFB

内容： 从受众相关的地理位置，在冷缓存和热缓存条件下测量TTFB。原因： TTFB计入后续每次绘制时间中；前端工作无法挽回已用于等待HTML的时间。方法： 在有检测手段的情况下，将请求拆分为DNS、连接、重定向、CDN等待、源站计算、数据库或上游API时间以及流式传输行为。比较缓存命中与未命中响应，确认个性化或Cookie未意外禁用缓存。工具： 请求瀑布图、服务器时序、CDN和源站日志、应用性能分析和合成请求监控。完成条件： TTFB在约定预算范围内，或存在一个单独的阻塞性平台问题已分配负责人并已排期。在TTFB表现不佳且原因不明之前，不要开始LCP优化。

5. 首先移除服务器和交付延迟

内容： 纠正缓慢的源站响应、缓存未命中、重定向或远距离交付。原因： 这些原因会延迟每个元素，且通常影响多个模板。方法： 移除可避免的重定向；缓存安全的HTML和数据；减少缓慢的数据库或API工作；将工作移出关键路径；调整CDN路由和缓存键。未经批准的设计不得缓存私有响应。工具： 应用分析器、查询追踪、CDN配置、响应头、监控和负载测试。完成条件： 重复的冷热缓存测试达到预算，缓存变体保持正确，错误数未回归，且优先URL在无额外跳转的情况下返回预期响应。

6. 修复LCP的发现、传输和渲染延迟

内容： 缩短最大内容绘制 ，即最大可见图像或文本块渲染的时间。原因： 过大的主图很常见，但发现过晚、优先级过低、阻塞渲染的CSS、JavaScript或字体可能占主导地位。方法： 提供尺寸正确的响应式图像；不延迟加载首屏LCP资源；在初始HTML中暴露该资源；仅在有证据的情况下设置优先级或预加载；移除渲染阻塞资源；使用子集化、可缓存的字体并搭配合适的后备字体。工具： LCP分解、瀑布图、图像检查、覆盖率报告、追踪和视觉对比。完成条件： 预期的LCP元素保持一致，其主要延迟下降，代表性页面满足预算，且带宽、文本可见性和渲染未出现回归。

7. 在具体交互中修复INP

内容： 缩短导致交互到下次绘制 （响应性指标）表现不佳的交互。原因： 盲目删除JavaScript可能不会触及缓慢的事件。方法： 分离输入延迟、处理延迟和呈现延迟；拆分长任务；移除同步工作；推迟非必要的第三方；避免重复布局；减少重新渲染；让出主线程以进行绘制。在真实硬件上使用生产环境第三方进行测试。工具： 交互追踪、主线程分析、长任务记录、框架分析器和真实设备。完成条件： 关键交互正常工作，负责任务满足重复测试预算，实地代理指标已记录，且分析、同意、键盘和屏幕阅读器行为未出现回归。

8. 通过预留最终布局修复CLS

内容： 防止导致累积布局偏移 （视觉稳定性评分）的移动。原因： 图像、字体、广告、横幅、嵌入内容和异步组件均可能导致界面移动。方法： 设置固有尺寸或aspect-ratio；为动态模块预留插槽；使用兼容的字体后备方案；使用transform进行动画。工具： 布局偏移区域、追踪、胶片帧、视觉回归测试和限速浏览器。完成条件： 每个实质性的偏移簇都有命名来源，页面在加载和关键交互过程中满足CLS预算，且预留空间不遮挡任何控件。

9. 重新测试整套指标和受保护旅程

内容： 在相同条件下将发布候选版本与冻结基线进行比较，然后在生产环境下测试。原因： 改善一个指标可能损害另一个指标：推迟JavaScript可能改善LCP但恶化首次交互，激进的字体变更可能改善绘制时序但造成布局偏移。方法： 运行多个受控样本，比较声明的统计量而非最佳运行结果，检查追踪，运行受保护的旅程，验证响应正确性，测试受影响和对照模板。工具： Lighthouse或等效的实验室运行工具、浏览器性能工具、请求监视器、视觉和功能测试以及发布检查清单。完成条件： 目标指标在声明的重复运行方法下满足实验室预算，TTFB/FCP/LCP/INP/CLS均未出现严重回归，受保护行为通过测试，生产环境提供预期变更，且未触发回滚。

10. 注释发布并安排实地审查

内容： 记录部署时间戳、变更范围、目标指标、预期方向以及实地审查日期。原因： CrUX使用滚动28天窗口，因此发布前的体验在部署后仍会出现在报告的第75百分位中。没有注释，团队可能过早判定一个好的修复无效，或将后续变动归因于错误的发布。方法： 将生产版本与诊断结果关联，立即检查错误，记录早期实地读数但不可将其视为最终结果，并安排负责人在窗口充分刷新后进行审查。工具： 部署日志、问题跟踪器、CrUX、AmICited Web Vitals和监控。完成条件： 工单标记为实验室已验收，发布注释和即时证据已附加，且存在指定的负责人和日历日期用于实地验证。

11. 根据实地数据验证并关闭或重新开启

内容： 在滚动窗口充分刷新后，对同等条件下的第75百分位实地数据进行比较。原因： 真实用户的设备、网络、地理位置、缓存行为、同意状态和交互无法通过一次实验室运行来代表。方法： 使用相同的CrUX级别（URL或来源）、相同的指标和可比的受众范围；考虑部分发布和其他发布的影响；检查模板代表页面而非仅依赖来源聚合数据。如果结果未达标，将当前追踪与原始原因陈述进行比较并重新开启诊断，而非堆叠不相关的调整。工具： AmICited Web Vitals、CrUX历史、发布注释、分析分段和证据包。完成条件： 目标指标满足约定的第75百分位阈值和范围，并记录局限性，此时状态变为实地已验证；或者工单凭借新的证据、负责人和下一个假设明确重新开启。

AmICited中的工具

打开AmICited Web Vitals 查看你的域名和追踪竞争对手的LCP、INP、CLS、FCP和TTFB（数据来自CrUX）。在诊断阶段使用它捕获实地基线，在部署后使用它验证滚动的实地结果。空值表示符合条件的实地数据不足，既不是零也不是通过。产品视图支持判定结论；追踪、服务器时序和浏览器配置文件仍用于识别原因。

使用性能影响 将页面级别的性能证据与引用位置关联，并识别有价值但缓慢的页面。这种关联有助于确定修复优先级，但不证明性能单独导致了引用结果。在解读变动时需保留相关性、内容、权威性和发布背景。

关于产品工作流程，请参考如何在AmICited中检查核心网页指标 。教程说明了指标的显示位置以及竞品比较的方式；本清单管理诊断、实施和验收。

决策规则：什么算作不合格

使用第75百分位数（简称p75）进行实地决策：75%的符合条件记录体验等于或低于该值。边界值属于较好的一档。LCP、INP和CLS决定核心网页指标状态；TTFB和FCP是用于排序和诊断工作的辅助衡量指标。

按顺序应用以下规则：

1. 超时、服务器错误、响应不正确或关键旅程故障将阻止发布，无论指标得分如何。
2. 较差的TTFB处于LCP的上游，应首先修复。当服务器已消耗大部分绘制预算时，不得声称仅通过图像解决问题。
3. 较差的实地指标优先于需要改善的指标。在同一等级内，优先处理共享模板原因、高流量和业务关键旅程。
4. 空白的URL级别实地值为未知。使用实验室证据和已记录的代理指标，但不得将未知重标记为良好。
5. 单次通过的实验室运行不足。在测试前声明设备/网络配置文件和重复运行方法。
6. 当部署的行为和受控测试通过时，修复为实验室已验收。仅在可比的滚动实地数据达到约定阈值后，方可标记为实地已验证。
7. 如果来源数据通过但高流量模板失败，则该模板的结论在该范围内优先。聚合不得掩盖集中的用户问题。

可交付成果：修复与验证包

每个根本原因交付一个工单或登记条目，附带子范围（当一个原因影响多个模板时）。使用电子表格、问题跟踪器或工程文档，但保留以下字段：

诊断ID及主要指标：
实地来源：URL | 来源
实地p75值、等级及28天窗口：
受影响的模板及代表性URL：
对照模板及URL：
元素、交互、请求或服务器区间：
原因陈述及证据链接：
实验室配置文件和重复运行基线：
目标、护栏及受保护旅程：
选定修复方案及被拒绝的替代方案：
工程负责人、审批人及依赖项：
发布/版本ID及部署时间戳：
即时生产与实验室结果：
CrUX实地审查负责人及日期：
可比实地结果及局限性：
监控阈值及重新开启规则：
状态：开放 | 实施中 | 实验室已验收 | 实地已验证 | 已重新开启 | 已接受风险

附上追踪、瀑布图、服务器区间、偏移记录、交互配置文件、测试输出和发布注释。已接受风险需要说明范围、原因、审批人、到期时间和监控触发器；它不等同于通过。

当另一位工程师能够复现原始问题、确认此变更如何解决该问题、验证已交付至生产环境的内容、并在无需询问原始调查者重建工作的情况下重复实地对比时，该包即被视为可接受。

常见问题

在隔离原因之前进行优化。 泛化的压缩和脚本删除替代了诊断。要求先提供指标-模板-元素证据。

在源站缓慢时压缩主图。 更小的图像不能在HTML到达之前渲染。当TTFB超出预算时，先测量并修复TTFB。

修复了错误的偏移。 CLS可能来自广告、同意横幅、字体、嵌入内容或水合组件。命名偏移来源。

推迟所有脚本。 不加区分地推迟可能破坏同意排序、分析、导航、表单或首次交互。更改负责的执行路径并对必需行为进行回归测试。

在共享模板发布后仅验证一个URL。 选取的示例可能通过，而更重的内容变体或其他组件配置仍可能失败。测试典型页面、重型页面和对照页面。

将来源级别数据解读为模板通过。 健康的高流量页面可能掩盖某个薄弱品类、文章或产品模板。保持诊断和验收在最小可靠范围内。

在部署当天关闭工单。 即时测试确立实验室验收。它们不能替代滚动的实地数据窗口。

等待28天才发现发布问题。 实地确认需要时间，但状态码、错误、旅程、视觉稳定性和受控指标应立即检查。滚动数据不是跳过发布质量保证的借口。

下一阶段：持续监控与迭代

将实地验证记录、发布注释、受影响的模板、局限性和阈值移交给持续刷新与迭代 。它需要一个稳定的基线，以便后续的内容、媒体、模板、活动和第三方变更可以进行比较，而无需重新发现为无法解释的变动。

下一任负责人记录谁在监控每个阈值、证据存放位置、审查频率以及什么条件会重新开启修复。当出现以下情况时，应在第1项重新开始本清单：某个指标再次变差、在完全刷新的窗口内反复出现需要改善的趋势、LCP元素发生变更、出现新的缓慢交互、或模板发布改变了已诊断的路径。不要自动重复之前的修复：同一指标可能在重新设计后因不同的元素而失败。

当实地状态明确、每个已接受的局限性都有负责人和审查日期、且监控能够将回归与模板和发布关联起来时，交接即告完成。如果实地验证仍处于待定状态，下一任负责人将收到已安排的审查日期，工单保持实验室已验收状态而非已关闭。

常见问题解答

核心网页指标修复常见问题解答