小白也能看的懂的页面性能优化来一波

前言

当你以为页面很卡的时候，你有可能须要更换手机，固然也可让对应的同窗进行性能优化了。本文适用给技术小白 & 部分前端同窗。

固然了，笔者在写文本以前也针对了部门内部和公司内部的部分H5页面的性能进行粗略的评估，结果固然是很是不使人满意的。或许咱们忙于业务，可是有时候咱们仍是要停下来评估性能，不能把性能优化一直说在嘴上。

开始正经文章

前面也说了，页面很卡，那到底很卡是怎么一个概念的，或者是说这么去衡量一个页面很卡，大概总结了下，能够分为如下几点：

1. 页面加载出现较长时间的白屏，术语：弱网环境下量化在不能超过4s
2. 页面在加载过程当中出现了明显的页面抖动或屡次白屏，术语：页面重排耗能厉害
3. 移动端页面中动画出现了明显的卡顿，术语:FPS低于了40帧
4. 移动端页面在行为交互（按钮点击／页面滚动）的时候出现明显的卡顿，术语:FPS低于了40帧

当咱们了解如何经过直观&客观去简单判断一个页面是否卡后，咱们能够定性该页面是否须要开发同窗去介入进行性能优化。那么性能优化方式又有哪些呢？

1. 页面自己及其静态资源大小减小 & 数量减小
2. 页面交互方式优化，eg：初始化禁止轮播，图片lazyload等
3. 页面视觉优化
4. 页面代码自己优化
5. 其余：太繁琐，省略1W字

可是说到具体的性能优化方案的话咱们应该怎么选择，咱们所产出的网站在编码方式／打包方式等等诸多方面有较大的不一样，这也给咱们性能优化增长很大难度。也说明了真正作好性能优化很难，就看你的预期和实际的gap。

既然说到了预期和实际的差距，咱们来讲说下如何快速缩小这个差距吧，而不是彻底解决。特整理了如下大概的处理方法

1. 砍加载时间最长的线

绿色区域表示TTFB／蓝色表示LOAD／灰色表示wait或Stalled

1. 缩小TTFB
2. 减小wait时间 -> 每次只能同时发起5个http请求，咱们须要考虑咱们的打包方式，该规整
3. 缩小部分大文件 -> base文件是否有冗余代码，是否能够拆解到其余文件，均匀分布
4. 合理应用gzip -> flexlbie.js gzip后文件反而大了，得不偿失

综上所属，咱们必须控制打包方式，尽可能减小冗余代码的加载，以及均匀分配js文件的大小，避免出现较小的js／css文件。固然了http数量方面仍是须要减小，在大小和数量取时间最小值吧。最后也要说明一点的事情，部分时候咱们会依赖于第三方服务，可能须要第三方的配合来优化。

1. lazyload添加和适当的交互干涉

右下角有个比较明显的1/5，即表示为轮播

• 原有逻辑：当页面渲染过程当中会批量加载全部图片，且当js加载完毕后即执行轮播，可能会出现图片尚未显示彻底即下一张
• 优化后的逻辑：当页面渲染完成前禁止加载未显示的图片，当页面未渲染完毕&图片未加载完毕前不进行任何轮播操做

如上的处理方式一方面优化首屏的加载大小，也保证页面过程不会由于动画执行致使页面总体渲染卡顿

1. 视觉干预

白屏时间不管如何都没法避免，这个时候咱们须要部分的视觉欺骗。具体方式如上图，在加载过程当中给页面默认背景色，在页面开始加载时即会出现load图，这种状况下面会适当的给页面续命，预计可让用户多等几秒

若是你处理好前面三点后，再删除一些console等冗余代码后，恭喜你，你基本上已经完成页面80%及其以上的性能提高，并且在投入产出比上面很是高，估计1-2天绝对够了，并且仍是很是值得投入的。

说在最后

其实性能优化真的一个佛系的操做，前面的优化很是的容易，后面10-20%优化就没有底了，这种仍是须要有同窗有必定的前端功底，深知须要对页面进行彻底颠覆重构。可是前面的优化确实能够考虑。

ps：早睡早起，常作运动，多与异性交朋友～