老生常谈的性能优化再来讲一遍给大家

深碍√TFBOYSˉ_ 2022-12-02 15:28 112阅读 0赞

高手过招往往不是考量谁知道的知识点多，而是招招致敌！  
  
很多人在刚开始学习做性能优化的时候，就是眉毛胡子一把抓，把知道的、想做的、能做的都一股脑都做了，这就是典型的看上去很勤奋的奋斗逼！  
  
苦哈哈的干了很多活，也落了地，确实性能得到了优化。但是要知道代码是一坨一坨的长大的，它不是你在那里优化一下，它就不动了的，于是乎过不了多长时间，又是一番难以想象的光景！  
  
真正懂得优化的高手是真正懂得“权衡”真谛哲学的人。其实我们说一个人在权衡的时候，它的底层逻辑其实就是他的认知范围内的数据的比较，是2/8原则，是优先级，是四象限法则，是时间管理，是人力管理，是成本管理，是抓大放小，更是审时度势！

## 环境判定 ##

首先要了解自己是处于一个什么样的环境。是做移动端页面的优化还是 PC 端页面的优化，是做首屏页面的优化还是做次级页面的优化，是做首跳场景的优化还是做二跳场景的优化...

## 数据 KPI ##

光是知道干活不知道拿钱的，一般我们称之为傻瓜。所以一开始你就要明确的知道什么东西是可以帮助你赚 money 的。

如果你有关注客户服务和销售团队的常见工单，研究高跳出率和低转化率的原因的话，会发现也许你觉得非常重要的某些指标其实并那么重要(比如一个季度都没什么人用的功能页面)。

我想现在你知道我在说的是业务价值，一定要把你的每一分钱都花在刀刃上！

假设你想比你的竞争对手至少快20%，这个时候你需要去选定你的目标。

*  TTFB(Time To First Byte):
 *   *  首字节时间，是反映服务端响应速度的重要指标
     *  浏览器开始收到服务器响应数据的时间 = 后台处理时间 + 重定向时间
 *  FID(First Input Delay)：
 *   *  从用户首次与网站进行交互到浏览器实际上能够响应该交互的时间
     *  可以集成web-vitals
 *  白屏时间（first Paint Time)
 *   *  用户从打开页面开始到页面开始有东西呈现为止
     *  `(chrome.loadTimes().firstPaintTime - chrome.loadTimes().startLoadTime)*1000`
     *  `window.performance.timing.responseEnd – window.performance.timing.fetchStart`
 *  核心内容展示时间(Largest Contentful Paint)
 *  资源大小

这些是不是你觉得最应该关注的。可是这还不够，因为你是迷茫的。如果变成这样：  
**3G环境下**

*  FID < 100ms：从用户首次与网站进行交互到浏览器实际上能够响应该交互的时间
 *  TTI < 5s：布局已经稳定、关键的Web字体可见、并且主线程已经空闲下来可以处理用户输入的时间点
 *  LCP < 3s：标记可视区已加载页面重要内容的时间点
 *  关键文件大小 < 170KB (gzip压缩后)

是不是觉得可以开干了！来思考一个问题，你的页面现在的问题到底在哪？是什么东西影响了这些指标，是否有可衡量的工具？

## 性能监测 ##

拿到一个有问题的项目的时候，可以从以下几个角度初探问题所在：  
有没有没有用的接口仍然在调用；  
有没有加入非常大的第三方包没有走CDN；  
有没有并发请求阻塞资源的加载，比如一个页面调了十几个接口；  
有没有非常大的业务资源因输入没有控制，导致有超常规大小的业务资源；  
....  
这些问题是我在大型项目开发中遇到过的，因为它有一个非常响当当的名字叫“历史遗留问题”，所以很容易成为钉子户。  
  
浏览器是有自带一个 Performance 面板，具备可视化功能。但是你要知道什么人更加看重这个数据，同时这些数据也不利于分享，最最重要的是它无法自动的随时随地、不间断的进行监视、测量。所以通常都会有自研的 SDK 去获取 `window.performance` 下的数据进行二次处理后做更加深层次的可视化。有用的可视化数据会推动建立长期关注性能的团队文化。

## 性能优化的底层逻辑 ##

其实深入思考一下就知道，性能优化的环节无非网络加载、渲染优化、文件优化、用户体验层面。其实什么 DNS、CDN、TCP、各级缓存、Gzip压缩、代码压缩混淆啊什么的基本上在架构层都考虑到了，一劳永逸的事情，几乎不需要你操心！用户体验上加个loading、进度条、骨架屏什么的也都是通用解决方案。  
  
