前言
当你觉得页面很卡的时候，你有可能需要更换手机，当然也可以让对应的同学进行性能优化了。本文适用给技术小白 & 部分前端同学。
当然了，笔者在写文本之前也针对了部门内部和公司内部的部分H5页面的性能进行粗略的评估，结果当然是非常不令人满意的。或许我们忙于业务，但是有时候我们还是要停下来评估性能，不能把性能优化一直说在嘴上。
开始正经文章
前面也说了，页面很卡，那到底很卡是怎么一个概念的，或者是说这么去衡量一个页面很卡，大概总结了下，可以分为以下几点：
- 页面加载出现较长时间的白屏，术语：弱网环境下量化在不能超过4s
- 页面在加载过程中出现了明显的页面抖动或多次白屏，术语：页面重排耗能厉害
- 移动端页面中动画出现了明显的卡顿，术语:FPS低于了40帧
- 移动端页面在行为交互（按钮点击／页面滚动）的时候出现明显的卡顿，术语:FPS低于了40帧
当我们了解如何通过直观&客观去简单判断一个页面是否卡后，我们可以定性该页面是否需要开发同学去介入进行性能优化。那么性能优化方式又有哪些呢？
- 页面本身及其静态资源大小减少 & 数量减少
- 页面交互方式优化，eg：初始化禁止轮播，图片lazyload等
- 页面视觉优化
- 页面代码本身优化
- 其他：太繁琐，省略1W字
但是说到具体的性能优化方案的话我们应该怎么选择，我们所产出的网站在编码方式／打包方式等等诸多方面有较大的不同，这也给我们性能优化增加很大难度。也说明了真正做好性能优化很难，就看你的预期和实际的gap。
既然说到了预期和实际的差距，我们来说说下如何快速缩小这个差距吧，而不是完全解决。特整理了以下大概的处理方法
- 砍加载时间最长的线
绿色区域表示TTFB／蓝色表示LOAD／灰色表示wait或Stalled
1. 缩小TTFB
2. 减少wait时间 -> 每次只能同时发起5个http请求，我们需要考虑我们的打包方式，该规整
3. 缩小部分大文件 -> base文件是否有冗余代码，是否可以拆解到其他文件，均匀分布
4. 合理应用gzip -> flexlbie.js gzip后文件反而大了，得不偿失
综上所属，我们必须控制打包方式，尽量减少冗余代码的加载，以及均匀分配js文件的大小，避免出现较小的js／css文件。当然了http数量方面还是需要减少，在大小和数量取时间最小值吧。最后也要说明一点的事情，部分时候我们会依赖于第三方服务，可能需要第三方的配合来优化。
- lazyload添加和适当的交互干涉
右下角有个比较明显的1/5，即表示为轮播
- 原有逻辑：当页面渲染过程中会批量加载所有图片，且当js加载完毕后即执行轮播，可能会出现图片还没有显示完全即下一张
- 优化后的逻辑：当页面渲染完成前禁止加载未显示的图片，当页面未渲染完毕&图片未加载完毕前不进行任何轮播操作
如上的处理方式一方面优化首屏的加载大小，也保证页面过程不会因为动画执行导致页面整体渲染卡顿
- 视觉干预
白屏时间无论如何都无法避免，这个时候我们需要部分的视觉欺骗。具体方式如上图，在加载过程中给页面默认背景色，在页面开始加载时即会出现load图，这种情况下面会适当的给页面续命，预计可以让用户多等几秒
如果你处理好前面三点后，再删除一些console等冗余代码后，恭喜你，你基本上已经完成页面80%及其以上的性能提升，而且在投入产出比上面非常高，估计1-2天绝对够了，而且还是非常值得投入的。
说在最后
其实性能优化真的一个佛系的操作，前面的优化非常的容易，后面10-20%优化就没有底了，这种还是需要有同学有一定的前端功底，深知需要对页面进行完全颠覆重构。但是前面的优化确实可以考虑。
ps：早睡早起，常做运动，多与异性交朋友～