性能与核心网页指标审计

阶段P3 · 步骤A — 理解
时间盒： 代表性审计4–8小时；模板级排查含工程追踪2–5个工作日。28天现场验证在修复后进行，不延长初始审计时间盒。
负责人： 技术SEO负责人负责范围与验收。性能工程师或高级前端工程师负责诊断；平台、CDN、分析、设计和产品负责人在各自系统造成延迟或不稳定时提供支持。

本阶段将真实用户的现场证据和可重复的实验室测试转化为修复清单，该清单与URL、模板、指标、负责人的"完成条件"测试绑定——而非一个笼统的速度分数。

为什么需要这个阶段，以及为什么在这里

性能应属于步骤A，因为页面超时首先是爬取问题，其次才是用户体验问题。爬取器或检索智能体的请求预算有限。如果源站停滞、反复重定向或返回不完整的响应，客户端可能在评估内容之前就放弃了页面。再快的标题、更好的文案和更强的结构化数据，也无法帮助无法可靠检索的内容。

P3阶段使用来自技术基线审计 的规范化主机、预期的可索引模板、优先级旅程、状态码证据和未解决的基础设施发现。这一顺序可防止误诊。例如，由重定向循环导致的五秒"页面加载"不是图像优化任务，而缓存的错误页面的快速测试也不是通过。P2确保正确的URL可以被请求和选择；P3确保它可以在可接受的时间和稳定性限制内被传递和使用。

延迟执行此阶段会造成返工。内容团队可能在一个英雄元素总是最慢的模板中发布内容，或批准一个导致每个产品卡片都发生偏移的推广位。该缺陷随后会蔓延到新页面。

输入与输出

输入确保样本具有代表性。输出形成与下一阶段的契约：确切说明哪些页面可靠可用、哪些条件仍然薄弱、以及哪些性能限制必须在后续测量中加以考虑。

现场数据和实验室数据是不同的证据

现场数据描述的是符合条件的Chrome用户实际体验到的情况。Chrome用户体验报告（通常简称为CrUX）汇总真实访问的测量数据，并报告第75百分位数：即75%的记录体验所达到或低于的值。它包含了真实设备、网络、位置、缓存、同意工具、会话和交互的复杂性。用它来判定用户是否通过了已发布的阈值，以及发布的变更最终是否改善了整体用户群体。

实验室数据描述的是在声明的条件下的一次受控页面加载或交互。Lighthouse是一种实验室测试，应用设备和网络模拟，捕捉追踪并解释可能的原因。用它来重现问题、在同一设置下比较两个构建版本、检查请求链并识别需要做的工作。实验室分数是有用的证据，但不能证明真实用户通过了测试。

两种来源可能不一致，且两者都不一定错误。快速的实验室运行可能使用邻近位置、暖CDN且没有有意义的交互，而现场访问者包括旧手机和遥远网络。应记录不一致并调查其条件；切勿对数值取平均值或选择看起来更健康的结果。

检查清单

按顺序完成这些检查。每个项目都说明了操作、原因、方法、工具和验收条件，以便分配任务和重新测试。

1. 确定代表性URL和条件矩阵

做什么： 定义要测试的URL、模板、设备配置、地理位置、同意状态和缓存状态。原因： 仅审计首页可能通过，而产品、文章或结账模板可能失败。方法： 将P2清单与流量和业务优先级数据结合；选择典型的、重型的和转化关键型的示例。工具： 分析工具、爬取清单、发布登记表和共享测试表。完成条件： 每个优先级模板都有一个经负责人批准的生产样本，每次测试记录设备、网络、位置、登录、同意和缓存假设。

2. 捕获CrUX现场基线

做什么： 记录URL级别和来源级别可用的p75现场指标值。原因： 来源可能掩盖薄弱的模板，而单个低流量URL可能没有可发布的数据。方法： 使用相同的观测日期和28天窗口，明确标注URL级与来源级，并将空值记录为"数据不足"。工具： AmICited Web Vitals和CrUX。完成条件： 每个抽样URL都有LCP、INP、CLS、FCP和TTFB值或记录为未知状态；来源级别和窗口明确无误。

