--- theme: juejin --- > 导语：最近在处理性能优化相关的工作，发现这块的内容涉及到比较多的知识点和有意思的工具，所以整理一下，便于以后查阅（毕竟迈入了30岁，很多东西不整理就容易忘😭😭），也希望对屏幕前正在看此文的你有一点帮助和启发。 #### 说完废话，我们言归正传，来聊一聊我们本次的话题：《前端性能优化》本文所有相关的demo展示都传到了github上: https://github.com/ycvcb123/performance-opt ### 本文目录: * 为什么要做性能优化？ * 性能优化发展历史 * 性能指标介绍 * 性能优化方案 * 自动化性能检测工具介绍 * 总结

## 为什么要做性能优化？ > 回答这个问题前，我们来看下一些网站的统计数据 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/77e732635e5d487c802f60da9c3ab33f~tplv-k3u1fbpfcp-watermark.image?) ###### *数据来源：* https://www.pingdom.com/blog/page-load-time-really-affect-bounce-rate/ 随着网页加载时间的变长，用户的跳出率会越来越高。`（高就高呗，又不是不能正常使用，i don‘t care～）` 我们接着看下面这张图： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2240335d7daf43f78b7ec382adfbc12e~tplv-k3u1fbpfcp-watermark.image?) ###### *数据来源：* https://www.websitebuilderexpert.com/building-websites/website-load-time-statistics/ ###### https://www.thinkwithgoogle.com/feature/testmysite/ 从上面的几个例子来看，`亚马逊`慢一秒就会损失1.6亿美元，`沃尔玛`每快一秒，就会增加`2%`的转化率，`速卖通`将页面加载的时间减少了`36%`，订单增加了`10.5%`,新客户转化率增加了`27%`，等等... 我们可以得出结论：网站的访问量及用户的持久性其实在一定程度上取决于其性能，如果一个网站响应耗时久，占用大量的cpu等，往往就会导致用户流失，从而给网站带来一些直接的经济损失。`（谈钱，你还能不care吗？😃）` 聊完了为啥要做性能优化，接下来我们来聊一聊性能优化的历史。

