JavaScript 启动性能瓶颈分析与解决方案

1顶
0踩

2017-02-20 10:27 by 副主编 jihong10102006 评论(0) 有3846人浏览

javascript

在 Web 开发中，随着需求的增加与代码库的扩张，我们最终发布的 Web 页面也逐渐膨胀。不过这种膨胀远不止意味着占据更多的传输带宽，其还意味着用户浏览网页时可能更差劲的性能体验。浏览器在下载完某个页面依赖的脚本之后，其还需要经过语法分析、解释与运行这些步骤。而本文则会深入分析浏览器对于 JavaScript 的这些处理流程，挖掘出那些影响你应用启动时间的罪魁祸首，并且根据我个人的经验提出相对应的解决方案。回顾过去，我们还没有专门地考虑过如何去优化 JavaScript 解析/编译这些步骤；我们预想中的是解析器在发现<script>标签后会瞬时完成解析操作，不过这很明显是痴人说梦。下图是对于 V8 引擎工作原理的概述：

下面我们深入其中的关键步骤进行分析。

到底是什么拖慢了我们应用的启动时间？
在启动阶段，语法分析，编译与脚本执行占据了 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 语法解析与编译是否成为了大部分网站的瓶颈？
我曾不止一次听到有人说，我又不是 Facebook，你说的 JavaScript 语法解析与编译到
底会对其他网站造成什么样的影响呢？对于这个问题我也很好奇，于是我花费了两个月的时间对于超过 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。

更多使用说明参考我的[url="https://gist.github.com/addyosmani/45b135900a7e3296e22673148ae5165b"]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 会允许所有的脚本，即使阻塞型的<script src=''>脚本也可以由后台线程进行解析。不过缺陷就是目前仅有一个 streaming 后台线程存在，因此我们建议首先解析大的、关键性的脚本。在实践中，我们建议将<script defer>添加到<head>块内，这样浏览器引擎就能够尽早地发现需要解析的脚本，然后将其分配给后台线程进行处理。我们也可以查看 DevTools Timeline 来确定脚本是否被后台解析，特别是当你存在某个关键性脚本需要解析的时候，更需要确定该脚本是由 streaming 线程解析的。

语法解析 & 编译优化
我们同样致力于打造更轻量级、更快的解析器，目前 V8 主线程中最大的瓶颈在于所谓的非线性解析消耗。譬如我们有如下的代码片：