你总在思考解决方案的无非这三种情况：

*  在整个链路中减少中间环节：比如将串行改成并行。
 *  尽可能的预加载、预执行、懒加载
 *  渐进式、分片段

## SSR 值不值得 ##

SSR 是当用户第一次请求页面时，由服务器把需要的组件或页面渲染成 HTML 字符串，然后把它返回给客户端。  
通常人们考虑 SSR 方案时都是奔着解决 CSR 下的 SEO 问题以及首屏加载速度过慢的问题。这里我们主要考虑性能。大家思考一下直出方案到底优化的是哪部分的时间？省去的是 \*\*前端渲染 \*\*以及 \*\*ajax请求 \*\*的时间吧！因为它把所有的计算都放到服务端了。  
  
但是 html 会比 CSR 的文件大吧！！！同时距离服务端远的用户也是会有比较长时间的白屏的！

### 离线包还是 PWA ###

所以通常移动端又会通过**离线包技术**去解决 html 本身文件加载时间的问题。离线包的基本思路就是通过 web view 统一拦截 URL，将资源映射到本地离线包，更新的时候对版本资源检测、下载和维护本地缓存目录中的资源。比如腾讯的 webso 和 Alloykit 的离线包方案。离线包是对 web 端而言相对透明、侵入性非常小的方案。

**PWA** 是通过纯 web 的方案去加速和优化加载性能。其通过 cacheStorage 缓存静态资源。  
但在传统的 http cache 方案下，我们一般不会缓存 HTML。这是因为 CSR 的 html 是一个空壳，我们一般会设置比较大的 max-age，这样在浏览器缓存过期时间内，用户看到的永远将是旧的页面。  
而对于直出 HTML，配合PWA，将从后台直出的 html 文件缓存到 cacheStorage 中，在下一次请求时，优先从本地缓存中获取，同时发起网络请求更新本地 html 文件。

接着又会发现有新的问题，就是第一次启动时加载 html 资源还是费时间的。可以通过 app 端上支持预加载一个JS 脚本，拉取需要 PWA 缓存的页面，提前完成缓存！  
  
对于前端而言，PWA 无疑会是更好的解决方案，但是 PWA 不是万能的，它有兼容性问题。比如只支持https。  
另离线包方案和 PWA 方案本身是可以有一个数据 PK 的。其实很多同学都是上了PWA，但从来没想过如果尝试把它拿掉，数据是否会有变化。

### SSR 的成本 ###

现阶段我们知道的解决方案都是基于 Node 的，也就意味着要上 SSR 必须得有 Node 中间层。也即意味着你需要有能够 hold 住 node 运维及架构能力的人力，还有服务端等硬件成本。同时因为服务端渲染的差异性，也会出现客户端正常而服务端异常的情况。前后端分离可能会出现平滑发布的问题：当页面的静态资源(js、css)的发布不是与后端一起发布时，可能引起后端返回的 HTML 内容与前端的 JS、CSS内容不匹配的问题。如果没做兼容处理，可能会出现样式错乱或者 document 选择器找不到元素的问题。  
  
所以加上SSR到底值不值得，小马过河！通常我们建议首屏渲染体验和 SEO 的优化方案有很多，不到万不得已不要用 SSR。

### NSR ###

如果说 SSR 放到服务器端成本比较大，那有没有可能放到客户端来。借助浏览器启用一个JS-Runtime，提前将下载好的 html 模板及预取的 feed 流数据进行渲染，然后将 HTML 设置到内存级别的 MemoryCache 中，从而达到点开即看的效果。  
  
这是一种将后台请求压力分发到各个客户端中的方案，同时因为客户端有数据预取和预加载，速度也能达到秒开。但是又有一个问题，预加载意味着你得是个算命先生！

### ESI (Edge Side Include) ###

更重要的是如果是首跳页面，什么预加载，预执行，预渲染都旁边呆着去吧！除了服务端和客户端，我们是不是还有一个地方可以放资源，对了，就是代理端，比如 CDN。  
![format_png][]  
CDN 比服务端距离用户更近，有更短的网络延时。在CDN节点上将可缓存的页面静态部分先快速返回给用户，同时在CDN节点上发起动态部分内容请求，并将动态内容在静态部分的响应流后，继续返回给用户。  
![format_png 1][]