## 性能优化发展历史？ > 读史让人明智 -- 某个名人说过参考一些资料整理了个时间轴（年份可能略有差异，不重要） ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f0cb50606795454481725da57b933e8f~tplv-k3u1fbpfcp-watermark.image?) #### 1. 2007年 -- 雅虎军规，检测工具 `yslow` [雅虎军规](https://developer.yahoo.com/performance/rules.html?guccounter=1), [yslow](http://yslow.org/) 一、雅虎提出的`35条军规`：包括我们熟悉的（减小cookie体积，减少http请求数，减少dns查询，避免重定向，避免404页面，等等。。。大家可以通过上面的官方链接研究一下）。二、`yslow`: 基于`雅虎35条军规`中的一部分军规开发的检测工具。（但是现在安装地址点进去已经`404`了，😓），想了解的同学看下这片文章 [网站性能评分工具Yslow 使用教程](https://devework.com/yslow.html) 可以说，`2007`从雅虎军规开始，开启了一个前端性能优化时代的新纪元（像极了`2007`年拍摄的`钢铁侠1`，开启了整个漫威宇宙），意义巨大。 #### 2. 2008年 -- `google`推出`WebPageTest` [WebPageTest](https://www.webpagetest.org/) ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0e72dc2145d940bab9a808151fdf3d6f~tplv-k3u1fbpfcp-watermark.image?) 可以选择测试地点，浏览器类型，在`Advanced Settings`高级选项中还能设置链接类型，测试次数，等等。。。非常有意思的一个工具，大家可以自己去尝试一下。 #### 3. 2009年 -- `google`推出`SPDY协议` SPDY：其实就是HTTP2的前身，大家可以看下这边文章，介绍的很详细 [SPDY简介](https://chenhm.com/post/2014-10-12-spdy) #### 4. 2010年 -- `FaceBook`推出`BigPige` `BigPige`，是针对服务端渲染(SSR)的优化。 > SSR: 服务端准备好所有内容，拼接成完整的html文档，返回给前端。简单来说，就是把页面分成不同的模块，当有模块加载完成，就返回给前端，不用等所有的模块都加载完成。如下图，对图中的 `3`，`4` 步做了优化： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5cc9e7bebd5d4044b17fed30832fb54a~tplv-k3u1fbpfcp-watermark.image?) ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/25335dc127f8401099ecfdb675b24f03~tplv-k3u1fbpfcp-watermark.image?) 更多关于`BigPige`的技术细节，大家可以参考 [bigPipe 原理分析](https://zhuanlan.zhihu.com/p/82398532) ,里面解释的很详细。 #### 5. 2015年 -- `HTTP-WG`基于`google`的`SPDY协议`正式推出`http2`,`google`推出`RAIL模型`和`PageSpeed insights` 页面性能检测工具一、`HTTP2`：介绍这个的文章很多，[一文读懂 HTTP/2 特性](https://zhuanlan.zhihu.com/p/26559480)，[HTTP2 详解](https://blog.wangriyu.wang/2018/05-HTTP2.html) 这两篇解释的很好，它的主要优点就是（关于下面的后两点，后面会有具体的`demo` 说明，大家先继续往下看～）： * 二进制格式传输代替文本传输 * 多路复用打破最大链接数限制 * 服务端推送减少TTFB时间二、`RAIL模型`：一图胜千言，看看下面这图，眼熟不？(¬◡¬)✧ ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c9bb3d331f7e462b9c82dffa9798269e~tplv-k3u1fbpfcp-watermark.image?) `google开发者手册` 对这个模型有一个很详细的解释 [Measure performance with the RAIL model](https://web.dev/rail/)。简单做一个说明： * `Response`：轻触后100ms内有反馈。 * `Animation`：保证动画每一帧的渲染都在`16ms` 以内，之前写过一遍相关的文章，大家感兴趣的可以看下，解释了为啥要保证一帧在`16ms` 以内，[兄dei，听说你动画很卡？](https://juejin.cn/post/6844903716500439047) 。 * `idle`：合理的利用空闲时间，保证任务尽量在`50ms` 完成。（这里等下介绍`long task`的时候，会有详细说明）。 * `load`：加载时间，重要的内容尽量在`1s` 内完成。三、`PageSpeed insights`性能检测工具 [PageSpeed insights](https://developers.google.com/speed/pagespeed/insights/) 使用界面： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ed99d120473e4b78bd5958f9b4f875a9~tplv-k3u1fbpfcp-watermark.image?) 结果输出页：(是不是像极了`lighthouse`，个人认为，这个其实就是`lighthouse` 的前身) ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0134fb5af03b4bc580992126454b042a~tplv-k3u1fbpfcp-watermark.image?) #### 6. 2016年 -- `google`推出`lighthouse`检测工具和`PWA`方案，还有`最佳开发者手册` 一、`lighthouse`：页面性能指标的检测工具，最简单的使用方式，就是打开`chrome` 控制台使用，其余还支持插件，node，命令行等使用形式。（下面也会有详细的介绍）二、`PWA`：渐进式`web` 应用，官方也有一个很详细的介绍 [Progressive Web Apps](https://web.dev/progressive-web-apps/) 它其实就是补足了，现在`web` 应用的一些不足，比如，消息推送，离线缓存，没法从屏幕上直接打开，等等... 三、`谷歌最佳开发者手册`：[web.dev](https://web.dev/) 有你想知道的很多东西（比如等下会说到的各个性能指标的定义，都有着很清楚的解释～），可以慢慢研究一下。 #### 7. 2017年 -- `google`推出`AMP`，百度推出`MIP` 两者其实差不多是一样的，`MIP` 继承了很多 `AMP` 的思想，目的都是为了加快移动页面的访问速度，主要原理都是通过自带的`runtime` 协调资源的加载时机和优先级，保证页面的快速渲染。具体的介绍看下`张鑫旭`大神写的 [移动页面加速google的AMP和百度的MIP简介](https://www.zhangxinxu.com/wordpress/2017/09/google-amp-baidu-mip/)，还有[谷歌AMP和百度MIP，你选哪个？](https://zhuanlan.zhihu.com/p/38253299) 这篇也很不错。 #### 8. 2018年 -- `HTTP-WG`推出`HTTP3` `HTTP3`：这里有一篇关于`HTTP3`的详解 [ 5 分钟看懂 HTTP3](https://www.infoq.cn/article/whcobxfbgtphy7ijv1kp)，感兴趣的同学可以了解一下。 #### 8. 2020年 -- `google`推出`web-vitals`新一代的性能指标评估方案 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a8fed0c994c4161ad27f159e1063664~tplv-k3u1fbpfcp-watermark.image?) 包含了三个重要指标：（在等下的指标介绍中会有详细的解释） * `LCP`：最大内容绘制时间 * `FID`：首次用户输入延时 * `CLS`：累计布局偏移说了这么多，以上就是性能发展的一个大概历史，接下来我们来聊一聊具体的性能指标：

