在 Web 开发中，随着需求的增长与代码库的扩张，咱们最终发布的 Web 页面也逐渐膨胀。不过这种膨胀远不止意味着占据更多的传输带宽，其还意味着用户浏览网页时可能更差劲的性能体验。浏览器在下载完某个页面依赖的脚本以后，其还须要通过语法分析、解释与运行这些步骤。而本文则会深刻分析浏览器对于 JavaScript 的这些处理流程，挖掘出那些影响你应用启动时间的罪魁祸首，而且根据我我的的经验提出相对应的解决方案。回顾过去，咱们尚未专门地考虑过如何去优化 JavaScript 解析/编译这些步骤；咱们预想中的是解析器在发现 <script>标签后会瞬时完成解析操做，不过这很明显是痴人说梦。下图是对于 V8 引擎工做原理的概述：react
下面咱们深刻其中的关键步骤进行分析。chrome
究竟是什么拖慢了咱们应用的启动时间？浏览器
在启动阶段，语法分析，编译与脚本执行占据了 JavaScript 引擎运行的绝大部分时间。换言之，这些过程形成的延迟会真实地反应到用户可交互时延上；譬如用户已经看到了某个按钮，可是要好几秒以后才能真正地去点击操做，这一点会大大影响用户体验。缓存
上图是咱们使用 Chrome Canary 内置的 V8 RunTime Call Stats 对于某个网站的分析结果；须要注意的是桌面浏览器中语法解析与编译占用的时间仍是蛮长的，而在移动端中占用的时间则更长。实际上，对于 Facebook, Wikipedia, Reddit 这些大型网站中语法解析与编译所占的时间也不容忽视：安全
上图中的粉色区域表示花费在 V8 与 Blink's C++ 中的时间，而橙色和黄色分别表示语法解析与编译的时间占比。Facebook 的 Sebastian Markbage 与 Google 的 Rob Wormald 也都在 Twitter 发文表示过 JavaScript 的语法解析时间过长已经成为了避免可忽视的问题，后者还表示这也是 Angular 启动时主要的消耗之一。网络
随着移动端浪潮的涌来，咱们不得不面对一个残酷的事实：移动端对于相同包体的解析与编译过程要花费至关于桌面浏览器2~5倍的时间。固然，对于高配的 iPhone 或者 Pixel 这样的手机相较于 Moto G4 这样的中配手机表现会好不少；这一点提醒咱们在测试的时候不能仅用身边那些高配的手机，而应该中高低配兼顾：框架
上图是部分桌面浏览器与移动端浏览器对于 1MB 的 JavaScript 包体进行解析的时间对比，显而易见的能够发现不一样配置的移动端手机之间的巨大差别。当咱们应用包体已经很是巨大的时候，使用一些现代的打包技巧，譬如代码分割，TreeShaking，Service Workder 缓存等等会对启动时间有很大的影响。另外一个角度来看，即便是小模块，你代码写的很糟或者使用了很糟的依赖库都会致使你的主线程花费大量的时间在编译或者冗余的函数调用中。咱们必需要清醒地认识到全面评测以挖掘出真正性能瓶颈的重要性。异步
JavaScript 语法解析与编译是否成为了大部分网站的瓶颈？async
我曾不止一次听到有人说，我又不是 Facebook，你说的 JavaScript 语法解析与编译到ide
底会对其余网站形成什么样的影响呢？对于这个问题我也很好奇，因而我花费了两个月的时间对于超过 6000 个网站进行分析；这些网站囊括了 React，Angular，Ember，Vue 这些流行的框架或者库。大部分的测试是基于 WebPageTest 进行的，所以你能够很方便地重现这些测试结果。光纤接入的桌面浏览器大概须要 8 秒的时间才能容许用户交互，而 3G 环境下的 Moto G4 大概须要 16 秒 才能容许用户交互。
大部分应用在桌面浏览器中会耗费约 4 秒的时间进行 JavaScript 启动阶段（语法解析、编译、执行）：
而在移动端浏览器中，大概要花费额外 36% 的时间来进行语法解析：
另外，统计显示并非全部的网站都甩给用户一个庞大的 JS 包体，用户下载的通过 Gzip 压缩的平均包体大小是 410KB，这一点与 HTTPArchive 以前发布的 420KB 的数据基本一致。不过最差劲的网站则是直接甩了 10MB 的脚本给用户，简直可怕。
经过上面的统计咱们能够发现，包体体积当然重要，可是其并不是惟一因素，语法解析与编译的耗时也不必定随着包体体积的增加而线性增加。整体而言小的 JavaScript 包体是会加载地更快（忽略浏览器、设备与网络链接的差别），可是一样 200KB 的大小，不一样开发者的包体在语法解析、编译上的时间倒是天差地别，不可同日而语。
现代 JavaScript 语法解析 & 编译性能评测
Chrome DevTools
打开 Timeline( Performance panel ) > Bottom-Up/Call Tree/Event Log 就会显示出当前网站在语法解析/编译上的时间占比。若是你但愿获得更完整的信息，那么能够打开 V8 的 Runtime Call Stats。在 Canary 中，其位于 Timeline 的 Experims > V8 Runtime Call Stats 下。
Chrome Tracing
打开 about:tracing 页面，Chrome 提供的底层的追踪工具容许咱们使用disabled-by-default-v8.runtime_stats来深度了解 V8 的时间消耗状况。V8 也提供了详细的指南来介绍如何使用这个功能。
WebPageTest
WebPageTest 中 Processing Breakdown 页面在咱们启用 Chrome > Capture Dev Tools Timeline 时会自动记录 V8 编译、EvaluateScript 以及 FunctionCall 的时间。咱们一样能够经过指明disabled-by-default-v8.runtime_stats的方式来启用 Runtime Call Stats。
更多使用说明参考个人gist。
User Timing
咱们还可使用 Nolan Lawson 推荐的User Timing API来评估语法解析的时间。不过这种方式可能会受 V8 预解析过程的影响，咱们能够借鉴 Nolan 在 optimize-js 评测中的方式，在脚本的尾部添加随机字符串来解决这个问题。我基于 Google Analytics 使用类似的方式来评估真实用户与设备访问网站时候的解析时间：
DeviceTiming
Etsy 的 DeviceTiming 工具可以模拟某些受限环境来评估页面的语法解析与执行时间。其将本地脚本包裹在了某个仪表工具代码内从而使咱们的页面可以模拟从不一样的设备中访问。能够阅读 Daniel Espeset 的Benchmarking JS Parsing and Execution on Mobile Devices 一文来了解更详细的使用方式。
咱们能够作些什么以下降 JavaScript 的解析时间？
减小 JavaScript 包体体积。咱们在上文中也说起，更小的包体每每意味着更少的解析工做量，也就能下降浏览器在解析与编译阶段的时间消耗。
使用代码分割工具来按需传递代码与懒加载剩余模块。这多是最佳的方式了，相似于PRPL这样的模式鼓励基于路由的分组，目前被 Flipkart, Housing.com 与 Twitter 普遍使用。
Script streaming: 过去 V8 鼓励开发者使用async/defer来基于script streaming实现 10-20% 的性能提高。这个技术会容许 HTML 解析器将相应的脚本加载任务分配给专门的 script streaming 线程，从而避免阻塞文档解析。V8 推荐尽早加载较大的模块，毕竟咱们只有一个 streamer 线程。
评估咱们依赖的解析消耗。咱们应该尽量地选择具备相同功能可是加载地更快的依赖，譬如使用 Preact 或者 Inferno 来代替 React，两者相较于 React 体积更小具备更少的语法解析与编译时间。Paul Lewis 在最近的一篇文章中也讨论了框架启动的代价，与 Sebastian Markbage 的说法不谋而合：最好地评测某个框架启动消耗的方式就是先渲染一个界面，而后删除，最后进行从新渲染。第一次渲染的过程会包含了分析与编译，经过对比就能发现该框架的启动消耗。
若是你的 JavaScript 框架支持 AOT（ahead-of-time）编译模式，那么可以有效地减小解析与编译的时间。Angular 应用就受益于这种模式：
现代浏览器是如何提升解析与编译速度的？
不用灰心，你并非惟一纠结于如何提高启动时间的人，咱们 V8 团队也一直在努力。咱们发现以前的某个评测工具 Octane 是个不错的对于真实场景的模拟，它在微型框架与冷启动方面很符合真实的用户习惯。而基于这些工具，V8 团队在过去的工做中也实现了大约 25% 的启动性能提高：
本部分咱们就会对过去几年中咱们使用的提高语法解析与编译时间的技巧进行阐述。
代码缓存
Chrome 42 开始引入了所谓的代码缓存的概念，为咱们提供了一种存放编译后的代码副本的机制，从而当用户二次访问该页面时能够避免脚本抓取、解析与编译这些步骤。除以以外，咱们还发如今重复访问的时候这种机制还能避免 40% 左右的编译时间，这里我会深刻介绍一些内容：
代码缓存会对于那些在 72 小时以内重复执行的脚本起做用。
对于 Service Worker 中的脚本，代码缓存一样对 72 小时以内的脚本起做用。
对于利用 Service Worker 缓存在 Cache Storage 中的脚本，代码缓存能在脚本首次执行的时候起做用。
总而言之，对于主动缓存的 JavaScript 代码，最多在第三次调用的时候其可以跳过语法分析与编译的步骤。咱们能够经过chrome://flags/#v8-cache-strategies-for-cache-storage来查看其中的差别，也能够设置 js-flags=profile-deserialization运行 Chrome 来查看代码是否加载自代码缓存。不过须要注意的是，代码缓存机制仅会缓存那些通过编译的代码，主要是指那些顶层的每每用于设置全局变量的代码。而对于相似于函数定义这样懒编译的代码并不会被缓存，不过 IIFE 一样被包含在了 V8 中，所以这些函数也是能够被缓存的。
Script Streaming
Script Streaming容许在后台线程中对异步脚本执行解析操做，能够对于页面加载时间有大概 10% 的提高。上文也提到过，这个机制一样会对同步脚本起做用。
这个特性却是第一次说起，所以 V8 会容许全部的脚本，即便阻塞型的 <scriptsrc=''>脚本也能够由后台线程进行解析。不过缺陷就是目前仅有一个 streaming 后台线程存在，所以咱们建议首先解析大的、关键性的脚本。在实践中，咱们建议将 <scriptdefer>添加到 <head>块内，这样浏览器引擎就可以尽早地发现须要解析的脚本，而后将其分配给后台线程进行处理。咱们也能够查看 DevTools Timeline 来肯定脚本是否被后台解析，特别是当你存在某个关键性脚本须要解析的时候，更须要肯定该脚本是由 streaming 线程解析的。
语法解析 & 编译优化
咱们一样致力于打造更轻量级、更快的解析器，目前 V8 主线程中最大的瓶颈在于所谓的非线性解析消耗。譬如咱们有以下的代码片：
(function(global, module) { … })(this, functionmodule() { my functions })
V8 并不知道咱们编译主脚本的时候是否须要module这个模块，所以咱们会暂时放弃编译它。而当咱们打算编译module时，咱们须要重分析全部的内部函数。这也就是所谓的 V8 解析时间非线性的缘由，任何一个处于 N 层深度的函数都有可能被从新分析 N 次。V8 已经可以在首次编译的时候搜集全部内部函数的信息，所以在将来的编译过程当中 V8 会忽略全部的内部函数。对于上面这种module形式的函数会是很大的性能提高，建议阅读The V8 Parser(s) — Design, Challenges, and Parsing JavaScript Better来获取更多内容。V8 一样在寻找合适的分流机制以保证启动时能在后台线程中执行 JavaScript 编译过程。
预编译 JavaScript？
每隔几年就有人提出引擎应该提供一些处理预编译脚本的机制，换言之，开发者可使用构建工具或者其余服务端工具将脚本转化为字节码，而后浏览器直接运行这些字节码便可。从我我的观点来看，直接传送字节码意味着更大的包体，势必会增长加载时间；而且咱们须要去对代码进行签名以保证可以安全运行。目前咱们对于 V8 的定位是尽量地避免上文所说的内部重分析以提升启动时间，而预编译则会带来额外的风险。不过咱们欢迎你们一块儿来讨论这个问题，虽然 V8 目前专一于提高编译效率以及推广利用 Service Worker 缓存脚本代码来提高启动效率。咱们在 BlinkOn7 上与 Facebook 以及 Akamai 也讨论过预编译相关内容。
Optimize JS 优化
相似于 V8 这样的 JavaScript 引擎在进行完整的解析以前会对脚本中的大部分函数进行预解析，这主要是考虑到大部分页面中包含的 JavaScript 函数并不会马上被执行。
预编译可以经过只处理那些浏览器运行所须要的最小函数集合来提高启动时间，不过这种机制在 IIFE 面前却反而下降了效率。尽管引擎但愿避免对这些函数进行预处理，可是远不如optimize-js这样的库有做用。optimize-js 会在引擎以前对于脚本进行处理，对于那些当即执行的函数插入圆括号从而保证更快速地执行。这种预处理对于 Browserify, Webpack 生成包体这样包含了大量即刻执行的小模块起到了很是不错的优化效果。尽管这种小技巧并不是 V8 所但愿使用的，可是在当前阶段不得不引入相应的优化机制。
总结
启动阶段的性能相当重要，缓慢的解析、编译与执行时间可能成为你网页性能的瓶颈所在。咱们应该评估页面在这个阶段的时间占比而且选择合适的方式来优化。咱们也会继续致力于提高 V8 的启动性能，尽我所能！
【责任编辑：庞桂玉 TEL：（010）68476606】