【译】Web 页面的体积膨胀了 10 年，我们学到了什么？

我多年来一直在写有关页面大小和复杂性的文章。如果你在性能领域工作了一段时间，当你听到我开始谈论页面增长时，我完全理解你会想要逃跑。;)

但页面的大小和复杂性每年都在增加，而这种增长并没有完全被更快的设备和网络，或者我们辛勤工作的浏览器所缓解。显然，我们需要继续讨论这个问题。我们需要理解不断增长的页面如何对我们不利，并制定策略来理解和管理我们的页面。

当我们谈论页面大小时，我们指的是什么？

页面大小是指页面的整体重量和复杂性，具体包括：

• 大小：页面总重量（以字节计）。大小尤其对有流量限制或计量的移动用户至关重要。
• 资源：页面上的资源总数。资源越多，复杂性越高，出现渲染延迟和阻塞的可能性就越大。
• HTML：通常是页面上最小的资源，其性能风险通常可以忽略不计。不过，最近我发现一个页面的HTML大小因为大量内联JavaScript急剧增加，导致渲染延迟，所以关注HTML大小仍然是个好主意。
• 图像：往往是页面膨胀的最大贡献者。在页面重量的第90百分位中，图像占约8.2 MB页面的5.7 MB，几乎占总页面重量的75%。此外，页面上的图像数量与零售网站的转化率下降有关（稍后详细说明）。
• JavaScript：即使页面的JS体积相对较小，仍可能存在JS引发的性能问题。即使是一个100 KB的第三方脚本也可能给页面带来严重影响。脚本越多，风险越大。仅关注阻塞JavaScript是不够的，因为即便没有阻塞资源，JavaScript的渲染方式仍可能导致性能问题。因此，了解页面上的CPU使用情况至关重要，因为JavaScript的CPU消耗超过了所有其他浏览器活动的总和。当JavaScript阻塞CPU时，浏览器无法响应用户输入，导致页面“卡顿”，即令人烦躁的页面渲染不稳定感。
• CSS：像JavaScript一样，CSS不需要过于庞大也能造成问题。执行不良的样式表可能导致从下载和解析时间过长到阻塞页面渲染等一系列问题。此外，CSS文件越多，潜在问题就越大。

页面膨胀如何损害你的业务？

几年前我参与的一项谷歌机器学习研究发现，页面元素的总数量是转化率的最大预测因素，而页面上图像的数量是第二大预测因素。
我们还发现，在一个会话中，页面上的脚本数量越多，转化的可能性越小。

图像大小也是一个问题，过多的图像重量会影响你在谷歌图片搜索中的SEO排名。考虑到图片搜索占谷歌搜索的26%以上，这点值得重视。

今天的页面有多大，与十年前相比如何？

在讨论这些数据之前，先说明几点背景和注意事项：

• 这些数据来自HTTP Archive，数据收集方式随着时间有所变化。但可以确定的是，页面的确变得越来越大了。
• 视频数据被故意排除，因为这些数据不一致，且在本文中优先级较低。
• 这些数据不应作为你网站的基准。即使你的页面比这些数据小，或者比这些数据大，也不能简单判断好坏。
• 不是所有页面都在变大，有些页面在这几年里实际上变小了，也许你的网站就是其中之一。

1. 现在桌面页面的中位数大小是十年前的3倍

我已经观察这些数据超过十年，所以这种增长并不让我惊讶。中位数大小为2159 KB，与我每周检查的大量页面情况大致相符。

2. 图像和JavaScript占总页面重量的三分之二

可以预料的是，页面大小的增长主要由图像和JavaScript驱动。图像占据中位数桌面页面重量的44%（约945 KB），JS则占23%（约500 KB）。)

3. 移动页面的中位数大小是十年前的近7倍

服务于移动用户的页面也经历了大幅增长。中位数大小为1984 KB，略小于桌面页面的2159 KB。虽然大而快速的页面是有可能的，但我们仍应关注页面膨胀对移动用户的影响，尤其是那些使用低CPU设备或带宽受限的移动用户。

