前端性能优化指北-关于有些细节和思路

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

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

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

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

如果前端工程师们都在积极的参与项目概念，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. AMP还是Instant Articles？
根据你整体组织结构的优先顺序和策略，你可以考虑使用Google的AMP或Facebook的Instant Articles。要知道没有这些你也可以达到不错的性能，但是AMP可以提供一个性能不错的免费的内容分发网络框架（CDN），Instant Articles可以在Facebook上促进你的性能。你也可以建立progressive web AMP。

7. 选择适合你的CDN
根据你的动态数据量，可以将一部分内容外包给静态网站生成工具，将它置于CDN上，从中生成一个静态版本，从而避免那些数据库的请求。也可以选择基于CDN的静态主机平台，通过交互组件丰富你的页面（JAMStack）。注意CDN是否可以很好的处理（或分流）动态内容。没必要单纯的将你的CDN限制为静态。反复检查CDN是否执行了内容的压缩和转化，检查智能HTTP/2传输和缓存服务器（ESI），注意哪些静态或动态的部分处在CDN的边缘（最接近用户的服务器）。

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

9. 使用符合标准的技术
使用符合标准的技术向过时的浏览器提供核心体验，向老式浏览器提供增强体验, 同时对所加载的内容要有严格的把控。即首要加载核心体验部分，将增强部分放在DomContentLoaded，把额外内容发在load事件中。以前我们可以通过浏览器的版本推断出设备的性能，但现在我们已经无法推测了。因为现在市场上很多廉价的安卓手机都不考虑内存限制和CPU性能，直接使用高版本的Chrome浏览器。一定要注意，在我们没有其他选择的时候，我们选择的技术同时可能成为我们的限制。

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

到底采用客户端渲染还是服务器端渲染？不论哪种做法，我们的目标都是建立渐进启动：使用服务器端渲染可以得到很短的首次有效渲染时间，这个渲染过程也包括小部分的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及以下用户，很有可能会中断脚本）。同时，减少第三方库和脚本的使用，尤其是社交网站的分享按键和<iframe>嵌入（比如地图）。你可以使用静态的社交网站分享按键（例如SSBG的）和指向交互地图的静态链接去代替他们。

14. 图片是否被正确优化？
尽可能的使用带有srcset，sizes还有<picture>元素的响应式图片。你也可以利用<picture>元素的AVIF、WEBP格式，用JPEG格式作为替补（参见Andreas Bovens的code snippet）或是使用内容协商（使用接受头）。本身可以使用自己的PS或者skecth尝试导出，若不能导出，可以尝试 火山引擎的ImageX图像处理服务（不知道怎么使用可以自行百度搜索 "火山引擎 ImageX"）可以支持多种格式输出，比如AVIF、webp格式；

我曾经写过这篇文档可以对照一下：高效率图像压缩处理服务， 参考截图：

你也可以使用客户端提示，现在浏览器也可以做到。在用来生成响应图片的源文件过少时，使用响应图片断点生成器。

15. 图片的进一步优化
当你在编写登录界面的时候，发现页面上的图片加载的特别快，这时你需要确认一下图片进一步优化的思路只要有三点：

降低图片的分辨率，如果浏览器中展示区域100*100，此时展示 400*400 就属于资源浪费，这也是显著提高图片响应速度最直接的方法；
降低图片压缩的质量，图片压缩质量，使用有损压缩，比如图片压缩质量90 和75对人眼可见的范围内都可以接受，常见支持有损压缩的图片格式比如，jpeg、wepb、heic、avif等图片格式支持图片有损压缩；
改变图像压缩的压缩方式，改变图片的压缩算法也能更高效的提高图片优化图片提高速度，比如 常见图像压缩率（图像画质等同前提下）： HEIF （heic） > AVIF （avif、avis） >webP（awebp） > jpeg > png 等；
正常情况下PNG是原图格式，体积特别大，巧的是业界对PNG 有pngquant 使用Median Cut量化算法的修改版本和其他技术来缓解Median Cut的不足，可以最大效率保留信息的前提下降低png 的体积大小；如果我们把如上的一些优化处理起来，我使用的过程中发现，火山引擎的imagex 已经完美的支持了上面三者的使用方法：下面我举个例子做一下说明：