## 性能指标介绍 > 在介绍前我们简单了解下，主要是谁在负责这个事？这就要提一下大名鼎鼎的`W3C`了！它在`2010`年成了`性能工作组`，由谷歌和微软的工程师担任主席，主要就是制定衡量 `Web` 应用性能的方法和 `API` 感兴趣的可以看下性能工作组的官网 [Web Performance Working Group](https://www.w3.org/webperf/)，对每一个提案都有一个非常详细的说明，如下，是我按照其中给的时间，整理了下大概的一个发展过程，能看到其中有我们很熟悉的 * 计时方法：`Navigation timing / paint timing / User timing`. * 专门处理上报的：`Beacon`. * 高精度时间：`High Resolution Time`. ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/832f0ad7bbc247508ab862b9877596de~tplv-k3u1fbpfcp-watermark.image?) 说句题外话，在整个前端性能优化的历史演进中，不管是工具，标准，新的技术，等等。。。 `google`都占据了举足轻重的作用，也许就是这样的不断发展慢慢卷没了IE... ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04f4df0f91d449bab62a7e4116b023e0~tplv-k3u1fbpfcp-watermark.image?) 我们现在来看下，性能相关的一些重要指标：右边这个图用过lighthouse的同学应该都见过，就是一个性能的总评分，而这个分数就是通过右边六项指标加权平均得到的，我们来具体看下这六项指标。 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/54304c071e1e451aa6fbab3296a97a78~tplv-k3u1fbpfcp-watermark.image?) * FCP: 首次内容绘制(可以理解为白屏时间) -- 以页面首次加载的时间为起点，来报告可视区内最大元素的绘制的相对时间 * LCP: 最大内容绘制 -- 根据页面首次开始加载的时间点来报告可视区域内可见的最大图像或文本等的相对时间还是那句话，一图胜千言： ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c808d15e01e84140847c2c005468aa67~tplv-k3u1fbpfcp-watermark.image?) * SI: Speed Index (可见区域内，显示页面可见部分的平均时间)，简单理解就是一个填充速度指标 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/460fc866a19f48fcb339ade6faecc04b~tplv-k3u1fbpfcp-watermark.image?) 看上下两张图，上部分在`1s`的时候就加载了`93%`左右的内容，下半部分在`11s`才加载到这么多，虽说，两个加载完成的时间都是`12s`，但是明显上面要比下面加载要快，转化成图表： ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e35ad26d8a25470894ccc23f2a572de5~tplv-k3u1fbpfcp-watermark.image?) 带入积分公式： ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3b4b93c57e1242a9b0389c32e583e679~tplv-k3u1fbpfcp-watermark.image?) 因为求的是不可见部分的积分，所以这个指标，越小越好： ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2c3db68614c94ef98a1c42c012e9dfc8~tplv-k3u1fbpfcp-watermark.image?) * TTI: 可持续交互时间如下图：指的是从最后一个长任务结束后，`5秒`的时间内，主线程是空闲的。 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/12c5fbb953804c6a84707334b8506fac~tplv-k3u1fbpfcp-watermark.image?) 在这里接上上文中留下的问题，为什么`RAIL模型`中建议，处理任务的时间好是`50ms`，这里我们来解释下`长任务` ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/293e2dba49f14102a643480e6fd9de9e~tplv-k3u1fbpfcp-watermark.image?) `RAIL`模型中，建议反馈的时间最好在`100ms`以内，但是在输入处理前可能还有写其他的工作要做，有一个阻塞的时间，所以长任务的时间定为50ms，是为了确保100ms内对输入作出响应，也就解释了为啥 `idle`中建议任务在`50ms`内完成，看官方提供的这个图： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/031f367b93e04aa1bbbe2724b2c6ef92~tplv-k3u1fbpfcp-watermark.image?) 综上，长任务就是超过`50ms`的任务。 * TBT: 总阻塞时长从FCP到TTI所有长任务阻塞时间之和 `TBT = （longtaskTime1 - 50ms）+ （longtaskTime12- 50ms）+（longtaskTime3 - 50ms）+ ...` * CLS: 累计布局偏移（可以理解为视觉稳定性的一个指标）具体可以看下官方的一个视频例子：https://storage.googleapis.com/web-dev-assets/layout-instability-api/layout-instability2.mp4 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/101c4a9c030c4db8afc3c1ed2e7b31a5~tplv-k3u1fbpfcp-watermark.image?) * FID: 首次输入延时从用户第一次与页面交互直到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0feb4fc01fdd4e82aa2a2eb754d8e219~tplv-k3u1fbpfcp-watermark.image?) 解释下上面这个图，从`FCP`到`TTI`这段时间内，用户输入遇到长任务后等待的时间，就是 `FID` > ok，综上就是我们需要知道的大部分指标的含义，接下来我们看下要怎么获取这些指标： #### `Performance TimeLine ` 闪亮登场！在`html`中有个`window`对象，在这个对象上挂载了许多我们熟悉的`api`，`window.location`,`window.document`,`window.postmessage`，`window.localStorage`等等，`web`的性能标准，则是在`window`上添加了一个`performance`属性，返回一个`Performance`对象，包含了很多衡量性能的属性和方法。 * ##### 提供了两个高精度的时间: `performance.now() `: 相对于创建浏览器上下文时间递增，不受系统时间的影响，是一个相对值。 `performance.timeOrigin`: 性能检测开始的时间 * ##### 三个方法： `getEntries()`， `getEntriesByType()`， `getEntriesByName()` `getEntries()` 返回一个对象数组包含 `Web` 应用程序整个生命周期的各种性能数据，`getEntriesByType` 和 `getEntriesByName` 就是按照`type` 和 `name` 做了一个筛选。 * ##### 两个对象： `PerformanceEntry`，`PerformanceObserver` 上面说的`getEntries`获取的对象就是继承于`PerformanceEntry`. 重点说下 `PerformanceObserver` 这个对象： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2f6e7463d3d5437d9e3d1ff573c59d14~tplv-k3u1fbpfcp-watermark.image?) 在控制台输入： ```js const perfObserver = new PerformanceObserver(entryList => { console.log(entryList.getEntries()); }) perfObserver.observe({type: 'paint', buffered: true}); ``` 在这里看就能看到上文说过的，`FCP`的绘制时间。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dba3876eb8a7494dbedc9886e7af2f6c~tplv-k3u1fbpfcp-watermark.image?) 指标数据基本就是通过这个`PerformanceObserver`对象观察得到的。多说一句，上面有个属性`buffered: true` 在我们创建 `PerformanceObserver` 之前，可能有些 `entry` 已经发生了，这中间有时间间隔，导致我们观察到的不是正确的。举个例子来说。假设我们想现在访问这个网页的 `entryType` 为 `paint` 的 `entry` ，但是我们打开控制台的时候，网页大概率已经加载完毕了，肯定观察不到 `entry`了，`bufferd`就出场了，`bufferd`确保我们能拿到`PerformanceObserver`创建之前的 `entry`。网上有很多基于 `PerformanceObserver`，获取性能指标的方法，推荐大家去看下 [perfume.js](https://github.com/Zizzamia/perfume.js) 的源码，可以更加熟练的使用 `PerformanceObserver`。聊完了指标的意义和获取方式，我们来聊一下第四部分性能优化方案