3. 在评分像素之前验证响应可靠性

做什么： 重复请求并记录状态码、重定向、首字节时间（TTFB）、超时和不一致的响应。TTFB是从请求开始到第一个响应字节到达的时间间隔。原因： 页面的HTML开始到达之前无法进行绘制，间歇性失败比外观上的速度慢更为严重。方法： 从相关区域测试冷缓存和暖缓存行为，检查服务器计时，并将异常与CDN和源站日志关联。工具： 请求监控器、浏览器网络面板、CDN/源站可观测性工具和Lighthouse瀑布图。完成条件： 优先级URL返回预期的200响应，无意外跳转或超时，每个慢速或失败的响应都有记录在案的发现和负责人。

4. 诊断最大内容绘制

做什么： 确定最大内容绘制 （LCP）元素，并将其时间分解为服务器延迟、资源发现、资源下载和渲染延迟。LCP衡量最大可见图像或文本块完成渲染的时间。原因： 如果浏览器发现图像较晚，压缩图像收效甚微；而前端更改无法消除缓慢的源站等待时间。方法： 检查追踪和瀑布图，比较缓存和未缓存的运行，检查预加载优先级、响应式图像大小、阻塞渲染的资源、字体行为和客户端渲染。工具： Lighthouse、浏览器性能工具、请求瀑布图和图像检查工具。完成条件： 为每个失败的模板命名实际的LCP元素和主要子部分，拥有可重复的基准测量值和具体的修复假设。

5. 诊断下次交互后绘制

做什么： 测试下次交互后绘制 （INP）路径上的真实操作，如菜单打开、筛选、加入购物车、表单输入和同意弹窗关闭。INP测量从用户交互到浏览器显示下一个视觉更新的延迟，使用访问期间的一个高延迟交互。原因： 页面可能看起来已完成加载，但JavaScript占用主线程时仍会忽略用户操作。方法： 重现重要交互，检查长任务和事件处理程序，测试第三方脚本，并区分输入延迟、处理时间和呈现延迟。工具： CrUX、浏览器性能追踪、交互分析工具和真实设备。完成条件： 每个重要交互都已被执行，针对失败的模板识别出慢速交互和负责的任务，修复方案配有可重复的交互测试。

6. 诊断累计布局偏移

做什么： 定位导致累计布局偏移 （CLS）的意外移动。CLS是一个无量纲分数，表示页面生命周期中意外的视觉移动。原因： 延迟出现的横幅、未设置尺寸的图像、换字体的操作、广告或水合组件，可能会移动用户即将点击的链接，并改变自动化提取找到内容的位置。方法： 使用布局偏移区域和胶片条，测试延迟资源和同意状态，检查没有预留尺寸的元素。工具： CrUX、Lighthouse追踪、浏览器渲染诊断和视觉回归捕获工具。完成条件： 每个显著的偏移都有来源元素、触发条件以及预留空间或渲染修复方案；由用户操作直接引起的预期移动需单独记录。

7. 使用FCP分离白屏延迟

做什么： 测量首次内容绘制（FCP），即浏览器渲染第一个文本、图像、画布或SVG内容的时间。原因： FCP可以区分出页面是早期有所进展还是保持空白，尽管它并不证明主要内容已就绪。方法： 比较FCP与TTFB和LCP，然后检查阻塞CSS、字体、脚本、服务器渲染标记和流式行为。工具： CrUX、Lighthouse以及网络/性能追踪。完成条件： 每个慢速FCP都被归因于服务器延迟、渲染阻塞、仅客户端渲染或其他有证据支持的原因，而非仅仅描述为"页面感觉慢"。

8. 按严重程度、影响范围和依赖关系排列发现