http://imagex.75live.com/tos-cn-i-n9b2vwdhz3/public/attachments/2021/03/11/GyVrojIWFkQOKSAzYnUmlQxvaESnPaZYxgpu9v1Z.png~tplv-n9b2vwdhz3-12:300:200.webp 这个是 png的原图处理好的结果，在这个url中imagex 给出了一种url语义，"~tplv--模板名称:[模板参数].图像格式"  通过改变300:300 能改改变压缩率，通过参数能够调整压缩质量，通过改变webp-->avif 可以转换成不同的压缩方法；

更巧妙的是在这，就算指定输出png后仍然还可以设置质量参数

如果你还觉得不够，那你可以通过多重背景图片技术来提高图片的感知性能。

15.1 如何使用webpack将静态素材快速托管到ImageX，并开启http/2
这里发现一个第三方写的但被官方推荐的开源插件https://github.com/Cmaxd/veimagex-webpack-loader ，通过配置webpack-loader 插件的方式可以将图片上传到ImageX，然后将图片使用不同的图片模板访问就可以满足需求，同一个图片可以使用多个地址，例如avif、webp、jpeg 使用 <picture> 标签进行降级 或者判断浏览器支持降级；

16. 网页字体优化了吗？
你用来修饰网页字体的服务很有可能毫无用处，包括字形和额外的特性。如果你在使用开源的字体，尝试用字体库中某一个小的子集或是自己归类一个小的子集从而压缩文件大小（例如通过一些特殊的注音符号引用Latin）。WOFF2 support是个非常不错的选择，如果浏览器不支持，那你可以将WOFF和OTF作为备用。你也可以从Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”一文中选择一个合适的策略，然后使用服务器来缓存字体。如果想要快速入门，Pixel Ambacht的教程与案例会让你的字体变得尽然有序。如果你用的是第三方服务器主机，没办法自己在服务器上对字体进行操作，一定看看Web Font Loader。

17. 快速执行关键部分的CSS
为了确保浏览器尽可能快的渲染你的页面，先收集页面首次可见部分的CSS文件（也叫决定性CSS或上半版CSS）进行渲染，然后将它加入页面的<head>部分，从而避免重复操作。因为慢启动阶段对交换包大小的限制，你关键CSS文件的大小也被限制在14KB左右。如果高于这个值，浏览器需要重复一些步骤来获取更多的样式。关键CSS是允许你这样做的。可能对每个模板都需要这个操作。如果可能，考虑一下用Fiament Group用的条件内敛方法。

通过HTTP/2，关键CSS可以单独存为CSS文件，通过服务器传输，而且可以避免HTML膨胀。服务器传输缺乏连续支持，并且存在一些超高速缓存的问题（Hooman Beheshti演示的前144页）。事实上，这样会导致网络缓冲区膨胀。因为TCP的慢启动，服务器传输在稳定的连接下会更有效率。所以你可能需要建立带有缓存的HTTP/2服务器传输机制。但请记住，新的cache-digest规则会否定手动建立的需要缓存的服务器的请求。

18. 通过tree-shaking和code-splitting减少净负载
Tree-shaking是通过保留那些在项目过程中真正需要的代码从而清理你的构建过程的一种方式。你可以用Webpack 2来提出那些没用的住配置文件，用UnCSS或Helium从CSS中取出不需要的样式。同理，也可以考虑学习一下如何编写高效的CSS选择器，以及如何避免膨胀和高费的样式。

Code-splitting是另一个Webpack特性，它可以根据按需加载的块将你的代码分开。只要你在代码中定义了分离点，Webpack便会处理好相关的输出文件。它基本上能保证你初始下载的内容很小，而且在需求被添加时按需请求代码。

Rollup所展示的结果要比Browserify配置文件所显示的好得多。所以当我们想使用类似工具的时候，或许应该看看Rollupify，它将ECMAScript2015模块变成了一个更大的CommonJS模块——因为小模块没准有出乎意料的高性能成本，这源自于你对打包工具模块系统的选择。

19. 提升渲染性能
使用类似CSS containment的方法对高消耗组建进行隔离，从而限制浏览器样式的范围，可以作用在为无canvas的浏览工作的布局和装饰工作中，或是用在第三方工具上。要确保页面滚动和出现动画效果时没有延迟，别忘了之前提到过的每秒60帧的原则。如果没办法做到，那就尽可能保证每秒帧数的大致范围在15到60帧。使用CSS中的will-change通知浏览器哪些元素和属性发生了变化。也记得要衡量渲染执行中的性能（可以用DevTools）。可以参照Udacity上Paul Lewis的免费课程——浏览器渲染优化，作为入门。还有一篇Sergey Chikuyonok的文章讲了如何正确的用GPU动画。

