1. 预载
预加载方法有两种：
A. 显式加载
我称之为显式加载，用户可以明显地感知到。 建议将这些加载表单添加到交互页面中。 一方面可以降低页面的趣味性，另一方面可以让后续的页面体验更加流畅。
B、隐式加载
这种在加载第一个图片时预加载第二个图片的方法，从而使页面体验更加流畅，我称之为隐式加载。 改善体验。
2. 按需加载
按需加载是优化不可或缺的手段，主要有以下两种形式：
这些方法在首屏加载的时候就尽可能加载首屏的内容，而位于首屏之外的元素只有出现在首屏时才加载css3图片变大，这样就大大节省了流量，提高了首屏的性能。正在加载。 时间。
这就是所谓的响应式加载，就是利用JS或者CSS来判断帧率css3图片变大，从而选择不同规格的图片导入。 这样做的好处是显而易见的，还可以提升加载率，节省流量。
3. 压缩图像
对于压缩图片，首先要提到的是jpg文件：
对于移动端的JPG文件，有这样的推论：
使用大格式、高有损压缩比的jpg
使用 jpegtran 进行无损压缩
对于 png 有以下推论：
彩色图片使用png24
对低颜色图像使用 png8
推荐使用pngquant
尽量避免重定向
为什么要尝试避免重定向？ 因为如图所示：
这是相同网速下的测试结果。 重定向之所以慢是因为它重复域名查找、tcp连接、发送请求。
5.用其他方法替换图像
有两种形式，第一种是：依靠CSS 3来勾画图像：
第二种：使用iconfont替换图片
但iconfont不一定比图片好，这里做个实验：
对于大图像，iconfont 并不比精灵图像更好。 对于一侧的小尺寸图标，建议使用 iconfont。
那么，对于脚本执行中的优化方法，这里只说两点：
1. 尽量避免DataURI
DataUri在移动端并不像在PC端那么受欢迎，因为：
经测试，DataURI比简单的外部链接资源慢6倍，生成的代码文件大小相比图片文件没有减少，但更小，浏览器在解码过程中需要消耗显存和CPU这些base64，这对移动端的好处非常显着。
2.点击风暴优化
移动端请使用touchstart、touchend、touch等暴风雨来代替延迟比较大的Click事件。 由于 mousedown，点击速度很慢：
那么，对于渲染阶段的优化方法，这里只说两点：
1.动画优化
a) 尝试使用css3动画
优势：
不占用js主线程
可以通过硬件加速
浏览器可以优化动画
缺点：
不支持中间状态窃听
b) 适当使用canvas动画
优势：
通过绕过渲染树估计渲染速度更快
缺点：
开发成本高，维护麻烦。
通过CSS 3动画和Canvas动画的对比：
得到推论：小于5个元素使用css3动画，大于5个元素使用canvas动画。
c) 合理使用RAF(requestAnimationFrame)
优势：
可以解决脚本问题导致的丢帧、卡顿问题
支持中间状态窃听
缺点：
兼容性问题
RAF动画和settimeout动画对比：
得到推论：如果不需要兼容android 4.3浏览器，请使用RAF制作脚本动画
2.高频风暴优化
像触摸移动和滚动这样的风暴可能会导致多重渲染。 这些风暴可以通过以下方法进行优化：
1.使用requestAnimationFrame监听帧变化，以便在正确的时间进行渲染
2.增加响应变化的时间间隔，减少重绘次数。
最后，只有一项针对合成/绘图的优化：
GPU加速
触发GPU加速的方法有：
CSS3 过渡
CSS3 3D 变换
WebGL 3D 渲染
视频
……
使用GPU加速之前有一个对比实验：
GPU加速实际上大大减少了合成/绘制时间，从而大大提高了页面速率，但GPU加速也有其自身的缺点：
过多的GPU层数会带来性能开销。 主要原因是使用GPU加速使用了GPU层的缓存，这样渲染资源就可以被复用，所以一旦层数多了，缓存就减少了，就会导致其他性能问题。 。
总结
本文针对页面呈现的四个阶段提出了典型的优化方法。 最后，我想提醒读者：其实，优化是一把双刃剑。
按需加载提高了速度，但可能会导致大量重绘；
触摸响应快，但很多场景不适合；
GPU加速效率高，但内存消耗大等。
加载会让整体体验流畅，但很容易造成用户流失
图像压缩会增加带宽成本，但可能会导致视觉效果较差
类似这样的矛盾还很多，请结合业务根据实际情况进行优化。
