现在我们建立网站时越来越依赖 JavaScript ,我们有时会在不经意间付出高昂的代价。如果您希望您的网站在移动设备上快速加载和交互,那么在这篇文章中,我将介绍为什么一些简单的规则可以帮你做到这一点。
简而言之:较少的代码=较少的解析/编译+较少的传输+较少的解压缩
当大多数开发人员考虑 JavaScript 的开销时,他们会考虑下载和执行开销。 发送更多字节的 JavaScript 需要的时间越长,用户的连接越慢。
即使在第一世界国家,这也是一个问题,因为用户有效的网络连接类型实际上可能不是 3G,4G 或 WiFi 。 你可能在咖啡店 WiFi ,连接到2G速度的蜂窝热点。
您可以 减少 JavaScript 的网络传输开销:
上图为减少向用户发送的JavaScript的最佳实践。
一旦下载完成后, JavaScript 最高昂的 开销之一就是 JS 引擎 解析/编译 代码的时间。在 Chrome DevTools的 Performance(性能) 面板中,解析和编译是黄色的 “Scripting” 时间的一部分。
Bottom-Up / Call Tree 可以让你查看确切的解析/编译时间。
上图为 Chrome DevTools “Performance(性能)” 面板 > Bottom-Up。 通过启用 V 8的 Runtime(运行时)调用统计,我们可以看到解析和编译等阶段上花费的时间。
但是,为什么会这样呢?
花费很长时间解析/编译代码会严重延迟用户与你网站进行交互的时间。你发送的 JavaScript 越多,在网站交互之前,解析和编译的时间也就越长。
.
一个字节一个字节的解析和编译, 浏览器处理 JavaScript 比同等大小的图像或 Web 字体开销更昂贵 — Tom Dale
与 JavaScript 相比,在处理相同字节大小的图片时会有大量的开销(他们仍然需要解码!)。但是在大多数移动硬件上,JS 更可能负面影响页面的交互性。
相同字节的 JavaScript 和 图像 的开销是不同的。图像通常不会阻塞主线程,也不会阻止界面在解码和光栅化时进行交互。然而,由于解析、编译和执行的开销,JS 会延迟交互。
当我们谈论解析和编译变慢的时候, 上下文很重要 – 我们在这里谈论的是普通手机。 普通用户可以使用CPU和GPU速度较慢的手机,无L2 / L3缓存,甚至可能会受到内存限制。
网络速度和设备功能并不总是相匹配。具有惊人速度的光纤连接用户不一定有最好的CPU来解析和评估发送到他们的设备的 JavaScript 。反过来亦是如此。一个糟糕的网络连接,但拥有一个快速的CPU。- Kristofer Baxter,LinkedIn
在 JavaScript Start-up Performance中,我注意到在低端和高端硬件上解析〜1MB解压缩(简单)JavaScript的开销。 在市场上最快的手机和普通手机之间,解析/编译代码的时间有2-5倍的差异。
在不同类别的桌面和移动设备上,解析1MB的JavaScript包(约250KB gzip)。 当查看解析的开销时,解压后的数据就可以被推断,例如〜250KB压缩的JS解压缩到〜1MB的代码。
那么现实世界中的网站是怎样的呢,如CNN.com?
在高端的iPhone 8上,解析/编译 CNN 的 JS 大约需要花费 4 秒,而普通手机(Moto G4)则需要13秒。 这可以显著的影响用户与本网站进行完全交互的速度。
比较苹果公司的A11仿生芯片和更大众的Android硬件中枭龙617的解析时间。
这突显了在普通硬件(如Moto G4),而不仅仅是你口袋里的手机上测试的重要性。 但是,上下文很重要:针对你的用户的设备和网络条件进行优化。
分析可以深入了解访问你网站的真实用户的移动设备类型 。这可以让你推断他们正在使用的真正的 CPU / GPU 约束。
我们是否真的发送了太多的 JavaScript ?错误,是有可能:)
使用 HTTP Archive (最高 ~500K 站点) 分析 移动设备上的JavaScript 的情况,我们可以看到 50% 的网站需要 14s 才能进行交互。这些网站花费长达4秒,只是解析和编译 JS 。
在获取和处理 JS 和 其他资源时需要花费时间,在感觉页面已经准备好使用之前,用户可以等待一段时间,这是正常现象。 我们一定可以在这里做得更好。
从网页中删除非关键的 JavaScript 可以减少传输时间,CPU密集型解析和编译以及潜在的内存开销。 这也有助于让你的网页更快地可进行交互。
不仅仅是解析和编译可能会带来开销。 ** JavaScript 执行**(分析/编译代码后就运行)是主线程上必须发生的操作之一。很长的执行时间也会影响网站的可交互时间。
如果脚本执行时间超过50ms,则交互时间将会延迟的时间是 下载,编译和执行JS所需的时间总和 – Alex Russell
为了解决这个问题,JavaScript受益于小的代码块(chunk),以避免锁定主线程。 探索是否可以减少执行过程中正在进行的工作。
当您试图保持JavaScript的解析/编译和网络传输时间较慢时,有一些模式可以帮助你像基于路由的分块(chunk) 或 PRPL。
PRPL是一种通过积极的代码分割和缓存优化交互性的模式:
让我们看看它可以产生的影响。
我们使用V8的运行时(Runtime) 调用统计来分析流行移动网站和 Progressive Web Apps(PWA) 的加载时间。正如我们所看到的,解析时间(以橙色显示)是许多这些站点花费时间的重要部分:
Wego 是一个使用PRPL的站点,设法保持较低的路线解析时间,交互速度非常快。 上面的许多其他站点都采用代码分解和性能预算来降低JS的开销。
JavaScript 可以通过其他方式影响页面性能:
许多网站将内容可视性作为交互性的开销来优化。当你有大量的 JavaScript 包时,为了获得一个快速的首屏展示,开发者有时会使用服务器端渲染;然后在 JavaScript 获取完成时,将其以附加事件处理程序的方式“升级”。
小心 – 这种方式也有自己的开销。你 1)通常发送一个更大的html响应,这可以提高页面的交互性,2)将用户置于一个离奇的山谷中,直到JavaScript完成处理之前,首屏以外的页面不能交互。
渐进式引导可能是一个更好的方法。 发送一个最小功能的页面(由当前路由所需的 HTML / JS / CSS 组成)。随着更多的资源加载完成,该应用程序可以延迟加载和解锁更多的功能。
渐进式引导 视图 by Paul Lewis
根据视图加载代码是非常好的建议。 PRPL 和 渐进式引导(Progressive Bootstrapping) 是可以帮助实现这一模式。
传输字节大小对于低端网络来说至关重要的因素。 解析时间对于设备CPU来说也很重要。尽量的减少这些开销是很重要的。
团队发现成功采用严格的性能预算来保持其 JavaScript 传输和解析/编译时间较低。请参阅Alex Russell的“Can You Afford It?: Real-world Web Performance Budgets”,以获取关于移动端优化的指导。
考虑一下我们制作的架构决策可以为应用程序逻辑留下多少JS“空间”。
如果您正在构建针对移动设备的网站,请尽可能在代表性硬件上开发,保持较低的 JavaScript 解析/编译时间,并采用性能预算,以确保您的团队能够关注其 JavaScript 性能开销。
来源: http://www.css88.com/archives/8396