5G 的小图标开始逐渐出现在世界各地的手机屏幕上。如果你已经开始使用了,可能会注意到,感觉上其速度并没有超过 4G 一大截,我同意这个观点。据了解,这是因为初期基础设施过渡的阻碍,但随着它的成熟,预计 5G 会极大的提高网络速度。在2019年预测的下载速度为平均每秒 100M 到 1G 比特。以这样的速度,你下载朋友的整个唱片的时间与现在加载一个页面的时间差不多。未来是令人惊讶的!

而且这不只是增加了带宽。延迟也将通过 5G 得到改善,延迟一直是 Web 臭名昭着的性能瓶颈之一。这意味着我们首次访问某个网站时,进行连接的时间可能会明显降低。 同样,太神奇了!

所以,网络性能的提升代表更快的速度。这应该能过解决网络的性能问题吧?

应该是这样,但我认为不会,至少不是很快。如果按照最近的趋势继续下去,对于一般的人来说 5G 可能会使 Web 性能更糟,而不是更好

更差?怎么会?!

更快的网络应该可以解决性能问题,但到目前为止,他们对 Web 产生了一种有趣的、无意识的影响。这是因为从历史上看,更快的网络速度使开发人员能够向用户提供更多代码 —— 特别是更多的 JavaScript 代码

在2011年至2019年期间,全世界 4G 覆盖率从5%扩大到79%。在同一时期内,传输给移动设备的 JavaScript 平均大小中位数增加了611%,从 52kb 增加到 372.9 KB。当然,这是一种相关性,许多因素促成了这种增长。是的,在此期间,网站也变得更加互动,这可能会导致 JavaScript 使用量的增加。此外,响应式设计得到了广泛使用,这意味着许多站点开始向所有设备发送单个 JavaScript 负载。但要明确的是,2011 年的“桌面”网站平均只比移动版本的网站多发送了大约 50kb 的JavaScript。一般来说,从那时起,UI 模式在网络上的变化并不大。例如,我们有幸帮助建立了 2010 年推出的高度跨设备的 Boston Globe 网站,而今天的新闻网站也有相似的感觉。最后,这种趋势仍在继续:即使在过去几年中,JavaScript 的平均传输大小也增加了 50% 以上。

在我们去讨论 JavaScript 框架之前,这些增加似乎并不完全是因为 Web 的用户界面功能。 实际上大部分来自第三方脚本 706% 的增幅。 可以肯定的是,这些第三方请求可能是 JavaScript 框架,但大多数情况下,它们是跟踪器、A/B 库、个性化脚本、广告和聊天机器人,所有这些都经常会启动第四方和第五方的请求。

因此,随着网络的改进,JavaScript 规模也在不断膨胀。 不过你可能会认为,如果所有这些代码的下载速度足够快,它就相对无害了吧? 好吧,不幸的是并没有。 与我们提供的其他类型的代码相比,JavaScript 的大小是独一无二的。

因此,JavaScript 的规模激增的 Web 得到了改善。不过,你可能会认为,如果所有的代码下载速度不够快,这是相对无害的,对不对?唉,可惜没有。相比于其他种类的,我们提供的代码,JavaScript是唯一昂贵的它的重量。

“在我的手机上看上去很好”

对开发人员的便利很容易让我们误入歧途。

在目前仍在使用的普通设备上,200kb 的 JavaScript(压缩用于传输)可能需要6秒或更长时间才能解析 —— 这不包括在通过网络下载代码所花费的时间内。 这听起来像是一个很大的 JavaScript,请记住,就平均而言,我们实际提供的功能几乎是它的两倍。 在对 JavaScript 解析期间,网页可能是可见的但不能交互,或者它可能完全是空白的(如果脚本是以阻止页面渲染的典型方式进行引用的话)。 这两种情况都很糟糕,更令人担忧的是许多在 Web 上工作的人甚至可能都没有注意到这个问题。

普通设备不是上千美元的带有3个镜头的全新 iPhone。 即使在美国,普通设备也是你在亚马逊畅销产品上看到的那种设备,大约 130 美元一个。它可能是一部 iPhone,更有可能是较旧的设备,最有可能的是处理器相对不足的中档 Android。

即使人们用上了新的快速网络,他们也很可能会对我们发送的代码感到窒息,从而使 5G 的速度提升失去意义。

那些没有 5G 的人呢?

5G 的覆盖需要更新大规模的基础设施,并且可能会首先部署在富裕的发达地区。在的农村和发展中地区不太可能很快用上 5G。 这意味着非 5G 地区的人们不仅会在他们动力不足的设备上体验 Web,而且他们还会通过旧的 3G 或 4G 网络下载越来越多的代码。

该怎么办?

这个问题出在我们身上。 是的,我们需要更好地确定资源交付的优先顺序,但最重要的是,我们需要停止提供如此多的 JavaScript。 我们需要审核自己的脚本库,并定期审查第三方集成,因为有许多包被放弃或只是短暂的使用。 也许我们甚至可以删除旧的第三方脚本,看看是否有人抱怨。 我们可以测试自己对跟踪和个性化的依赖,像纽约时报那样提供常规的、无特定目标的广告实际上也可以增加收入(如果是这样,请删除不再需要的脚本)! 我们可以运行 CalibreSpeedCurve 等服务来监控我们的绩效预算,让团队中的每个人都参与到绩效流程中。 我们应该尽一切努力让团队成员了解他们自己对所有角色的影响。

随着网络的改进,有一个巨大的机会来改善我们构建的 Web,要么抓住这个机会,要么浪费它。