前端性能之JavaScript成本（2018）

关于原文

原文是在Medium上面看到的，Chrome工程师Addy Osmani发布的一篇文章，这位的Medium上面的自我介绍里面有一句Passionate about making the web fast，和这篇文章的主体能够说很是契合了。

最近在作一个服务端渲染的项目，到底页面性能的提高可以带来多少的意义，或者到底有多少合理的方法来让精雕细琢移动端的用户体验。

这篇文章主要是部份内容的翻译，而且结合本身的一些想法，以备在项目架构的时候考虑到这些相关的东西。

原文内容会按照引用样式排版

原文-The Cost Of JavaScript 2018

这篇文章很干，干到一张图都不存在，因此想读下去的请作好准备吧~，更推荐直接去读原文哦！！

前言

首先，JavaScript仍旧是咱们发送到用户移动设备上的最昂贵的资源，由于它能够在很大程度上延迟用户的交互。

JavaScript阻塞页面上的交互动做，全部同步执行的JavaScript代码不会中断本身的执行来给忽然触发的交互事件让路，而且若是在交互的时候须要页面样式的变化，也是会被阻塞的。React 16中新加入的Fiber功能，就是为了将同步的re-render操做分片，来让页面的交互能够间歇进行而不是彻底阻塞。关于React Fiber的原理，能够看这一篇：React 16.0 Fiber源码解读。

React在Release Note中也写到了，React 16还有一大进步就是相比起15.6版原本说，其react库压缩到了5.3kb，gzip压缩后能够达到2.2kb，而react-dom库也从141kb压缩到了103.7kb，库大小的减小也可以很好地提高React在客户端的执行速度，在页面首次渲染的时候加载更少的资源。

• 为了保证速度，仅仅加载当前页面必须的JavaScript；
• 提早作好性能预算，而且合理利用；
• 作好JavaScript打包以及代码审计工做；
• 每个交互都是从一个新的“可交互时间”开始的，考虑如何在这种状况下进行优化；
• 若是一段客户端JavaScript并不可以提高用户体验，那么就要问问你本身这段代码是不是必须的。

原文的文章很长，因此放了一个tl;dr:在文章最前面，文章的五个重点都列出来了，如何压榨每个Byte的JavaScript的性能，须要从多个方面考虑可精简的JavaScript。

web因为用户“体验”而膨胀

也许你根本就不知道本身页面中的JavaScript到底占据了多少物理资源来执行，尤为是在移动设备上。目前的现代网页平均会使用250KB的压缩JavaScript，若是没有压缩的话，大概是1MB左右的脚本，这些脚本都须要浏览器来执行，不管是在移动设备仍是PC上面。

在公司网络的环境下，使用lighthouse来对网易云音乐的首页进行检测，从开始HTTP请求一直到页面开始能够交互的时间大概在3s左右，根据5s原则来讲，已是一个很好的体验了，不少元素的延迟加载起到了很好的做用。若是你想看到本身的网页性能到底如何，可使用lighthouse快速生成一个网页性能的检测报告。

移动端用户体验随着JavaScript阻塞交互事件超过14秒以上，逐渐消失。

致使移动端上面代码阻塞时间的主要缘由是移动端CPU的性能以及网络情况。

这里显示的中国并非4G覆盖率很是低，而是没有数据，可是能够看到西欧、北美等地区的4G覆盖率也只是60%~80%之间，并不可以达到基本全覆盖，因此为了这部分3G用户的用户体验，缩减JavaScript压缩后文件的大小也是必然的。

而且移动端设备的性能也是瓶颈之一，智能手机的普及率虽然比较高，可是质量良莠不齐，许多移动端设备还停留在1G甚至512RAM的状况下。

大部分互联网公司都会采用两套web来实现移动端和桌面端，移动端采用高压缩的页面，来减小网络时间和加载时间。

JavaScript存在成本

若是页面有着过多的脚本，那么就须要考虑code-spliting来分开bundle代码，或者经过tree-shaking来减小JavaScript的包袱。

目前咱们的业务项目采用React+Node.js的SSR来进行SEO优化和首屏性能提高。咱们的JS Bundle中有着不少的JavaScript库代码：

• react&& react-dom等客户端框架；
• 大型SPA可选的状态管理解决方案：mobx、vuex、redux、rxjs；
• ES六、ES7等polyfills，为浏览器厂商还债；
• @music等组件库，包括Utils组件以及UI组件。