20. 预热网络连接，加快传输速度
使用页面框架，对高消耗组建延迟加载（字体，JS文件，循环播放，视频和内嵌框架）。使用资源提示来节省在dns-prefetch（指的是在后台执行DNS检索），preconnect（指要求浏览器在后台进行握手链接（DNS，TCP，TLS）），prerender（指要求浏览器在后台对特定页面进行渲染），preload（指的是提前取出暂不执行的源文件）。根据你浏览器的支持情况，尽量使用preconnect来代替dns-prefetch，而且在使用prefetch和prerender要特别小心——后者（prerender）只有在你非常确信用户下一步操作的情况下再去使用（比如购买流程中）。

HTTP/2
21. 准备好使用HTTP/2
Google开始向着更安全网页的方向努力，并且将所有Chrome上的HTTP网页定义为“不安全”时，你或许应该考虑是继续使用HTTP/1.1，还是将目光转向HTTP/2环境。虽然初期投入比较大，但是使用HTTP/是大趋势，而且在熟练掌握之后，你可以使用service worker和服务器推送技术让行性能再提升一大截。
现在，Google计划把所有HTTP页面标记为不安全，并且将HTTP安全指示器设置为与Chrome用来拦截HTTPS的红色三角相同的图标。

使用HTTP/2的环境的缺点在于你要转移到HTTPS上，并且根据你HTTP/1.1用户的数量（主要指使用过时操作系统和过时浏览器的用户），你需要适应不同的建构过程，才能发送不同的建构。注意：不论是迁移还是新的构建过程都可能非常棘手而且耗时很多。

22. 适当部署HTTP/2
重申，使用HTTP/2协议之前，你需要彻底排查目前为止你所使用协议的情况。你需要在打包组建和同时加载很多小组间之间找到平衡。

一方面，你可能想要避免将很多资源链式链接，与其将你全部的界面分割成许多小模块，不如将他们压缩使之成为建构过程的一部分，之后给它们赋予可检索的信息并加载它们。这样的话，对一文件将不再需要重新下载整个样式清单或JavaScript文件。

另一方面，封装是很有必要的，因为一次向浏览器发送太多JavaScript文件会出问题。首先，压缩会造成损坏。得益于dictionary reuse，压缩大文件不会对文件造成损害，压缩小文件则不然。确实有方法可以解决这个问题，但这不是本文讨论的范畴。其次，浏览器还没有优化到可以对类似工作流进行优化。例如，Chrome会引发进程间通信（IPCs），这些通信的数量与资源的数量成正比，而这成百上千个资源将会消耗大量的浏览器的执行时间。
Chrome的Jake Archibald建议，为了用HTTP/2达到最好的效果，考虑一下逐步加载CSS文件

当然你可以考虑逐步加载CSS文件。很显然，你这样做对HTTP/1.1的用户非常不利，所以你可能需要根据不同的浏览器建立多个版本来应对你的调度过程，这样就会使过程略微复杂。你也可以避免HTTP/2连接的合并，同时受益于HTTP/2来使用域名碎片，但是实现起来有些困难。

我们到底应该做什么呢？如果你粗略的用过HTTP/2，似乎成功的发送过10个左右的包（在老是浏览器上运行的也不错）。那你就能着手开始试验并且为你的网站找到平衡点。

23. 确保服务器安全可靠
所有的浏览器都支持HTTP/2并且使用TLS，这是有你可能想要避免安全警告，并删除页面上没用的元素。好好检查你的安全头部是否设置正确，排除已知的缺陷并检查证书。

如果还没有迁移到HTTP， 你那可以先看看HTTPS准则（The HTTPS-Only Standard）。确保所有外部插件和监视脚本都能被HTTPS正确加载，确保没有跨站脚本出现，HTTP脚本传输的安全头和内容安全头也都设置正确。

快速入门
这份清单综合性很强，几乎介绍了所有的可用的优化方式。那么，如果你只有一个小时进行优化，你应该干什么呢？让我们从中总结10个最有用的来。别忘了在你开始优化前和结束优化后，记录你的结果，包括开始渲染时间以及在3G，有限连接下的速度。

但没关系，本文只是一个普通大纲（希望能做到综合性强），你应该根据自己的工作环境列一份适合自己的清单。最重要的，在开始优化之前，先对项目中存在的问题有一个明确的了解。
————————————————
版权声明：本文为博主「七脉神剑」的原创文章