正文共：1872 字
预计阅读时间：10 分钟
作者：Scott Jehl
翻译：疯狂的技术宅
来源：filamentgroup
5G 的小图标开始逐渐出现在世界各地的手机屏幕上。如果你已经开始使用了，可能会注意到，感觉上其速度并没有超过 4G 一大截，我同意这个观点。据了解，这是因为初期基础设施过渡的阻碍，但随着它的成熟，预计 5G 会极大的提高网络速度。在2019年预测的下载速度为平均每秒 100M 到 1G 比特【https://www.quora.com/How-fast-is-a-5G-network】。以这样的速度，你下载朋友的整个唱片的时间与现在加载一个页面的时间差不多。未来是令人惊讶的！
而且这不只是增加了带宽。延迟也将通过 5G 得到改善，延迟一直是 Web 臭名昭着的性能瓶颈之一。这意味着我们首次访问某个网站时，进行连接的时间可能会明显降低。同样，太神奇了！
所以，网络性能的提升代表更快的速度。这应该能过解决网络的性能问题吧？
应该是这样，但我认为不会，至少不是很快。如果按照最近的趋势继续下去，对于一般的人来说 5G 可能会使 Web 性能更糟，而不是更好。
更差？怎么会？！
更快的网络应该可以解决性能问题，但到目前为止，他们对 Web 产生了一种有趣的、无意识的影响。这是因为从历史上看，更快的网络速度使开发人员能够向用户提供更多代码 —— 特别是更多的 JavaScript 代码。
在2011年至2019年期间，全世界 4G 覆盖率从5％扩大到79％【https://www.ericsson.com/en/mobility-report/mobility-visualizer?f=16&ft=2&r=1&t=2,19&s=14&u=4&y=2011,2019&c=6】。在同一时期内，传输给移动设备的 JavaScript 平均大小中位数增加了611％，从 52kb 增加到 372.9 KB【https://httparchive.org/reports/page-weight#bytesJs】。当然，这是一种相关性，许多因素促成了这种增长。是的，在此期间，网站也变得更加互动，这可能会导致 JavaScript 使用量的增加。此外，响应式设计得到了广泛使用，这意味着许多站点开始向所有设备发送单个 JavaScript 负载。但要明确的是，2011 年的“桌面”网站平均只比移动版本的网站多发送了大约 50kb 的JavaScript。一般来说，从那时起，UI 模式在网络上的变化并不大。例如，我们有幸帮助建立了 2010 年推出的高度跨设备的 Boston Globe 网站，而今天的新闻网站也有相似的感觉。最后，这种趋势仍在继续：即使在过去几年中，JavaScript 的平均传输大小也增加了 50％ 以上。
在我们去讨论 JavaScript 框架之前，这些增加似乎并不完全是因为 Web 的用户界面功能。实际上大部分来自第三方脚本 706％ 的增幅【https://speedcurve.com/blog/javascript-growth/】。可以肯定的是，这些第三方请求可能是 JavaScript 框架，但大多数情况下，它们是跟踪器、A/B 库、个性化脚本、广告和聊天机器人，所有这些都经常会启动第四方和第五方的请求。
因此，随着网络的改进，JavaScript 规模也在不断膨胀。不过你可能会认为，如果所有这些代码的下载速度足够快，它就相对无害了吧？好吧，不幸的是并没有。与我们提供的其他类型的代码相比，JavaScript 的大小是独一无二的。
因此，JavaScript 的规模激增的 Web 得到了改善。不过，你可能会认为，如果所有的代码下载速度不够快，这是相对无害的，对不对？唉，可惜没有。相比于其他种类的，我们提供的代码，JavaScript是唯一昂贵的它的重量。
“在我的手机上看上去很好”
对开发人员的便利很容易让我们误入歧途。
在目前仍在使用的普通设备上，200kb 的 JavaScript（压缩用于传输）可能需要6秒或更长时间才能解析 —— 这不包括在通过网络下载代码所花费的时间内。这听起来像是一个很大的 JavaScript，请记住，就平均而言，我们实际提供的功能几乎是它的两倍【https://httparchive.org/reports/page-weight#bytesJs】。在对 JavaScript 解析期间，网页可能是可见的但不能交互，或者它可能完全是空白的（如果脚本是以阻止页面渲染的典型方式进行引用的话）。这两种情况都很糟糕，更令人担忧的是许多在 Web 上工作的人甚至可能都没有注意到这个问题。
普通设备不是上千美元的带有3个镜头的全新 iPhone。即使在美国，普通设备也是你在亚马逊畅销产品上看到的那种设备，大约 130 美元一个。它可能是一部 iPhone，更有可能是较旧的设备，最有可能的是处理器相对不足的中档 Android。
即使人们用上了新的快速网络，他们也很可能会对我们发送的代码感到窒息，从而使 5G 的速度提升失去意义。
那些没有 5G 的人呢？
5G 的覆盖需要更新大规模的基础设施，并且可能会首先部署在富裕的发达地区。在的农村和发展中地区不太可能很快用上 5G。这意味着非 5G 地区的人们不仅会在他们动力不足的设备上体验 Web，而且他们还会通过旧的 3G 或 4G 网络下载越来越多的代码。
该怎么办？
这个问题出在我们身上。是的，我们需要更好地确定资源交付的优先顺序，但最重要的是，我们需要停止提供如此多的 JavaScript。我们需要审核自己的脚本库，并定期审查第三方集成，因为有许多包被放弃或只是短暂的使用。也许我们甚至可以删除旧的第三方脚本，看看是否有人抱怨。我们可以测试自己对跟踪和个性化的依赖，像纽约时报那样提供常规的、无特定目标的广告实际上也可以增加收入（如果是这样，请删除不再需要的脚本）！我们可以运行 Calibre 【https://calibreapp.com/】和 SpeedCurve 【https://speedcurve.com/】等服务来监控我们的绩效预算，让团队中的每个人都参与到绩效流程中。我们应该尽一切努力让团队成员了解他们自己对所有角色的影响。
随着网络的改进，有一个巨大的机会来改善我们构建的 Web，要么抓住这个机会，要么浪费它。
原文：https://www.filamentgroup.com/lab/5g/
