2017前端性能优化清单

https://github.com/Findow-team/Blog/issues/11?utm_source=tuicool&utm_medium=referral

2017前端性能优化清单

你开始使用渐进启动了么？是不是已经使用过React和Angular中tree-shaking和code-splitting两个工具？有没有用过Brotli、Zofli和HPACK这几种压缩技术，或者OCSP协议（在线证书状态协议）？知不知道资源提醒，客户端提醒和CSS containment一类的技术？了解IPv6，HTTP/2和Service Worker这些协议吗？

回想那些年，大家往往在完成了产品之后才会去考虑性能。常常把与性能相关的事情拖到项目的最后来做，所做的也不过是对服务器上的config文件进行一些微调、串联、优化以及部分特别小的调整。而现在，技术已经有了翻天覆地的变化。

一个项目的性能是非常重要的，除了要在技术层面上注意，更要在项目的设计之初就开始考虑，这样才可以使性能的各种隐形需求完美的整合到项目中，随着项目一起推进。性能最好具有可量化、可监测以及可改动的特性。网络越来越复杂，对网络的监控也变得越来越难，因为监测的过程会受到包括设备、浏览器、协议、网络类型以及其他技术（CDN，ISP，缓存，代理服务器，防火墙，负载均衡器和服务器对性能的影响都很大）的很大影响。

下文是一份2017年的前端性能优化清单，阐述了作为前端开发人员，为了确保反馈速度以及浏览器兼容性我们需要考虑的问题。

（你也可以下载checklist PDF或者check in Apple Pages。优化万岁！）

正文

微优化是保持性能最好的办法，但是又不能有太过明确的优化目标，因为过于明确的目标会影响在项目中做的每一个决定。以下是一些不同的模型，请按照自己舒服的顺序阅读。

请准备好然后定下目标！

1. 比你最强的竞争对手快20%

根据一个心理学研究，你的网站最少在速度上比别人快20%，才能让用户感觉到你的网站比别人的更快。这个速度说的不是整个页面的加载时间，而是开始加载渲染的时间，首次有效渲染时间（例如页面需要加载主要内容的时间），或者交互时间（指的是页面或者应用中主要的页面加载完成，并主备好与用户进行交互的时间）。

在Moto G（或中端三星设备）和Nexus 4（比较主流的设备）上衡量开始渲染时间（用WebPagetest）以及首页有效渲染时间（用Lighthouse），最好是在一个开放的实验室中，使用规范的3G，4G和Wi-Fi链接。

Lighthouse，一个Google开发的新的性能审查工具

你可以通过你的分析报告看看你的用户处在哪个阶段，选取其中前90%的用户体验来做测试。接着收集数据，建一个表格，筛去20%的数据并预设一个目标（如：性能预算）。现在你可以将上述两个值进行对比检测。如果你始终维持着你的目标并且通过一点一点改变脚本去加快交互时间，那么上述方法就是合理可行的。

由Brad Frost创建的性能分析

和你的同事分享这份清单。首先要确保团队中的每个人都熟悉这份清单。项目中每一个决定都会影响性能，如果前端工程师们都在积极的参与项目概念，UX以及视觉设计的决定，这将会给整个项目带来巨大收益。地图设计的决定违背了性能理念，所以他在这份清单内的顺序有待考虑。

2. 反应时间为100毫秒，帧数是每秒60帧

RAIL性能模型会为你提供一个优秀的目标，既尽最大的努力在用户初始操作后的100毫秒内提供反馈。为了达到这个目标，页面需要放弃权限，并将权限在50毫秒内交回给主线程。对于像动画一样的高压点，最好的方法就是什么都不做，因为你永远无法达到最小绝对值。
同理，动画的每一帧都需要在16毫秒内完成，这样才能保证每秒60帧（一秒/60=16.6毫秒），如果可以的话最好能在10毫秒内完成。因为浏览器需要一定的时间去在屏幕上渲染新的帧，而且你的代码需要在16.6毫秒内完成执行。要注意，上述目标应用于衡量项目的运行性能，而非加载性能。

3. 首次有效渲染时间要低于1.25秒，速度指数要低于1000

纵使这个目标实现起来非常困难，你的最终目标也应该是让开始渲染时间低于1秒且速度指数低于1000（在网速快的地方）。对于首次有效渲染时间，上限最好是1250毫秒。对于移动端，3G下移动设备首次渲染时间低于3秒都是可以接受的。稍微高一点也没关系，但千万别高太多。

定义你所需要的环境

4. 选择和安装你的开发环境

不要过多的关注当下最流行的工具，坚持选择适合自己开发环境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者组合起来的工具。只要这个工具运行的速度够快，而且没有给你的维护带来太大问题，这就够了。

5. 渐进增强（progressive enhancement）

在构建前端结构的时候，应始终将渐进增强作为你的指导原则。首先设计并且构建核心体验，随后再完善那些为高性能浏览器设计的高级特性的相关体验，创建弹性体验。如果你的网页可以在使用低速网络、老旧显示器的很慢的电脑上运行飞快，那么在光纤高配电脑上它只会运行的更快。

6. Angular，React，Ember等

