Web 性能入门指南-1.6 持续的网络性能监控

网络性能最难的部分不是让您的网站更快，而是保持网站速度。经常听说一家公司投入大量精力优化其网站，但几个月后却发现其网页速度又回到了原点。持续测试（使用网络性能预算来创建护栏）是解决方案。

**现实情况是，网站速度虽然至关重要，但也很容易被忽视。**它不像模糊的图像或布局问题那样引人注目。如今用于构建网站的大多数现代工具和框架都很容易使这个问题变得更加严重。

让性能在整个开发过程中更加清晰可见是公司可以做的最关键的事情之一。我们需要工具来帮助我们避免发布会导致意外回归的代码。

回归监控

如今，大多数工具的默认立场是让您能够更轻松地随时向您的网站或应用程序添加代码。（嘿，npm install。）他们几乎不重视的是让您意识到您正在做的事情会对您的性能产​​生负面影响。

为了解决这个问题，我们需要找到将监控纳入工作流程的方法，以帮助我们注意到何时存在导致性能下降的风险。幸运的是，我们有一些工具可供使用。

性能指标阈值监控

虽然单靠性能阈值监控并不能确保良好的性能，但我们还没有看到一家公司在不使用某种性能指标监控的情况下长期维持性能。

性能监控是**团队同意不超出的一个或多个性能指标的明确限制。**然后，该监控用于对潜在回归发出警报、在检测到回归时中断部署以及指导设计和开发决策。

大多数 Web 性能工具都带有一些默认的性能监控，但您需要自己重新评估一次（可能每 2-4 周一次），以确保您设置的监控指标符合您的实际情况。我们正在寻找“出现回归时发出警报”和“不要发出太多警报以致我们开始忽略警报”之间的平衡。

这是最近 KickStart 合作的一个例子。（KickStart 是 咨询项目 ，我们帮助公司设置和运行监控。）JS 脚本的预算设置为 2000 毫秒（这是红线），但该网站远远低于监控指标，这样监控指标设定的毫无用处，他们必须有超过 500% 的回归才能触发任何类型的警报！

我们最终根据当时过去两周的数据将预算设置为 375 毫秒。这使我们能够在出现回归时收到警报，而不会产生警报疲劳。

从图表来看，如果他们继续保持目前的趋势，下次重新评估预算时，他们可能会将预算再降低一点，因为最近的一些变化似乎已经带来了改善。

一旦通过 Slack 或电子邮件收到回归警报，团队就可以立即着手解决问题，以免问题开始影响更广泛的用户体验。如果没有精细调整的警报，多个小的回归问题会累积起来，并开始影响业务指标。

代码更改的自动测试

另一个重要的保障是当代码发生更改时进行自动化性能测试。同样重要的是，这些测试结果应该显示在开发过程中的某个地方——开发人员所在的地方。 每次都要求团队在另一个工具中寻找结果会增加不必要的摩擦。

一个很好的方法是让每个拉取请求都触发自动测试，然后将结果直接放回到拉取请求的详细信息中以便于审查。

出于这个原因，我们非常喜欢使用 CI/CD 工具，例如 Github 集成 。无需更改任何代码，您就可以在每个拉取请求上设置自动性能测试。（如果您不使用 GitHub，也可以使用 部署 API 来触发自动测试。）

现在，当团队更改代码时，他们会在拉取请求审查过程中立即获得性能反馈，从而有助于将性能放在首位。

性能防护栏

实际上，我们不需要登录太多次。我们已经设置了性能预算和基于部署的测试。我们只需等待收到警报，然后开始修复问题。- Patrick Hamann，《金融时报》

性能不是修复一次就能置之不理的事情。随着页面内容和结构的改变，我们需要持续关注性能。

性能防护栏帮助我们全面了解正在发生的事情。

• 性能监控 让我们能够针对关键指标设置阈值并发出警报，这样我们就能立即知道是否存在问题

• 自动化代码测试 将性能信息直接呈现在开发人员面前，使用相同的性能预算清楚地表明每次代码更改的影响

• 将自动化测试与详细的测试结果相结合 ，确保开发人员能够深入研究并快速识别回归的来源

• 在与这些部署以及其他变更相关的历史图表中显示注释，可确保整个团队全面了解性能可能发生转变的原因

设置适当的防护栏来防止性能回退，然后与一系列追踪线索相结合，以便在发生回退时，我们能够深入其中并迅速识别问题的根源，这是确保我们的网站快速且持续保持这种状态的关键步骤。