## 性能优化方案？ > 要优化，肯定要先找问题，找问题，就要先看指标，我们如何方便快速的查看刚才描述的那些指标呢？ `chrome` 开发者工具，带给我了我们很大便利！ `performance` 模块： ![Dimensions Moto G4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6ec4a46bcb564444b5dcacc8c9dde9eb~tplv-k3u1fbpfcp-watermark.image?) `network` 模块： ![Performance Network.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c4511ac418814dc583f2ad312bf6f66d~tplv-k3u1fbpfcp-watermark.image?) 上面两个模块可以帮我很好的分析定位问题，但是你光让我看着这些东西，就来判断具体要做那些优化，说实话还有感觉有点不方便的，所以下面介绍下，`chrome`的一个大杀器 `lighthouse`: ![Performance.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/30cbb4bd8aa9461b97d81f9827429b93~tplv-k3u1fbpfcp-watermark.image?) 点击`Generate report`，来生成报告。 ![Performance.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5e5b567965ae49c8a357a46775bdc858~tplv-k3u1fbpfcp-watermark.image?) 上图不但告诉了我们评分，指标，最最重要的，还告诉了我们该怎么做！！！下面是一些常见的问题及一些对应的解决办法： #### 图片相关： ##### 1. 使用有效恰当的图片 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/385da97f5d2d4d6eb85769fe66ab6909~tplv-k3u1fbpfcp-watermark.image?) ##### 2. 使用下一代图片格式 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5bed9718d92b44a690f27018c5efa548~tplv-k3u1fbpfcp-watermark.image?) ##### 3. 图片懒加载 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0d7d8ed7f32142a28ab096cfca9c92c5~tplv-k3u1fbpfcp-watermark.image?) 先看第一个问题，除了要注意使用图片的大小外，还要注意图片的格式，我们看下现有的图片格式大概分哪几类： 1. `PNG`：无损压缩、质量高、体积大、支持透明应用场景：色彩简单，但是对图片要求比较高的图片（网站的logo） 2. `JPG`：有损压缩、体积小、加载快、不支持透明应用场景：背景图片，轮播图，banner 3. `GIF`：基于LZW压缩算法的无损压缩应用场景：短，小，不容易用样式实现的动画 4. `APNG`：动态PNG，像GIF格式一样播放动态图片，并且拥有GIF不支持的24位图像和8位透明性应用场景：同GIF 5. `SVG`：文本文件、体积小、不失真、兼容性好应用场景：地图，股票k线图 6. `WEBP`：支持透明，支持有损压缩，无损压缩，可以和GIF一样动应用场景：能用就用，做好降级处理 7. `BASE64`：无需请求，嵌入HTML 应用场景：小图标看下一个推荐的选择图片的公式： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/428d8b4aeb4a45ca9368b727bb8251ef~tplv-k3u1fbpfcp-watermark.image?) 不要小看图片格式的选择，图片资源的请求几乎占据了网站资源请求量的一半： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7b87c16a4efd4d838f339dc266f623af~tplv-k3u1fbpfcp-watermark.image?) 合理的使用图片尺寸和格式，可能会对加载速度带来很大的优化效果。我们接着看下面的两个问题： ##### 使用`webp` 格式的图片和图片懒加载这两者其实可以合成一个套方案 ##### VUE-LAZYLOAD + WEBP 首先如何获取`webp`格式的图片？除了网上的一些生成工具外，在项目中我们可以使用`webpack`插件`imagemin-webp-webpack-plugin `来生成 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/55cb3aa204da4e0a8a5c2c4d2874dc1a~tplv-k3u1fbpfcp-watermark.image?) 会得到一个和原图`hash`值一样的，后缀为`webp`格式的图片。引用方法： ```html ``` ```js !detect.DEV && Vue.use(VueLazyload, { filter: { progressive(listener: any, options: any) { // 把lazysrc的值赋给src listener.src = listener.el.getAttribute('lazysrc'); }, webp(listener: any, options: any) { if (isSupportWebp() && !/\.svg$/.test(listener.src)) { listener.src += '.webp'; } }, }, }); ``` 看下`webpack` 的具体配置： ```js //... plugins: [ isProduction && new ImageminWebpWebpackPlugin({ config: [ { test: /\.(jpe?g|png)/, options: { quality: 75, }, }, ], overrideExtension: false, // 这里不会替换后缀名，而是往后加添加 xxxxx.png.webp }), ] // 特别注意，下面这个修改是为了解决，引用时相对路径找不到的问题 isProduction && config.module.rule('vue') .use('vue-loader') .tap(options => { return { ...options, transformAssetUrls: { img: ['src', 'lazysrc'] } } }) ``` 看下效果，滑动到底步，图片懒加载，且在支持webp的情况下显示webp格式的图片： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8a5f3f92e2b8456883b4589cba5caaf1~tplv-k3u1fbpfcp-watermark.image?) #### js相关问题 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9e58095824c941bebc1db695ef820902~tplv-k3u1fbpfcp-watermark.image?) 观察上面建议点，大概可以把问题归结为：加快`js`文件的下载，解析，执行效率。我们看以下几个方案： 1. 开启现代浏览器模式：我们在用`vue`，或者 `react`构建项目的时候，都会有一步用`babel-loader`把`es6+`的语法转成`es5`的操作，这是为了兼容各个不同的浏览器，但其实现在`es6`的语法，很多浏览器都是支持的，在支持的情况下，我们不再转换成冗长且执行效率低下的`es5`语法，可以大大的提升`js`的执行效率，对于不支持的情况，在用`es5`做一个兼容就好。原理是按照`browserslist`，构建两次，一次生成现代模式，一次生成老的模式，通过判断浏览器是否支持`module`，来选择新旧模式。 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a5514af6482040f2b068d7afd90428d9~tplv-k3u1fbpfcp-watermark.image?) 在`vue-cli`中，已经为我们提供了开启这种现代浏览器模式的方式。 ```js vue-cli-service build --modern ``` 2. 按需加载（以`vue`项目举例）如果同一个页面，有着多种不同的模版，建议使用如下的方式加载： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/18aefd5fbcb74cf1b259fc17af6d38ff~tplv-k3u1fbpfcp-watermark.image?) 同一个文件中，如果有大段的逻辑不是需要立刻执行，建议通过下面这种方式执行： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7dd9e16f9438428cb9fe5ee48d4695e0~tplv-k3u1fbpfcp-watermark.image?) `webpackPrefetch: true` 是为了让在浏览器空闲的时候加载这段代码，而不会因为触发后再加载，影响到对用户的反馈。 3. 合理的分包策略这里提供一个大概的参考，以`vue`项目为例： 1. 为了防止`node_modules`打包出来的`chunk-vendor`过大，可以将其中大于300kb的模块单独打包出来。 2. 为了防止一些公共模块重复打包，可以把公用的模块打包到一起，根据打包后的体积在考虑如何进一步更细致的拆分。 3. 像`vue`, `vuex`, `vue-router`，这类的库，变动可能非常小，可以通过`cdn`引入，构建时候不要在打包。 ```js //... // 通过cdn的方式引入 config.externals({ vue: 'vue', 'vue-router': 'vue-router', vuex: 'vuex', }); const assets = [ { path: `/libs/vue/2.6.12/vue.esm.min.js`, type: 'js' }, { path: `/libs/vue-router/3.5.1/vue-router.esm.min.js`, type: 'js' }, { path: `/libs/vuex/3.1.2/vuex.min.js`, type: 'js' }, ]; new HtmlWebpackIncludeAssetsPlugin({ assets, append: true, }), //... // 拆包 config.optimization.splitChunks({ minSize: 300 * 1024, maxInitialRequests: Infinity, chunks: 'all', cacheGroups: { matchVendor: { test: /[\\/]node_modules[\\/]/, name(module) { // 超过300kb，单独打包 const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1]; return `chunk&&&&&&${packageName.replace('@', '')}`; }, priority: 10 }, common: { minSize: 100 * 1024, minChunks: 2, // 有两个或者两个以上chunk都使用到了，就单独打包出来 priority: 0, reuseExistingChunk: true, name: 'chunk-common', } } }) ``` ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/25f7af86450e4f4ea0e30137e74da8a3~tplv-k3u1fbpfcp-watermark.image?) 4. 迎合`v8` 引擎做优化 > 我们先看下`v8`是如何运行代码的 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d4479940c0e948f9b38de9017ed7b24d~tplv-k3u1fbpfcp-watermark.image?) `js`是一门解释型的语言，而解释型的语言特点就是启动快，执行慢，像`c/c++`这种编译型的语言特点则是，启动慢，执行快。`v8`引擎则是结合了两者的优点：首先如上图所示，一段`js`代码通过解析生成抽象语法树，然后生成字节码，解释器可以直接解释执行字节码，或者通过编译器将其编译为二进制的机器代码再执行，首先是通过解释器执行并且输出结果，随后如果有一段代码被反复的执行，`v8`会启动`Turbofan`，将字节码文件编译成机器码，从而加快`js`的执行效率。我们来看一个具体的例子： ```js const { performance, PerformanceObserver } = require('perf_hooks'); const add = (a, b) => a + b; const num1 = 1; const num2 = 2; performance.mark('start'); for (let i = 0; i < 10000000; i++) { add(num1, num2); } // add(num1, 'x'); for (let i = 0; i < 10000000; i++) { add(num1, num2) } performance.mark('end'); const observer = new PerformanceObserver((list) => { console.log(list.getEntries()[0]); }) observer.observe({ entryTypes: ['measure'] }) performance.measure('test', 'start', 'end'); ``` 如上一段代码，他的执行时间是： `15ms` ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2d07cef3e5504cb0a21e5fbb986ccdd0~tplv-k3u1fbpfcp-watermark.image?) 输入命令`node --trace-opt v8-template1.js`，观察一下他的优化过程 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e2e0297c2aa44172bd3af2c4652a95b2~tplv-k3u1fbpfcp-watermark.image?) 可以看出`add` 这个方法已经被`Turbofan` 优化了，原因是因为这是一段高频且稳定的代码。接着，我们把上面注释掉的 `add(num1, 'x'); ` 放开，然后再跑一次 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b7a5073c0a7d4c07b962e7fb9534c228~tplv-k3u1fbpfcp-watermark.image?) 发现执行时间变长了，why？输入命令`node --trace-deopt v8-template1.js`，观察下他的反优化过程 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/53beaf070b244135bbccf37e8eb566fd~tplv-k3u1fbpfcp-watermark.image?) 清晰的看到，上面反优化的原因是因为入参的反馈类型不足，其实就是，一直都是两个数字相加，突然有一个变成了字符串，产生了不确定性`v8`不知道该怎么优化了，也就是对应上图中绿色的`DeOptimize`的步骤。 `v8` 的源码中详细的列出了会导致反优化的场景：还有一篇对应的不错的解释： [Optimization killers](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers)，阔以研究一下。 #### 网络传输相关问题 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7a9a7d3f1c0542d3a44a2f7092ebe6c7~tplv-k3u1fbpfcp-watermark.image?) 启用`http2` 上文说了，`http2`有两个很大的优势是： 1. 多路复用，解除了浏览器最大链接数的限制 2. 服务端推送，节省了`TTFB`的时间我们来实际观察一下： `http1`: ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f034564e308a4219995ed282f13fa0b4~tplv-k3u1fbpfcp-watermark.image?) `http2`: ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/86f7efb5c3804fd39dff4a172387be10~tplv-k3u1fbpfcp-watermark.image?) 服务端推送：正常的`http`请求，都会有一个从请求发出到接收到首字节的时间，这个就是`TTFB`，而`http2`服务端推送节省了这一时间（源码以上传： https://github.com/ycvcb123/performance-opt/tree/master/http2-demo）可以自己观察下。正常请求： ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e510cf4e534a427a985d2c974716c587~tplv-k3u1fbpfcp-watermark.image?) push: ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7e8ebb9084c64b318afaf61cd167ff85~tplv-k3u1fbpfcp-watermark.image?)

