[图]网络比15年前更慢错误更多?开发者加载了100万个网站实测

2020年12月28日 13:52 次阅读 稿源:cnBeta.COM 条评论

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

访问:

京东PLUS会员元旦大促:视频双会员148元 送30元无门槛红包

阿里云“爆款特惠”主题活动- 云服务器低至0.55折 96元/年

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

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

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

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

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

总体情况

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

k9xny1fj.jpg

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

ifz9ybwa.jpg

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

41vs538s.jpg

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

那么,是什么让网络变得缓慢?预测交互时间(Predicting time-to-interactive)

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

qco1jtnn.jpg

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

g9cksjzx.jpg

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

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

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

jkeo7un1.jpg

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

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

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

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

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

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

rp93kbl9.jpg

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

79co38ee.jpg

如果我们相信这一点,我们就会得出这样的结论:将请求的资源从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或更高版本来做。

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

对文章打分

[图]网络比15年前更慢错误更多?开发者加载了100万个网站实测

2 (6%)
已有 条意见

    最新资讯

    加载中...

    今日最热

    加载中...

    热门评论

      阿里云免费试用频道

      Top 10

      招聘


      Advertisment ad adsense googles cpro.baidu.com
      created by ceallan