做什么： 按失败区间、受影响流量和模板、业务关键性以及上游依赖关系对积压工作排序。原因： 修复五个黄色分数可能消耗整个迭代周期，而一个红色TTFB失败延迟了源站上的每个页面。方法： 首先处理可靠性失败，然后处理差指标（优先于需改进指标）；在相同严重程度内，先修复共享平台原因和TTFB，再进行下游LCP工作。工具： 发现登记表、分析工具、模板清单和工程估算。完成条件： 每个发现都有严重程度、受影响的URL数量或模板范围、证据、负责人、工作量、依赖关系和明确的优先级。

9. 在实验室中验证实施效果

做什么： 在相同条件下比较更改后的构建与记录的基线。原因： 现场数据无法提供即时的发布反馈，而不可重复的"之后"运行无法确定代码更改导致了差异。方法： 运行多个受控样本，比较中位数而非单次最佳运行，检查追踪以发现回归，测试关键交互和布局。工具： Lighthouse、浏览器性能工具、预发布环境或受控生产发布、以及请求监控。完成条件： 预期原因已被消除，目标指标在多次重复运行中通过约定的实验室预算，其他关键指标未出现回归，证据已附加到发现中。

10. 标注发布并等待现场确认

做什么： 记录部署时间、范围、预期指标和验证日期。原因： CrUX采用滚动28天窗口，因此修复发布后发布前的访问仍会出现在报告百分位数中。方法： 立即监控错误，随着新数据到达检查方向的趋势变化，仅在发布后足够多的天数代表窗口时才进行最终比较。工具： 部署日志、AmICited Web Vitals、CrUX和监控工具。完成条件： 即时技术检查通过，发布标注可见，并存在指定的负责人和日期用于现场确认；不得仅凭实验室证据将发现标记为"已验证"。

AmICited中的工具

打开 https://app.amicited.com/audit/web-vitals，使用真实用户CrUX数据将你的域名与跟踪的竞争对手进行比较。审计将LCP、INP、CLS、FCP和TTFB放在一个表格中，标记你的域名，并使缺失的现场数据可见而非显示为误导性的零值。使用比较回答两个问题：域名是否通过已发布的阈值，以及面向同一受众的竞争对手是否展示了明显更好的现场结果。

性能影响 功能将页面级性能与引用位置和可能性关联起来。将这种关系视为优先级证据，而非速度单独导致引用变化的证明。如果一慢速的被引用页面和快速的非引用页面在权威性、相关性和内容方面存在差异，那么性能只是变量之一。有用的信号是，受影响的页面值得修复和监控。

有关产品操作，请遵循如何在AmICited中检查核心网页指标 。本手册定义了审计范围、决策和交接；教程涵盖操作步骤和读数，在此重复会造成两份内容漂移。

判定规则：什么算作差

基于第75百分位数的现场数据判定核心网页指标 。“好"意味着p75值等于或低于良好阈值。处于边界上的值属于较优区间；例如，LCP恰好为2.5秒属于好。辅助的FCP和TTFB阈值指导诊断和验收，但它们不属于三个指标的核心网页指标通过评估。

使用以下优先级规则：

1. 失败的请求、超时和无效响应优先于分数。 可靠性是交付关卡。
2. 先修复"差"区间，再修复"需改进"区间。 红色代表已证实的糟糕体验，而非优化机会。
3. 当TTFB失败时，先修复TTFB再修复LCP。 响应开始前LCP无法发生，因此后端延迟在浏览器渲染任何内容之前就消耗了LCP预算。
4. 优先处理共享原因而非孤立症状。 一个跨四个模板的缓存策略修复，优于四个影响范围更小的独立图像调整。
5. 在相同严重程度内，优先考虑流量和旅程价值。 差的结账INP或高流量文章LCP，优先级高于同一区间的低流量存档页面。
6. 不要将空白的CrUX值视为好。 它是未知的。在获得现场数据量之前，使用可重复的实验室证据和可比较的模板。
7. 不要承诺即时现场数据变化。 立即验证部署，然后让滚动窗口替换旧体验，再接受或拒绝现场结果。