## 自动化性能检测工具介绍？ `PUPPETEER` + `LIGHTHOUSE` 源码以上传： https://github.com/ycvcb123/performance-opt/tree/master/puppeteer-lighthouse `puppeteer`是谷歌提供的一个无头浏览器（在无界面的情况下操作浏览器） `lighthouse` 谷歌官方提供了`node`版的使用方式大概的原理就是，通过`puppeteer`启动浏览器，解决一些登录态的问题，然后通过`lighthouse`检测页面性能，获取分析结果，自定义分析展示。 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3514ce7072c84ae09776867442b47001~tplv-k3u1fbpfcp-watermark.image?) 点击查看详情，可以看到`lighthouse` 的具体分析报告 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bc5ac6262214449a901192e30e94eb0b~tplv-k3u1fbpfcp-watermark.image?)

## 总结：关于性能优化的方案和知识点还有很多很多，对于不同的项目侧重点可能也不一样，日后也会慢慢补充进来，这方面的工作需要静下心来慢慢分析，多多尝试，某位伟人说过，耐心是一切聪明才智的基础，希望你我都可以在平时繁忙的需求中，可以抽一些时间出来，多一些沉淀，多一些进步。回想上一次在掘金写文章，居然还是2019年，2年多的时间，其实有很多可以记录的知识点，但是因为懒惰，没能写下来，以至于在跟别人讨论问题的某些时候，明明有一块的知识我曾经特别熟悉，但却不是能说的太清楚了，想翻下以前的记录，却发现一个字都没有。。。（像极了萧亚轩的那首《最熟悉的陌生人》），然后只能弱弱的说句：我以前研究过，不太记得了～，所以有时间还是尽量做一些记录，于人于己，百利无害。好习惯还是要捡起来！

#### 未完待续...我们下次见ヾ(￣▽￣)Bye~Bye~