共计 2565 个字符，预计需要花费 7 分钟才能阅读完成。
作者：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 个方案及实现
- 更多文章 …
