高效监控网站性能

网站性能优化建议众多，但即使遵循所有建议，你能否保持网站持续优化？是否针对了正确的页面？Matt Zeunert 概述了有效的网站性能优化策略，并解释了不同类型数据在其中扮演的角色。

衡量网站性能的多维度指标

虽然没有单一方法能全面衡量网站性能，但谷歌用作排名因素的核心网页指标是一个很好的起点，它们涵盖了访问者体验的不同方面：

最大内容绘制（LCP）：衡量初始页面加载时间
累积布局偏移（CLS）：衡量渲染后内容是否稳定
下次绘制交互（INP）：衡量页面响应用户输入的速度

此外，还有许多其他网站性能指标可用于跟踪技术方面，如页面重量或服务器响应时间。虽然这些通常不直接影响最终用户，但它们能让你深入了解是什么减慢了页面速度。

你还可以使用用户计时 API 来跟踪网站上特别重要的页面加载里程碑。

合成测试与真实用户数据

网站性能数据有两种不同类型：

合成测试在受控测试环境中运行
真实用户数据从实际网站访问者收集

合成监控可以提供超级详细的报告，帮助你识别页面速度问题。你可以精确配置数据收集方式，选择特定的网络速度、设备尺寸或测试位置。

然而，你的合成测试设置可能无法匹配真实访问者的典型情况，而且你无法编写所有可能的用户交互方式脚本。

这就是为什么你还需要真实用户监控（RUM）。通过 RUM，你可以看到不同的加载时间以及特定访问者群体受到的影响。你可以查看特定的页面视图，以确定导致特定访问者性能差的原因。

同时，由于 Web API 限制和性能考虑，真实用户数据不如合成测试报告详细。

实现快速网站的三个步骤

数据收集在整个网站性能优化生命周期中都很有帮助。你可以遵循这个三步流程：

识别：在整个网站收集数据并识别缓慢的访问者体验
诊断：深入技术分析以找到优化方案
监控：检查优化是否有效，并在性能回归时获得警报

步骤1：识别缓慢的访问者体验

首先，是什么促使你调查网站性能问题？你可能已经有一些具体问题，无论是来自客户报告还是谷歌搜索控制台中核心网页指标部分的低分。

真实用户数据是检查慢页面的最佳位置。它告诉你网站上的技术问题是否真的导致用户体验差。它很容易在整个网站上收集（而合成测试需要为每个 URL 设置）。而且，你通常可以同时获得查看次数和性能指标。一个月只有两个访问者的中等慢速页面不如一天有数千次访问的中等快速页面重要。

你还可以运行网站扫描，从网站地图获取 URL 列表，然后根据谷歌 Chrome 用户体验报告（CrUX）的真实用户数据检查每个页面。但是，这仅适用于达到最低流量阈值以包含在 CrUX 数据集中的页面。

如果没有可用的真实用户数据，可以使用基于谷歌 Lighthouse 工具的扫描工具 Unlighthouse。它为每个页面运行合成测试，允许你筛选结果以识别需要优化的页面。

步骤2：诊断网站性能问题

一旦识别出网站上的慢页面，你需要查看页面上实际发生了什么导致延迟。

调试页面加载时间

如果页面加载时间指标（如 LCP）存在问题，合成测试结果可以提供详细分析。你还可以运行页面速度实验来尝试并衡量某些优化的影响。

真实用户数据在调试页面速度时仍然很重要，因为加载时间取决于许多用户和设备特定因素。例如，根据用户设备的大小，负责 LCP 的页面元素可能会有所不同。RUM 数据可以提供可能影响因素的细分，如 CSS 选择器和图片 URL，帮助你准确找出需要修复的内容。

调试慢交互

通常也需要 RUM 数据来正确诊断与 INP 指标相关的问题。具体来说，真实用户数据可以提供对导致慢交互原因的洞察，帮助你回答以下问题：

哪些页面元素负责？
时间是花在处理已活动的后台任务还是处理交互本身？
哪些脚本对总 CPU 处理时间贡献最大？

你可以从高层次查看这些数据以识别趋势，并查看特定的页面视图以了解影响特定访问者体验的因素。

步骤3：监控性能并响应回归

持续监控网站性能可以让你跟踪更改后性能是否改善，并在分数下降时发出警报。

你如何响应性能回归取决于你查看的是基于实验室的合成测试还是真实用户分析。

合成数据

合成测试的测试设置在运行之间是标准化的。虽然基础设施更改（如浏览器升级）偶尔会引起变化，但性能通常由网站加载的资源和运行的代码决定。

当指标发生变化时，DebugBear 允许你查看两个测试结果之间的前后比较。例如，下一个屏幕截图显示了首次内容绘制（FCP）指标的回归。比较显示，新图片被添加到页面，与其他页面资源竞争带宽。

从报告中可以清楚地看到，之前需要 255 毫秒加载的 CSS 文件现在需要 915 毫秒。由于样式表是渲染页面内容所必需的，这意味着页面现在加载更慢，让你更好地了解需要优化的内容。

真实用户数据

当你看到真实用户指标发生变化时，可能有两个原因：

访问者特征或行为的变化，或
网站上的技术更改

例如，启动广告系列通常会增加重定向、减少缓存命中并改变访问者人口统计。当你看到 RUM 数据回归时，第一步是找出更改是在你的网站上还是在访问者的浏览器中。检查广告系列中的查看次数变化、引荐来源域或网络速度，以获得更清晰的画面。

如果这些访问与典型访问者相比具有不同的性能，那么这表明回归不是由于你网站上的更改。但是，你可能仍然需要在网站上更改以更好地服务这些访问者群体并为他们提供良好体验。

要识别技术更改的原因，请查看组件细分指标，如 LCP 子部分。这有助于你缩小回归原因的范围，无论是由于服务器响应时间的变化、新的渲染阻塞资源还是 LCP 图片。

你还可以检查页面视图属性的变化，如不同的 LCP 元素选择器或导致性能差的特定脚本。

结论

一次性页面速度测试是优化性能的良好起点。然而，像 DebugBear 这样的监控工具可以构成更全面的网站性能策略的基础，帮助你长期保持快速。