交付物：性能修复登记表

向工程团队交付一份登记表及其证据文件夹。电子表格、问题追踪器或结构化的项目表格均可接受，前提是保留以下字段并允许按模板、严重程度、负责人和状态进行筛选：

编号和发现：
受影响的URL和模板：
优先级旅程和流量背景：
指标和现场区间：
CrUX级别、p75值和28天窗口：
实验室配置和重复基线：
观察到的原因和证据参考：
预期条件和目标：
建议的更改：
严重程度和优先级理由：
负责人、依赖关系和工作量：
发布日期和标注：
实验室即时验收结果：
现场确认日期和结果：
状态：待处理 | 已计划 | 实验室验收 | 现场已验证 | 已接受风险

附上URL矩阵、CrUX导出数据、实验室追踪、瀑布图、胶片条、交互记录、布局偏移证据和发布注释。按原因去重：如果同一个未缓存的源站查询导致三个模板的TTFB都较差，则应创建一个父级发现并包含三个受影响范围，而非三个相互竞争的不同诊断。

“已接受风险"需要指定的审批人、原因、受影响范围、过期或审查日期以及监控条件。它不能替代负责人。交接完成的条件是：工程师能够重现失败，下一阶段负责人能够识别哪些结果仍受性能限制。

常见错误

将Lighthouse视为最终判决。 一次实验室运行获得100分并不覆盖较差的p75现场数据。应将Lighthouse作为诊断证据，CrUX作为总体人群证据。

只测试首页。 每个高价值模板及一个重型示例都应采样，否则模板缺陷将逃过审计。

在检查TTFB之前优化LCP图像。 图像可能已经很小，而源站却在花费两秒生成HTML。应将LCP分解为各个组成部分，首先修复上游时间。

使用单次最快运行。 缓存温度、后台活动和网络变化可能产生美化了的离群值。保持配置不变，比较多次重复运行的中位数。

发布次日即宣布胜利。 实验室可以证明代码和交付立即发生了变化；但28天现场窗口无法做到。标注发布并安排现场验收。

将缺失的CrUX数据标记为零。 没有数据意味着未达到合格条件或流量阈值。这与性能质量无关。

追逐综合分数而非失败的体验。 总结分数可能提高，而结账交互仍然停滞或英雄横幅仍然偏移。应接受命名的指标和旅程，而非表面上的分数变动。

为赢得测试而移除有用功能。 从实验室变体中删除同意、个性化、分析或可访问性行为，会产生用户永远不会收到的结果。应优化生产要求或做出明确的产品决策。

忽略目标指标之外的回归。 延迟脚本可以改善LCP，但可能造成首次交互时的INP差；为错误的尺寸预留空间可能将加载延迟转变为CLS。应重新测试所有五个指标和关键旅程。

下一阶段：AI可访问性与智能体就绪度

AI可访问性与智能体就绪度 阶段接收代表性URL矩阵、响应可靠性证据、TTFB分布、未解决的性能发现以及说明哪些内容出现在初始响应中的陈述。其负责人使用这些证据区分访问策略失败与交付失败，并重现智能体获取页面的真实条件。

当关键URL响应可靠，且没有未解决的性能缺陷使检索证据无法解释时，下一阶段可以继续进行。当需改进指标影响用户但不妨碍稳定访问时，可以在附带书面限制的条件下继续进行。当请求超时、返回间歇性错误或主要响应经常超过约定的关键阈值时，应暂停受影响模板的推进。

交接完成的条件是：下一阶段负责人知道哪些URL代表每个模板、测试条件、剩余的交付失败，以及P3证据是否已经解释了慢速智能体抓取。

常见问题解答

常见问题解答