4. 图像和JavaScript占据了移动页面的大部分重量

我们为移动用户提供了约876 KB的图像和453 KB的脚本，占总页面重量的67%。JavaScript大量消耗CPU，尤其是对于低性能设备用户，这点非常令人担忧。如果你依赖用户使用新设备，可能需要重新考虑这一点。近年来，智能手机的更换周期越来越长，这一趋势似乎将继续下去。

5. 第90百分位的页面非常庞大，主要由图像重量构成

仅关注中位数是不够的，你还应关注90百分位用户群体。虽然10%的用户听起来不多，但如果你的网站每月有1000万访客，那意味着有100万用户的体验非常糟糕。
90百分位的桌面页面大小为8271 KB，包含177个资源。页面重量的近75%由图像占据，总计超过5 MB。

90百分位的移动页面稍微小一点，为7574 KB，包含168个资源。

6. 桌面页面的资源数量多年保持不变

无论是中位数还是90百分位的数据都显示资源数量相对稳定。事实上，这让我有些惊讶。我原以为随着页面总大小的增长，资源数量也会显著增加。

7. 但移动页面的资源数量在增加

这并不意外。我们早已远离十年前为移动用户提供的简化页面。

8. 图像请求大幅减少，但图像大小大幅增加

虽然我们提供的图像数量减少了，但这些图像是高分辨率的，或者未经优化。如今的中位数页面包含25张图像，而2012年这一数字为42张。虽然图像请求数量急剧下降，但总大小几乎增加了三倍，从331 KB增至945 KB。

这种趋势也延续到了移动端。图像请求数量保持不变，但总图像大小几乎增加了6倍——从151 KB增至876 KB。

9. JavaScript请求数量翻倍，而JS体积几乎增加了四倍

我们提供的脚本比以往更多，带来了性能风险，同时页面的JS体积达到500 KB。

移动页面稍微好一些，JS体积为453 KB。

10. 桌面和移动页面的CSS请求数量都增加了一倍以上

更多的样式表意味着更高的性能退化风险。页面上的CSS数量需要关注，因为有问题的CSS可能阻止页面其他部分渲染。

页面膨胀如何影响核心网页指标（Core Web Vitals）？

Google 的核心网页指标是一组旨在从用户体验角度衡量性能的指标。虽然页面总大小和重量不会直接影响核心网页指标，但你需要仔细考虑所提供资源的数量和大小。

最大内容渲染 (LCP)

最大内容渲染（LCP）衡量页面上最大可见元素的渲染时间。页面膨胀可能导致以下问题影响LCP时间：

• 缓慢或阻塞的脚本和样式表会延迟图像的渲染开始时间。
• 未优化的图像加载时间过长。LCP包括图像渲染的整个时间。如果图像在1秒时开始渲染，但需要4秒才能完全渲染，则LCP时间为5秒，未达到Google设定的2.5秒阈值。

首次输入延迟 (FID)

首次输入延迟（FID）衡量页面响应用户交互的速度。输入延迟通常发生在浏览器的主线程忙于解析和执行大型JavaScript文件时。

很多页面上都有不必要的JS文件，正如上文所提到，JS文件的体积逐年增加。页面上的JS越多，FID变慢的可能性就越大。Tim Kadlec 在他的演讲中提到：

“JavaScript 是网络上每字节最昂贵的资源，而且我们的网站使用它的量比以往更多。即使你优化交付、解析和执行，你也永远无法让它比不使用JS的情况更高效。”

累计布局偏移 (CLS)

累计布局偏移（CLS）衡量页面的视觉稳定性。它基于一个公式，简而言之，它计算页面中视觉内容在视口中的偏移量和偏移距离。CLS帮助你理解页面是否会为用户带来“卡顿”的体验。

