Fast load times系列翻译——性能预算 101

Fast load times系列翻译——性能预算 101

性能与用户体验的重要组成部分，这也是业务指标的一部分。我们都认为，如果是一名优秀的程序员，都是以开发一个优秀性能的站点为目标，但是事实上很少人能做到。和大多数事情一样，要实现一个目标，你必须先去清晰地定义它，这可以从设置一个性能预算开始。

定义

**性能预算就是对影响站点性能的各种指标施加一组限制。它可以是页面的总体积，可以是移动页面网络加载速度，甚至是发送 HTTP 请求的数量。它可以作为设计、技术和决策的参考点。

有了预算，设计师就可以衡量高分辨率图像的效果以及他们选择的 web font 的数量。它还能帮助开发人员比较解决问题的不同方法，并根据库的大小和解析和评估它们。

选择指标

基于数量（Quantity-based metrics）

这个指标对于开发的早期会比较有用，因为它强调了重的图片和 JavaScript 包的影响。这也很容易让设计人员和开发人员相互协调。

我们刚刚已经提到了一些可以当做性能预算的内容，比如页面大小和 HTTP 请求数量，但是我们可以为它们设置更细的粒度，例如：

• 图片的最大大小
• web fonts 的最大数量
• 包括框架，脚本的最大大小
• 外部资源最大总量，例如第三方库

然而，这些数字并不能影响太多用户体验的内容。两个相同 HTTP 请求、相同大小的页面，可能会根据请求资源的顺序不同而展现不同的渲染过程。如果其中一个页面上的关键内容（例如关键图片或样式）在进程中加载较晚，用户将会等待更长的时间才能看到有用的内容，相当于页面“变慢了”。

这就是另一个指标：里程碑时间 很重要的原因

里程碑时间（Milestone timings）

里程碑时间记录了页面加载时发生的事件，例如：DOMContentLoaded 或 load event。最有用的事件是 以用户为中心的性能指标,它能告诉你加载页面的一些关键内容。这些内容可以通过浏览器 API 来获取，也可以从 Lighthouse 中获得。

首次内容渲染（First Contentful Paint (FCP) ）用来衡量浏览器首次显示 DOM 的第一部分内容，如文本和图像

首次可交互时间（Time to Interactive (TTI)）用来衡量页面完全可响应用户的输入所花费的时间。如果你要在页面是进行任何交互动作，如链接、按钮、输入或使用表单，这是非常重要的指标。

基于规则

Lighthouse 和 WebPageTest 是基于普遍的最佳实践规则，你可以以他们为指标。此外，Lighthouse还为你提供了简单的优化提示。

建立基准线

实践是检验真理的唯一标准，想要真正知道适合你的网站的优化方法就是尝试它，研究它，然后测试你发现的问题。分析方法之间的差异，分别看看它们表现如何。

当然，如果你没有时间，这里有一些很好的默认数字来帮助你入门：

• 首次可交互时间小于 5 秒
• 关键渲染路径资源小于 170 kb（压缩后）

这些数字是根据真实世界的基准设备和 3G 网络速度计算的。现在超过一半的站点请求发生在移动设备上，所以你应该使用3G网络速度作为基准线。

举个例子

你应该为网站上不同类型的页面制定适当的预算，因为它们的内容是不同的。例如

• 手机端产品展示的页面 JavaScript 大小必须小于 170 KB
• 搜索页面的图像大小必须小于 2MB
• 主页页面在 Moto G4 手机上用 慢速3G 加载并在 5s之内首次可交互
• 博客页面（产品介绍页面？）的 Lighthouse 得分必须 > 80

将性能预算添加到构建过程中

选择的工具取决于你的项目规模和项目的资源：

• 使用 webpack
• bundlesize
• Lighthouse CI

当某项内容超出了预期的阈值，那么你可以：

• 优化现有的功能和资源
• 删除当前的功能或资源
• 不添加新功能或资源

性能追踪

如果要保证你的网站足够快，那你必须一致追踪测量它的性能。随着时间的推移和从实际用户获取的数据，我们可以看到性能的变化是如何影响业务指标的。

译者的话

这篇文章普及了一下页面的渐进式渲染，我们可以很直观地了解到渐进式渲染的优点，它有更快的速度和更好的用户体验。

但是这篇文章的主旨其实是让我们了解到一种优化用户体验的途径，就是把加载分段。用里程碑时间的形式来将加载分为首次内容渲染和首次可交互，并分别为它们设置基线。总的来说是一篇介绍文章。
欢迎关注我的个人微信公众号：前端 stack，每周分享一篇外文技术翻译哦

---

原文链接：https://web.dev/performance-budgets-101/