前端优化的几个点

开始之前

最近一直在赶项目，持续的连轴转让脑子都慢了。。。现在大概已经初步完成了，回过头来复盘一下，有很多需要优化的地方。

以下内容仅仅是列一些我们经历的、操作过的优化思路，仅供参考。

优化的目的

优化无非就是增强体验感，如果使用的时候出现卡顿、等待，甚至崩溃，那么必然体验是失败的。此时就需要进行优化。

优化的几个点

这里以我们项目中很长的一个页面为例，该页面中有大约400个组件，每个组件都需要数据请求，组件大部分都是表格和图表（echart）。嗯，这就是大概的前提。

1、拆分页面

如果可能，还是尽量不要设计信息量巨大的页面，尤其是页面展示很长的那种，因为毕竟需要向下滑动才能看到，不如切换页面。该方案可以最大程度优化所有问题。

尽可能将不同类别、不同场景、不同使用的内容，分别放到不同的页面，不要将所有内容糅杂在一个页面，这样不仅开发费劲，优化费劲，使用起来也很费劲。

2、懒加载

如果一次性将所有内容都渲染出来，必然会导致卡顿甚至崩溃，这个时候可以使用懒加载。懒加载可以减少一次渲染的数量，大大提高体验感。

懒加载的实现方式各不相同，但其原理大体相通，都是基于可视范围进行渲染。

常用的懒加载方案：

• 手动计算
  这个需要每一个组件都有一定的高度，然后根据高度计算是否在可视范围内
• 使用 IntersectionObserver API 来实现
  该 API 通过观察每个组件，如果出现在视口，则渲染并执行回调。在我的实际使用中，该 API 对于量巨大的数据效果并不友好，它需要给每一个对象都添加一个 API，然后才能观察。那么这个时候，如果数据量巨大，就会在创建期有一个很大的计算压力，但后续效果还不错。这也算是一个缺点吧
• 通过 lazy-component 组件
  通过懒加载组件实现。目前我们使用的是该方案。它使用简单，只需要在需要懒加载的组件外部套一层，它会自动计算。

3、数据加载方式

在页面加载过程中，一个很重要的耗时操作就是数据加载，尤其是 请求数据-接收数据 这个阶段，是非常考验网速的，如果遇到网速慢、请求数量多的情况，那么就等着吧，页面会长时间渲染不出东西的。

虽然现在数据请求一般都使用 Promise，但同时请求毕竟会相互侵占带宽，不如一个一个请求，请求回来一个渲染一个，最起码可以持续显示东西，不会是一开始白屏，紧跟着后续一下子全出来。（好像也是首页白屏的痛点）

一个很简单的方案，使用消息队列。这个在前段用的应该不是很多，但如果遇到同时请求数量很多的，可以尝试使用，无非就是通过一个 Promise 来回回调，进来一个请求一个，请求完成继续下一个。

这也是为什么不能用 Promise.all 的原因。它的本质还是同时请求，等于没有优化。

4、组件优化

针对某些组件，可能在写法上并不友好，对渲染也不友好，此时就要进行改造甚至弃用。

比如 element-ui 的表格，在渲染上贼慢，而且表头和表身的滚动分离（设计所致），导致体验很不友好，就需要大改。我们最后用 div 自行解决。当然也可以使用一些其他表格框架来替代。

再比如 echart，这个应该算是现在前端图表展示的不二选择。如果页面上有很多图表，那么未知的问题也会越来越多。虽然 echart 优化的非常好（甚至比表格性能高很多），但也避免不了优化的几个点。

• canvas -> svg
  性能高一点，但也有缺点，不支持富文本了
• 关掉动画效果
  不得不说，动画就算优化的再好，都不如直接关掉。当我们把图表动画关掉以后，性能提升了不止一点，可以说有质的提升。

5、按需引入

为了减少加载包的大小，一定要按需引入，尤其是那些东西很多，但只用了一点点的包，比如 lodash。

包括组件也一样，有些组件可能仅仅在一个地方用，这样根本无需全局引入。

6、webpack 拆分

跟上面一样，也是为了减少加载包的大小，这个问题老生常谈了。

最后

以上仅仅是我对此次项目优化的一点阶段性总结与回顾，梳理一下，仅供参考。