译 the cost of JS

原文

当咱们构建的网页大量依赖于Javascript，咱们有些时候须要研究那些不太容易看得见的消耗。在这篇文章中,我将介绍为何一点规则能够帮助若是你想让你的网站加载&是交互式快速移动设备上。

Network 网络

当大多数的开发者考虑Javascript的代价时，他们主要考虑的是下载和实行的消耗。在线上派遣更多的字节的JavaScript须要更长的时间用户的链接。https://cdn-images-1.medium.c...*U00XcnhqoczTuJ8NH8UhOw.png

这是一个问题,即便在发达国家,做为有效的网络链接类型用户可能不会是3g, 4g或WiFi。你多是在一个咖啡店连着2G的热点。

你能够减小网络传输Javascript带来的代价：

• 只传输用户须要的 代码分离能够起效。
• 使用minify文件（ babel-minify or uglify-es for ES2015）
• 压缩（Brotli, gzip or Zopfli ) Brotli对gzip在压缩比例上效果显著。 它帮助CertSimple节约了17%的JS字节和LinkedIn节约了4%的加载时间。
• 移除不须要的代码 DevTools检测代码覆盖率。对于单独的代码 如 tree-shaking, Closure Compiler的高级优化，库插件 lodash-babel-plugin，Webpack的ContextReplacementPlugin像Moment.js 使用babel-preset-env & browserlist来避免在现代浏览器中已经被转换的特性。高级开发人员可能会仔细分析他们的Webpack捆绑包，以帮助肯定减小没必要要依赖。
• 缓存来减小网络传输 肯定脚本的最佳生存期(max - age)&提供验证令牌(ETag)，以免传输未更改的字节。服务人员缓存可使您的应用程序网络具备弹性，并使您可以访问V8的代码缓存等特性。了解关于文件名散列的长期缓存。

工具(https://cdn-images-1.medium.c...*8Spf9To8dzTG3Xy9s57oVA.png)

Parse/Compile 解析

一旦下载下来，JavaScript最大的开销之一就是使用JS引擎来解析/编译此代码。在Chrome DevTools中，解析和编译是性能面板中黄色“脚本”时间的一部分。

自底向上/调用树容许查看准确的解析/编译时间:
https://cdn-images-1.medium.c...*GdrVt_BTTzzBOIoyZZsQZQ.png

为何这是一个问题？
https://cdn-images-1.medium.c...*Dirw7RdQj9Dktc-Ny6-xbA.png

https://cdn-images-1.medium.c...*Dirw7RdQj9Dktc-Ny6-xbA.png

花很长时间解析/编译代码会极大地延迟用户与站点交互的速度。您发送的JavaScript越多，在您的站点进行交互以前解析和编译它的时间就越长。

https://cdn-images-1.medium.c...*6Y665hpxfWNMu2EXu3VGlw.png

Byte-for-byte, JavaScript is more expensive for the browser to process than the equivalently sized image or Web Font — Tom Dale

意思就是 对于浏览器来讲，JS比同等大小的图片和web字体更昂贵。

与JavaScript相比，处理至关大小的图像须要花费大量的成本(它们仍然须要被解码!)，可是在普通的移动硬件上，JS更有可能对页面的交互性产生负面影响。

JS VS image: https://cdn-images-1.medium.c...*PRVzNizF9jQ_QADF5lQHpA.png

当咱们讨论解析和编译速度慢时，执行环境很重要，咱们讨论的普通手机。用户能够是拥有慢CPU和GPU的手机没有L2/L3缓存，甚至多是内存受限。

Network capabilities and device capabilities don’t always match up. A user with an amazing Fiber connection doesn’t necessarily have the best CPU to parse and evaluate JavaScript sent to their device. This is also true in reverse..a terrible network connection, but a blazing fast CPU. — Kristofer Baxter, LinkedIn

JavaScript中启动性能,我注意到在低,高端的硬件上解析~ 1 mb解压(简单的)JavaScript的成本。在市场上最快的手机和普通手机之间解析/编译代码存在有2-5x的时间差别。

真实的网站如CNN，在高端手机iPhone8上花费约4s解析和编译CNN的JS，而普通手机（moto G4) 花费约13s.这速度能够显著影响用户与这个网站的交互。

