目前业内有个大部分人都赞同的观点：网络相比较 15 年前速度更慢，而且错误更多。由于不断增加的 JavaScript、框架、Webfonts 和 polyfills，已经抵消了更快的计算性能、网络和协议带来的优势。那么实际情况真的如此吗？

开发者 Lars Eidnes 加载了全球排行前 100 万的网站，追踪每个量化指标，并记录了每个错误、关注每个请求的 URL。他创建首个将网络性能、错误和库联系起来的数据库。而在本文中，他对这些数据进行了分析，并帮助站长找到创建高性能网站的合适方法。

为什么要加载 100 万个网页?

正如文章开头所提及的，当前网络真的要比 15 年前更慢了吗? 开发者 Lars Eidnes 试图找到 2020 年网络速度变慢以及出现崩溃的主要原因。

这个计划非常简单：编写一个网页浏览器的脚本，让它加载渲染前 100 万个域名的主页面，然后按照目前可以量化的指标进行追踪：包括渲染时间、请求次数、，重绘，JavaScript错误， 使用的库等等。

对这些数据进行分析之后，我们能够更深入的了解不同因素之间的影响。例如，哪些因素导致页面加载时间过长？哪些库和长时间的可交互时间（Time to Interactive，简称 TTI）有关？最常见的错误是什么？是什么原因导致的？

总体情况

开发者使用 Puppeteer 编写了一个 Chrome 脚本，启动了 200 个 EC2 实例，并在周末的时候加载渲染 100 万个网站。整体数据如下：

HTTP 2 现在比 HTTP 1.1 更常见，但 HTTP 3 仍然很少见。(注意：我们把任何使用QUIC协议的东西都算作HTTP 3，即使Chrome有时会报告为HTTP 2 + QUIC)。这是对根文件而言，对于链接资源，协议号看起来有些不同。

对于链接资源，HTTP 3 的普及率大约是 HTML 文档情况下的 100 倍。这怎么可能是真的呢？因为所有的网站都在链接同样的东西。

在很大一部分网站上都有少量的脚本链接。这意味着我们可以期待这些资源在缓存中，对吗？不再是了。从Chrome 86开始，从不同域请求的资源 将不共享缓存。火狐正在计划实现同样的功能。Safari多年来一直这样分割缓存。

那么，是什么让网络变得缓慢？预测交互时间（Predicting time-to-interactive）

鉴于这个网页的数据集和它们的加载时间指标，如果能了解一些关于是什么让网页变慢的信息就更好了。对此，开发者重点研究了 dominteractive 指标，也就是文档成为用户互动之前的时间。最简单的做法是，我们只需要看看每个指标与 dominteractive 的相关性。

基本上每个指标都与 dominteractive 呈现正相关的关系，除了 0.x 和 1.x 版本之外。这些指标中的许多指标之间也是正相关的。我们需要一个更复杂的方法来了解导致高交互时间的各个因素。

其中有些指标是时间，以毫秒为单位。我们可以看一下他们的框图，了解浏览器的时间都花在哪里。导致长互动时间的各个因素的一种方法是做一个线性回归，我们从其他指标预测 dominteractive。

也就是说，我们给每个指标分配一个权重，将一个页面的 dominteractive 时间建模为其他指标的加权和，再加上一些常数。优化算法设置权重，使整个数据集的预测误差最小化。通过回归发现的权重大小，可以告诉我们每个指标对页面加载缓慢的影响有多大？

开发者从回归算法中排除时间指标。如果我们花了 500ms 建立连接，就会给 dominteractive 增加 500ms，但这并不是一个特别有趣的见解。时间指标从根本上说是结果。我们希望了解是什么原因导致了它们。

括号中的数字是优化算法学习的回归系数。您可以将这些数字解释为具有毫秒的单位。虽然确切的数字应该带着盐分（见下面的注释），但看到分配给每个特征的比例是很有趣的。

例如，该模型预测，每当传递主文档所需的重定向时，会有354ms的减速。每当主HTML文档通过HTTP2或更高版本交付时，模型预测的交互时间会降低477ms。对于文档触发的每一个请求，它预测了额外的 16ms。

在解释回归系数时，我们需要记住，我们是在现实的简化模型上操作。事实上，交互时间并不是由这些输入指标的加权和决定的。显然，模型没有机会发现一些因果因素。混淆变量显然是一个问题。

举个例子，如果用HTTP2加载主文档与通过HTTP2加载其他请求是相关的，那么模型会把这个优势渲染到 main_doc_is_http2_or_greater 的权重中，即使速度的提升来自主文档以外的请求。当我们将模型所说的内容映射到关于现实的结论时，我们需要谨慎。

不同 HTTP 协议版本对 dominteractive 的影响有多大？

这里有一个有趣的图，dominteractive 按用于传递 HTML 主页面的 HTTP 协议版本来划分。有极少数网站仍然通过 HTTP 0.9 和 1.0 交付。而这些网站恰好都很快。似乎我们无法脱离这样一个事实：协议变得更快的效果是，程序员会很乐意通过向浏览器交付更多的东西来消耗这种加速。

这是对用于交付HTML根基页面的协议版本而言。如果我们看一下协议对该文档中链接的资源的影响呢？如果我们按协议版本对请求次数进行回归，就会得到以下结果。

如果我们相信这一点，我们就会得出这样的结论：将请求的资源从HTTP 1.1移到2上，速度会加快1.8倍，而从HTTP 2移到3上则会慢 0.6 倍。HTTP 3真的是一个较慢的协议吗？不是：更可能的解释是 HTTP 3 很少见，通过HTTP 3发送的少数资源（如Google Analytics）是对dominteractive影响大于平均水平的东西。

不同类型的内容对 dominteractive 的影响有多大？

我们从传输的字节数来预测dominteractive的时间，按照传输的数据类型来划分。在这里，请求是按照发起请求的内容来划分的。显然，并不是所有的请求都是平等的。由链接元素触发的请求（即CSS、favicons）和由CSS触发的请求（即字体、更多CSS）以及脚本和iframe会大大减慢速度。

在XHR和fetch上做请求会预示着比基线dominteractive时间更快（可能是因为这些请求几乎都是异步的）。CSS和脚本经常以渲染阻塞的方式加载，所以发现它们与较慢的交互时间相关联也就不足为奇了。视频的成本相对较低。

经验教训

我们在这里并没有发现任何新的优化技巧，但分析确实让人了解到各种优化所能带来的影响情况。以下说法似乎有很好的经验支持。

● 尽可能少地提出请求 请求的数量比传输的千字节数更重要。

● 对于你必须要做的请求，如果可以的话，通过HTTP2或更高版本来做。

● 尽量避免渲染阻塞请求，尽可能选择异步加载。