即便已经完成了code split，首屏加载中，上面的这些库也会有一大部分被加载进来，形成整个项目的JavaScript冗余。

整个页面在加载的时候，有着几个重要的时间节点。

是否开始有内容显示在页面上了。也就是用户可以感觉到本身获得了响应；

是否有完整的内容显示在页面上，也就是可交互的内容已经显示了出来；

是否能够开始进行交互了，也就是意味着用户可以开始对页面进行正常操做。

前两个阶段在服务端渲染的状况下，大部分进行的仍是页面的render操做，render是没有太多办法来对其进行加速的。因此为了提高交互效果，第三阶段是必须着力解决的。不可以产生交互的主要缘由是脚本尚未加载完成，致使了页面阻塞。加速加载和执行，经过减小JavaScript包的大小是可行的方法。

另一种方法是经过SSR，为用户提供更快的首屏渲染速度，而且在以后，将JavaScript注入到页面当中。

经过<script>标签等主进程加载过多的JavaScript会形成阻塞问题，而采用Web Worker进程或者缓存来进行页面脚本的执行可以获得更短的阻塞时间。

咱们估测了Google News的移动端可交互时间，在高端设备上大约是7秒左右，而低端设备则达到了55秒。

中低端设备的JavaScript运行速度远远比我预期的要长不少，因为生活和工做环境中较少接触这类设备，因此这类用户设备的比例是须要进行埋点获取的，若是这类设备的比例较高（在国内是比较有可能发生的），那么就须要为这类用户进行JavaScript的削减或者压缩。

Pinterest将打包后的JavaScript从2.5MB压缩到了小于200KB，响应时间从23秒下降到了5.6秒，这样带来的直接结果就是，他们的收入提高了44%而注册量提高了753%Orz，移动端的周活提高了103%。

咱们须要作的重点是防止JavaScript成为整个网站的瓶颈。

须要记住的是，若是想要让JavaScript变得更快，那么须要作到下面几点：

• 下载快
• 解析快
• 编译快
• 执行快

Parse/Compile

上面是各大网站在V8引擎上面的脚本执行时间图，解析和编译阶段占了总时间的大约10%~30%，在Chrome 66中，V8能够在后台线程编译代码，能够将编译时间减低到大约20%左右，可是也不多见到可以在50ms以内编译完的JavaScript代码。

另外一个要注意的事情就是，JavaScript的大小并不彻底意味着它的时间消耗，一个200KB的图片和一个200KB的JavaScript所占用的时间是彻底不一样的。

二者的下载时间应该是差很少而且和大小强相关的，可是图片须要解码，栅格化以及绘制到屏幕上，而JavaScript代码包须要解析，编译以及执行。JavaScript的时间消耗基本是要大于图片的，这个差距也取决于设备的CPU性能。

根据上述内容，**在进行性能测试的时候，尽可能让环境恶劣起来，不要使用高速的网络环境以及高性能设备来进行测试。**由于用户设备和环境的均值多是你想象不到的。

可变性会杀死用户体验，高性能设备可能会变慢，高速网络也可能会变慢，可变性最终会让全部事情都变慢。

可变性须要让开发人员下降开发时的基准线，来保证每个用户的体验。若是你的团队可以经过一些策略来获知全部访问你的站点的用户环境，那么能够很方便地对于站点的性能兼容性进行测试。在测试的时候，采用用户中具备表明性的网络和设备环境来进行测试。

It's important to know your audience.

• 对于网络，低端网络环境须要更小的JavaScript bundle。这就要求减小代码的冗余、缩小代码体积、而且进行压缩；
• 对于设备，作好对于重复访问数据的缓存工做，解析时间对于低端设备来讲是最重要的。

当咱们的站点愈来愈依赖于JavaScript的时候，咱们有时候就会为了避免容易看见的发送到客户端的代码付出代价。

如何发送更少的JavaScript

这一点的关键在于如何发送最少限度的JavaScript到客户端，而且可以保证用户的正常体验。Code-splitting是其中的重点。

目前来讲，Code-splitting经常使用的方法就是在bundle代码的时候，仅仅返回当前路由对应的相关代码，而不返回整个庞大的代码包。对于路由的切分以及库的引入来讲，这一个原则相当重要。不管什么理由，都尽可能不要将其余路由的代码注入到当前访问的路由当中。路由的懒加载是decrease你的JavaScript加载速度的重点。