这强调了平均测试硬件的重要性(如Moto G4)而不是你口袋里的手机。然而环境问题:优化设备和网络环境的用户。

分析能够提供深刻了解实际用户访问你的网站使用移动设备。这能够提供机会了解真正约束CPU /GPU他们的操做。

Are we really sending down too much JavaScript?

使用HTTP存档(~ 500 k网站)来分析JavaScript在移动设备上的状态,咱们能够看到50%的网站花费14秒去响应交互。这些网站仅仅为了解析和编译JS花了4秒。

https://cdn-images-1.medium.c...*sVgunAoet0i5FWEI9NSyMg.png

从页面中删除非关键的JavaScript能够减小传输时间、cpu密集型解析和编译以及潜在的内存开销。这也有助于让你的页面更快捷。

执行时间 Execution Time

执行时间:https://cdn-images-1.medium.c...*ec0wEKKVl7iQidBks3oDKg.png
不只仅是解析和编译花费时间。 JavaScript执行(运行代码一次解析/编译)的操做,必须在主线程上。 长的执行时间也能够推出用户于这个网站的交互时间。

If script executes for more than 50ms, time-to-interactive is delayed by the entire amount of time it takes to download, compile, and execute the JS — Alex Russell

为了解决这个问题，Javascript能从小块中获益，以免锁定主线程。探索你是否能减小在执行过程当中完成的工做量。

模式用于减小JS的代价

当你试图保持解析JavaScript /编译&网络传输时间慢,模式像基于路径分割或PRPL能够起到帮助。

PRPL是经过积极互动的模式,优化代码分隔和缓存。

PRPL 模式
https://cdn-images-1.medium.c...*VgdNbnl08gcetpqE1t9P9w.png

让咱们来可视化下它带来的影响。

咱们能够分析普通手机上的网站加载时间和使用V8运行回调的渐进式应用。咱们能够看到解析时间(橙色所示)是一个重要的部分,不少的这些网站自由支配本身的时间

wego 网站是使用了PRPL， 设法保持低解析时间的路线,让互动很是快。面的许多其余网站采用代码分隔和绩效预算试图下降JS成本。

其余花销

JS在其余方面影响网页性能：

• 内存 页面会出现闪避或因为GC(垃圾收集)带来的常常性暂停。当浏览器回收内存,JS执行停了下来，因此浏览器常常收集垃圾能够暂停执行比咱们可能更频繁。避免内存泄漏和频繁的gc暂停继续页面闪避。
• 在运行过程当中，长时间运行的JavaScript能够阻塞主线程致使页面没有响应。分割成小块(使用requestAnimationFrame()或requestIdleCallback(调度))能够最小化响应问题

进步的Bootstrapping

许多网站优化内容的可见性是以昂贵的交互为代价。当你有大量的JS块时，为了得到快速的渲染，开发者经常采用server-side渲染方式。而后当JS最终被取出时，upgrade附加事件？？

请注意： 这有内在的花销。1）一般发送更大的HTML响应,能够推进咱们的交互性 2）可使用户在一个恐怖谷理论？？ 一半的性能是不能实际交互的要等到JS彻底处理结束。

Progressive Bootstrapping多是一个好方法。发送一个最小功能的页面（包含实行当前功能的JS/HTML/CSS）。当更多的资源到达时，应用能够lazy-load 和释放更多的特征。

合理的加载代码是一个圣杯。PRPL和渐进的引导模式能够实现这种想法。

总结

传输大小对低端网络相当重要。解析时间为CPU绑定的设备是很重要的。保持低这些问题。

团队发现采用严格的绩效预算成功地减小了他们的JavaScript传输和解析/编译时间。Alex Russell’s Can yo afford it?: Real-world Web Performance Budgets

若是你在构建一个目标设备是移动端的，尽力发展典型的硬件上,下降你的JavaScript解析/编译时间,采用绩效预算,以确保你的团队可以关注他们的JavaScript成本。