*  首屏 TTFB 会很短，静态内容（例如页面 Header 、基本结构、骨骼图）可以很快看到。
 *  动态内容是由 CDN 发起，相比于传统浏览器渲染，发起时间更早，且不依赖浏览器上下载和执行 js。理论上，最终 reponse 完结时间，与直接访问服务器获取完整动态页面时间一致。
 *  在静态内容返回后，已经可以开始部分 html 的解析，以及 js, css 的下载和执行。把一些阻塞页面的操作提前进行，等完整动态内容流式返回后，可以更快地展示动态内容。
 *  边缘节点与服务端之间的网络，相比于客户端与服务端之间的网络，更有优化空间。例如通过动态加速，以及 edge 与 server 之间的连接复用，能为动态请求减少 TCP 建连和网络传输开销。以做到最终动态内容的返回时间，比 client 直接访问 server 更快。

ESR 是需要借助 CDN 的边缘计算能力(保证了可以在CDN上做类似于service worker的操作，可对请求和响应做灵活的编程)，那如果 CDN 服务商不支持那就免谈啦！

## 用到什么加载什么 ##

懒加载

*  一次不加载完所有的文件内容，提前做拆分只加载此刻需要用到的那部分
 *  当需要更多内容时，再对用到的内容进行即时加载

**路由级别**：

*  `require.ensure(dependencies, callback, chunkName)`
 *  Bundle-Loader

**module 级别**：

*  `import()`

**内容级别**：  
图片 lazy-load:

### 渐进式 ###

把你的包拆的小小的，一点一点的加载。把最不重要的放到最后加载。  
配合使用 webpack 的 code spiltting 配置、splitChunks、external、dll等。

### 没用的代码删掉 ###

*  模块级别的冗余代码：Tree-Shaking
 *  碎片化的冗余代码（如 console 语句、注释等）: optimization.minimize && optimization.minimizer
 *  删除多余的声明语句：scope hoisting

## 代码到底该怎么写 ##

*  先切换`display:none`再修改样式
 *  通过`class`的切换批量修改样式
 *  用`transform`属性去操作动画
 *  meta viewport (可以加速页面渲染)
 *  `<img>`标签的 `loading`属性
 *  合理使用`Canvas`代替多`DOM Tree`
 *  使用`requestAnimationFrame`  
    
 *  使用`shouldComponentUpdate`
 *  及时清理定时器
 *  使用 `requestIdleCallback`
 *  使用`PureComponent`
 *  使用 `immutable-js`
 *  使用`Fragment`标签
 *  使用`Element.getBoundingClientRect()`获取可视区域
 *  使用`VDOM`
 *  使用防抖和节流
 *  大文件切片上传
 *  算法

## 总结 ##

我从宏观层面的监测及数据 KPI 到多端合作，最后从前端工程化以及微观代码层面讲述了性能优化的闭环，另外的网络状况、CDN，ISP，缓存覆盖，代理，第三方脚本、解析器阻塞模式、磁盘I/O、IPC延迟、防病毒软件和防火墙，负载均衡、后台CPU任务、和服务器配置等对web性能有着明显影响但是前端同学平常无法或较少关注的层面、以及静态资源例如图片、字体等的处理等大家较为熟悉的层面，因为考虑到网络上这方面的文章较多未多赘述。  
  
学过算法的同学应该都知道，加速本质上就是在用更多的网络、内存和 CPU 换取速度，以空间换时间！  
你要知道做性能优化在某些场景下你的决策是正确的，在某些场景下你的决策就是错误的。这才叫权衡！自动的随时随地、不间断的进行监视、测量你的项目性能，这是性能优化成熟的标志，因为你的环境和需求是一直在变化的。  
  
最后重点推荐一个性能优化的案例学习网站 WPO Stats，这个网站上有很多很不错的性能优化的案例分享。

## 参考资料 ##

[前端性能优化：当页面渲染遇上边缘计算][Link 1]  
[2020前端性能优化清单][2020]  
交互响应性能之FID

[format_png]: /images/20221123/e3a5455e7a4541f8a9db5e15b49491a8.png
[format_png 1]: /images/20221123/6072c23a1e5445eb8aaf82998b536820.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA%3D%3D&idx=1&mid=2247496301&scene=21&sn=5035b8ed597a24fdc9d8c7641a57399a#wechat_redirect
[2020]: https://mp.weixin.qq.com/s?__biz=MzI5NjIzNjA1Nw%3D%3D&idx=1&mid=2247484156&scene=21&sn=4d1057da5727fb874f6bd9f7857b94ce#wechat_redirect