import Loadable from 'react-loadable';
const LoadableOtherComponent = Loadable({
    loader: () => import('./OtherComponent'),
    loading: () => <div>Loading...</div>
});
const MyComponent = () => {
    <LoadableOtherComponent />
};
复制代码

在React中添加code-splitting能够经过React Loadable进行，这个库是一个HOC，能够动态加载须要的React组件，而不会在首次渲染的时候就将全部的页面组件都加载进来，即便它暂时不会被使用。

如今也有不少库能够帮助你来定位本身的代码包，来帮助你从代码层面减小JavaScript代码的长度。好比webpack bundle analyzer，source map explorer，bundle buddy。这些工具会审视你的代码，而且找到其中的冗余，大型库以及一些未使用的依赖。

打包审查能够着重于一些大型依赖，或者是给你一个较轻的低位替代。

措施，优化，监控以及重复

若是你不肯定本身的工程代码是否存在这些问题，经过LightHouse能够审查你的站点。

cnpm install -g lighthouse
lighthouse http://yoursites.com
复制代码

快速生成一份站点的性能审查报告。

云音乐主站的审查报告大概是这样的，咱们的移动端主站大概须要3秒左右的时间可以获得交互响应。

因为这篇文章是从个人桌面上淘出来的，因此图彷佛都挂掉了。。有兴趣的能够本身去跑一下云音乐主站的代码哦！

Code Coverage是一个用来发现你的页面中的未使用JavaScript以及CSS的DevTools。使用这个工具能够看到页面中有多少代码影响了加载性能，而且这些代码让你付出多少时间的代价。

这是主站测试环境下的代码覆盖率，能够发现libs文件基本上有一半都未在使用。而CSS更加夸张，95%的代码都没有使用过。

PRPL原则

PRPL(Push、Render、Precache、Lazy-Load)模式适用于尽力将每个单独路由的代码拆开，而后利用service worker来pre-cacheJavaScript代码，这些懒加载的代码是与当前路由强相关的路由的逻辑代码。

也就是说，咱们在进行路由加载的时候，仅仅加载一个纯净的路由页面。当这个路由页面渲染完毕以后，咱们经过一个路由相关的list来将其余与当前路由有跳转规则的路由页面加载进来，经过service worker来在后台线程进行懒加载与解析。而且根据咱们当前的环境，来进行优雅降级，若是设备不支持后台线程，那么就采用主线程来进行加载。

性能预算

性能预算是保证全部开发人员在一个频道的关键，性能预算定义了一个常量，来让团队有着共同的性能目标。

性能预算通常包括下面几个部分：

• Milestone timings（里程碑时间？）：这个时间通常基于加载页面时候的用户体验，好比能够开始交互的时候。这个时间通常是页面完成加载的精确时间。
• Quality-based metrics：基于纯粹的值，好比JavaScript的大小，HTTP请求的数量，这个值主要关注浏览器体验。
• Rule-based metrics：经过LightHouse或者其余页面测试工具获得的评分。

因为如今的大型项目总都是由多个开发人员一块儿进行开发的，这些开发人员对于页面的性能并无一个统一的标准，经过上面三个标准，每一个人在加入了本身的代码以后就能够对于性能进行测试，来确认本身是否影响到了整个项目的性能预算。好比本身的库致使了团队的JavaScript代码超量。这时，团队的人就须要根据状况来削减本身的代码量。

下面的有点可怕，就放原文了：

Here’s an action plan for performance:

Create your performance vision. This is a one-page agreement on what business stakeholders and developers consider “good performance”

Set your performance budgets. Extract key performance indicators (KPIs) from the vision and set realistic, measurable targets from them. e.g. “Load and get interactive in 5s”. Size budgets can fall out of this. e.g “Keep JS < 170KB minified/compressed”

Create regular reports on KPIs. This can be a regular report sent out to the business highlighting progress and success.

在GIT合并的时候设置LightHouse的检测规则，若是致使了LightHouse评分下降，则blocked该次合并。在对于性能极致要求的业务状况下，这个方法的确可以有效地提高业务代码的质量。

Get fast, Keep fast

性能不是一蹴而就的，许多细小的变更均可能会带来大的收益。