最好使用那些支持服务器端渲染的框架。在使用某个框架钱，先记录服务器和客户端的引导时间，记得要在移动设备上测试，最终才能使用某个框架（因为面对的是性能问题，如果在使用某个框架后，再做修改是非常困难的）。如果你使用JavaScript框架，要保证你的选择是被广泛使用并且经过考验的。不同框架对性能有着不同程度的影响，同时对应着不同的优化策略，所以最好可以清楚的了解你要用的框架的每个方面。在写网页应用时可以先看看PRPL pattern和application shell architecture。

本图描述了PRPL pattern

上图是application shell，是一个小型的、由HTML,CSS和JavaScript构成的用户界面

7. AMP还是Instant Articles？

根据你整体组织结构的优先顺序和策略，你可以考虑使用Google的AMP或Facebook的Instant Articles。要知道没有这些你也可以达到不错的性能，但是AMP可以提供一个性能不错的免费的内容分发网络框架（CDN），Instant Articles可以在Facebook上促进你的性能。你也可以建立progressive web AMP。

8. 选择适合你的CDN

根据你的动态数据量，可以将一部分内容外包给静态网站生成工具，将它置于CDN上，从中生成一个静态版本，从而避免那些数据库的请求。也可以选择基于CDN的静态主机平台，通过交互组件丰富你的页面（JAMStack）。

注意CDN是否可以很好的处理（或分流）动态内容。没必要单纯的将你的CDN限制为静态。反复检查CDN是否执行了内容的压缩和转化，检查智能HTTP/2传输和缓存服务器（ESI），注意哪些静态或动态的部分处在CDN的边缘（最接近用户的服务器）。

开始优化

9. 直接确定优化顺序

首先应该弄清楚你想解决的问题是什么。检查一遍你所有的文件（JavaScript，图片，字体，第三方script文件以及页面中重要的模块，例如轮播，复杂信息图标和多媒体内容），并将他们分类。
列一个表格。明确浏览器上应该有的基础核心内容，哪些部分属于为高性能浏览器设计的升级体验，哪些是附加内容（那些不必要或者可以被延时加载的部分，例如字体，不必要的样式，轮播组件，播放器，社交网站入口，很大的图片）。更详细的细节请参考文章”Improving Smashing Magazine’s Performance‘’。

10. 使用符合标准的技术

使用符合标准的技术向过时的浏览器提供核心体验，向老式浏览器提供增强体验, 同时对所加载的内容要有严格的把控。即首要加载核心体验部分，将增强部分放在DomContentLoaded，把额外内容发在load事件中。

以前我们可以通过浏览器的版本推断出设备的性能，但现在我们已经无法推测了。因为现在市场上很多廉价的安卓手机都不考虑内存限制和CPU性能，直接使用高版本的Chrome浏览器。一定要注意，在我们没有其他选择的时候，我们选择的技术同时可能成为我们的限制。

11. 考虑微优化和渐进启动

在一些应用中，可以在渲染页面前先初始化应用。最好先显示框架，而不是一个进度条或指示器。使用可以加速初始渲染时间的模块或技术（例如tree-shaking和code-splitting），因为大部分性能问题来自于应用引导程序的初始分析时间。还可以在服务器上提前编译，从而减轻部分客户端的渲染过程，从而快速输出结果。最后，考虑使用Optimize.js来加快初始加载速度，它的原理是包装优先级高的调用函数（虽然现在已经没什么必要了）。

渐进启动指的是使用服务器端渲染，从而快速得到首次有效渲染，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽可能的接近首次有效渲染时间。

到底采用客户端渲染还是服务器端渲染？不论哪种做法，我们的目标都是建立渐进启动：使用服务器端渲染可以得到很短的首次有效渲染时间，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽可能的接近首次有效渲染时间。接下来，尽可能的增加一些应用的非必要功能。不幸的是，正如Paul Lewis所说，框架基本上对开发者是没有优先级的概念的，因此渐进启动在很多库和框架上是很难实施的。如果你有时间的话，还是考虑使用策略去优化你的性能吧。

12. HTTP的缓存头使用的合理吗？

仔细检查一下例如expires，cache-control，max-age以及其他HTTP缓存头是否被正确的使用。一般来说，资源不论在短时间（如果它会被频繁改动）还是不确定的时间内（如果它是静态的）都是可缓存的——你大可在需要的时候在URL中成改版本。

如果可能，使用为指纹静态资源设计的Cache-control:immutable，从而避免二次验证（2016年12月，只有FireFox在https://处理中支持）。你可以使用，Heroku的primer on HTTP caching headers，Jake Archibald的 ”Caching Best Practices”，还有IIya Grigorik的HTTP caching primer作为指导。

13. 减少使用第三方库，加载JavaScript异步操作

当用户请求页面时，浏览器会抓取HTML同时生成DOM，然后抓取CSS并建立CSS对象模型，最后通过匹配DOM和CSS对象生成渲染树。在需要处理的JavaScript文件被解决之前，浏览器不会开始对页面进行渲染。作为开发者，我们要明确的告诉浏览器不要等待，直接开始渲染。具体方法是使用HTML中的defer和async两个属性。

事实上，defer更好一些（因为对于IE9及以下用户对于IE9及以下用户，很有可能会中断脚本）。同时，减少第三方库和脚本的使用，尤其是社交网站的分享按键和