5G 有可能会使 Web 明显变慢

作者：Scott Jehl

翻译：疯狂的技术宅

原文：https://www.filamentgroup.com...

未经允许严禁转载

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。 我们需要审核自己的脚本库，并定期审查第三方集成，因为有许多包被放弃或只是短暂的使用。 也许我们甚至可以删除旧的第三方脚本，看看是否有人抱怨。 我们可以测试自己对跟踪和个性化的依赖，像纽约时报那样提供常规的、无特定目标的广告实际上也可以增加收入（如果是这样，请删除不再需要的脚本）！ 我们可以运行 Calibre 和 SpeedCurve 等服务来监控我们的绩效预算，让团队中的每个人都参与到绩效流程中。 我们应该尽一切努力让团队成员了解他们自己对所有角色的影响。

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

---

本文首发微信公众号：前端先锋

欢迎扫描二维码关注公众号，每天都给你推送新鲜的前端技术文章

欢迎继续阅读本专栏其它高赞文章：

• 深入理解Shadow DOM v1
• 一步步教你用 WebVR 实现虚拟现实游戏
• 13个帮你提高开发效率的现代CSS框架
• 快速上手BootstrapVue
• JavaScript引擎是如何工作的？从调用栈到Promise你需要知道的一切
• WebSocket实战：在 Node 和 React 之间进行实时通信
• 关于 Git 的 20 个面试题
• 深入解析 Node.js 的 console.log
• Node.js 究竟是什么？
• 30分钟用Node.js构建一个API服务器
• Javascript的对象拷贝
• 程序员30岁前月薪达不到30K，该何去何从
• 14个最好的 JavaScript 数据可视化库
• 8 个给前端的顶级 VS Code 扩展插件
• Node.js 多线程完全指南
• 把HTML转成PDF的4个方案及实现

---

• 更多文章...