CLS受到页面资源数量和这些资源的加载时间和方式的强烈影响。例如，Sears.com 的CLS得分为1.0468，而Google推荐的得分为0.1或以下。也就是说，这是一个非常“卡顿”的页面！
这些截图突出了最重要的视觉元素变化:

image.png

不出所料，虽然这个页面的总体大小（接近 3 MB）并不算太大，但它包含了大量的请求。在这 559 个请求中，大部分是图片（175 个请求）、JavaScript（140 个请求）和“其他”（133 个请求）。

查看同一页面的瀑布图，我们可以看到：

• 16 个请求在页面开始渲染前完成
• 52 个请求在最大内容渲染（Largest Contentful Paint）前完成
• 62 个请求在最大布局偏移（与 CLS 相关的指标）前完成

这确实是很多请求！

大页面能否提供良好的用户体验？

可以。虽然页面大小可能是实际性能问题的预警信号，但如果你关注用户体验，你需要仔细查看页面的构建方式，判断页面的大小和复杂性是否真的影响了用户感受到的加载速度。

仅看总请求数和页面大小这些粗略的指标是不够的，你还需要了解：

• 有多少请求是阻塞请求？
• 如果页面包含阻塞请求，它们中有多少位于关键渲染路径中？也就是说，有多少阻塞请求会在页面关键指标（如开始渲染和最大内容渲染）之前出现？
• 多少潜在问题请求来自第三方？你如何保持对这些请求性能的可见性？
• 页面上最重要的图像是否是首先渲染的？它们显示的速度有多快？

亚马逊是提供大型、快速页面的一个很好的例子。在最近的行业页面速度基准测试中，亚马逊首页在开始渲染时间方面表现最佳。尽管页面包含 410 个请求，总大小达到 4,311 KB——远超前面提到的中值大小——但页面的开始渲染时间仅为 0.3 秒，最大内容渲染时间为 0.48 秒，CLS 分数为 0.1526。

从亚马逊的瀑布图细节中可以看出原因。虽然在最大内容渲染（Largest Contentful Paint）之前加载了 38 个资源，但其中只有一个是阻塞渲染的，并且这些资源都非常轻量。

关键点总结

我遇到过很多负责构建和优化网站的人。当我们查看他们页面的构建方式时，往往会看到他们对页面中的一些问题感到惊讶，比如幽灵脚本、大量未优化的图像以及他们没有意识到的阻塞资源。这些人都很聪明，问题并不在于他们，而在于网站的规模、发布周期的速度以及触及每个页面的人数。

我们不可能回到 1999 年之前的轻量化、低于 1MB 的网页时代。但我们可以重新控制现有的页面。

1. 理解每个页面的关键渲染路径
   你的页面上可能有很多不必要的垃圾文件，其中一些还未被优化。太多的内容会让你无法看到整体问题。你可以拥有体积大、复杂的页面，但仍然能让它们感觉很快。良好用户体验的关键是快速传递最重要的内容。这里有一些用于分析和优化关键渲染路径的优秀资源。

2. 确保每个接触页面的人都了解其行为对性能的影响
   再多的高级性能监控工具，如果组织内没有强大的性能文化，也是无法帮助你的。这里有一些帮助你在这条路上前进的提示和最佳实践。

3. 防止性能回退
   页面膨胀通常发生在人们不再关注的时候。我们需要持续地监控页面。将性能测试集成到 CI/CD 过程中是防止性能回退的好方法，特别是如果你结合了性能预算。通过为关键指标（如开始渲染、最大内容渲染以及各种页面大小和重量的指标）设定性能预算，当这些指标超出界限时，你可以收到提醒。

4. 不要假设硬件和网络会缓解页面膨胀
   虽然一些用户可能拥有更新的设备和快速的网络，但并不是所有人都这么幸运。如果你使用了真实用户监控工具，请关注第 75 和 95 百分位的性能指标，这样你就能了解网站在较差环境下的表现。