(function (global, module) { … })(this, function module() { 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 的启动性能，尽我所能！

原文出处： Addy Osmani

查看图片附件

来自: 王下邀月熊_Chevalier

分享到：

1
顶

0
踩

评论共 0 条请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

JavaScript启动性能瓶颈分析与解决方案.docx

跨平台解决方案的技术分析

本文旨在介绍不同跨平台解决方案的技术架构和特点，分析各个解决方案的优势和不足之处，以便对业界当前的跨平台技术方案建立起整体的认知和对团队的技术选型提供一定的参考作用。注意的是，这里的跨平台特指的是...

JavaWeb 并发编程与高并发解决方案

在这里写写我学习到和自己所理解的 Java高并发编程和高并发解决方案。现在在各大互联网公司中，随着日益增长的互联网服务需求，高并发处理已经是一个非常常见的问题，在这篇文章里面我们重点讨论两个方面的问题，一...

【高并发解决方案】秒杀系统架构分析与实战

#0 系列目录#秒杀系统架构秒杀系统架构分析与实战#1 秒杀业务分析#正常电子商务流程（1）查询商品；（2）创建订单；（3）扣减库存；（4）更新订单；（5）付款；（6）卖家发货秒杀业务的特性（1）低廉价格；（2）大幅...

chrome开发者工具_如何使用Chrome开发者工具查找性能瓶颈

您的主要目标是确定Scotch上的性能瓶颈，并进行优化以获得更好的性能。软件工程中的瓶颈描述了一个应用程序的容量受单个组件限制的情况。 In the next step, you will perform an audit to look for performance ...

前端如何进行网站性能分析及优化性能

1.分析网站性能常用的方式 1.1chrome dev Tools 1.2Lighthouse 1.3第三方收费方案 2.介绍一个常用的性能分析工具 LightHouse 2.1 特点： 2.2 使用方式 2.3 代码示例 2.4性能报告 3.准确衡量网站的性能 ...

SpringMVC中的跨域请求配置解决方案

作者：禅与计算机程序设计艺术 1.简介跨域（Cross-origin resource sharing）是由一个资源从一个域名访问另一个不同的域名而发生的一种行为。由于同源策略的限制，默认情况下浏览器禁止从不同域向当前域发送HTTP...

秒杀的架构设计和解决方案

秒杀系统架构分析与实战 1 秒杀业务分析正常电子商务流程（1）查询商品；（2）创建订单；（3）扣减库存；（4）更新订单；（5）付款；（6）卖家发货秒杀业务的特性（1）低廉价格；（2）...

编写高性能JavaScript

很多JavaScript引擎，如Google的V8引擎（被Chrome和Node所用），是专门为...如果你是一个开发者，并且关心内存使用情况与页面性能，你应该了解用户浏览器中的JavaScript引擎是如何运作的。无论是V8，SpiderMonkey

关于 VS Code 优化启动性能的实践

The First Second 这次分享的介绍，CovalenceConf 是一个以 Electron 构建桌面软件为主题的技术会议，这也是 VS Code 团队为数不多的对外分享之一(质量较高)，主要分享了 VS Code 是如何优化启动性能的。...

JavaScript 的性能优化：加载和执行

JavaScript 的性能优化：加载和执行随着 Web2.0 技术的不断推广，越来越多的应用使用 JavaScript 技术在客户端进行处理，从而使 JavaScript 在浏览器中的性能成为开发者所面临的最重要的可用性问题。而这...

WebView性能、体验分析与优化

关于这些问题的解决方案数量可能会比问题还多，而它们也各有优劣。具体分析太过复杂，鉴于篇幅原因在这里不做具体分析了。您可以期待我们的后续计划：BPM（浏览器包管理）。 JS解析、编译、执行在...

5116-微信小程序电影院订票选座系统设计及实现+ssm（源码+数据库+lun文）.zip

本系统主要针对计算机相关专业的正在做毕业设计的学生和需要项目实战练习的学习者，可作为毕业设计、课程设计、期末大作业。本系统主要针对计算机相关专业的正在做毕业设计的学生和需要项目实战练习的学习者，可作为毕业设计、课程设计、期末大作业。本系统主要针对计算机相关专业的正在做毕业设计的学生和需要项目实战练习的学习者，可作为毕业设计、课程设计、期末大作业。本系统主要针对计算机相关专业的正在做毕业设计的学生和需要项目实战练习的学习者，可作为毕业设计、课程设计、期末大作业。

JavaScript 中的 `Array.prototype.filter` 方法全解析

在 JavaScript 编程中，处理数组是一项基本而重要的任务。数组的过滤操作是其中的一个常见需求，Array.prototype.filter 方法为此提供了强大的支持。本文将深入探讨 Array.prototype.filter 方法的工作原理、使用场景、代码示例以及与其他数组方法的比较。 Array.prototype.filter 是 JavaScript 中处理数组的强大工具，它允许开发者以声明式的方式轻松筛选出符合特定条件的元素。通过结合使用 Array.prototype.filter 和其他数组方法，可以解决各种复杂的数据筛选问题。通过本文的详细介绍和示例代码，你应该能够掌握 Array.prototype.filter 的工作原理，并能够在实际开发中灵活运用它来处理数组数据。此外，了解其与 Array.prototype.map 和 Array.prototype.reduce 的结合使用，可以帮助你更好地编写高效且易于维护的代码。

5108-微信小程序的书橱+ssm（源码+数据库+lun文）.zip

5046-微信小程序校园二手交易平台的小程序+ssm（源码+数据库+lun文）.zip

SMT小型视觉贴片机控制系统源码源代码图纸 DI

图书馆自动化管理系统.zip

这是一个基于Apache kafka、Docker Compose、MongoDB和Flask技术的图书馆自动化管理系统。该项目旨在实现图书馆的各项服务自动化，包括图书借阅、预约和搜索功能。通过Flask构建REST API，使用MongoDB存储和管理图书、用户、借阅记录、罚款和预约等相关数据。apache Kafka用于系统各组件之间的消息通信，确保消息传递的可靠性和可扩展性。项目还实现了用户认证和授权功能，通过JWT进行安全认证和授权。每个对系统服务的请求都需要使用JWT进行验证。项目提供了全面的文档，解释了系统架构、数据库模式和API端点。同时，项目明确了所有依赖关系，并提供了环境搭建指南，便于其他开发者轻松复制环境。此外，项目还包含测试用例，以确保关键功能的正常运行。 1、资源项目源码均已通过严格测试验证，保证能够正常运行； 2、项目问题、技术讨论，可以给博主私信或留言，博主看到后会第一时间与您进行沟通； 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用，尤其对于人工智能、计算机科学与技术等相关专业，更为适合； 4、下载使用后，可先查看README.md文件（如有），本项目仅用作交流学习参考，请切勿用于商业用途。

【前景培训教材】第九章4G和5G信令流程.pdf

以下是对提供的参考资料的总结，按照要求结构化多个要点分条输出： 4G/5G无线网络优化与网规案例分析： NSA站点下终端掉4G问题：部分用户反馈NSA终端频繁掉4G，主要因终端主动发起SCGfail导致。分析显示，在信号较好的环境下，终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理，尝试关闭节电开关等。 RSSI算法识别天馈遮挡：通过计算RSSI平均值及差值识别天馈遮挡，差值大于3dB则认定有遮挡。不同设备分组规则不同，如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效：某5G站点开启100M+60M CA功能后，测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误，修正后测试正常。 5G网络优化与策略： CCE映射方式优化：针对诺基亚站点覆盖农村区域，通过优化CCE资源映射方式（交织、非交织），提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网：与三扇区组网相比，AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同，需根据具体场景选择适合的组网方式。 5G语音解决方案：包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略，如NSA和SA，并影响语音连续性和网络覆盖。 4G网络优化与资源利用： 4G室分设备利旧：面对4G网络投资压减与资源需求矛盾，提出利旧多维度调优策略，包括资源整合、统筹调配既有资源，以满足新增需求和提质增效。宏站RRU设备1托N射灯：针对5G深度覆盖需求，研究使用宏站AAU结合1托N射灯方案，快速便捷地开通5G站点，提升深度覆盖能力。基站与流程管理：爱立信LTE基站邻区添加流程：未提供具体内容，但通常涉及邻区规划、参数配置、测试验证等步骤，以确保基站间顺畅切换和覆盖连续性。网络规划与策略：新高铁跨海大桥覆盖方案试点：虽未提供详细内容，但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划，需考虑信号穿透、移动性管理、网络容量等因素。总结：提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。通过具体案例分析，展示了无线网络优化中的常见问题及解决方案，如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。强调了5G网络优化与策略的重要性，包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。提出了4G网络优化与资源利用的策略，如室分设备利旧、宏站RRU设备1托N射灯等。基站与流程管理方面，提到了爱立信LTE基站邻区添加流程，但未给出具体细节。新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。

1顶0踩