1. 网络传输性能优化
image.png
浏览器在得到用户请求之后，经历了下面这些阶段：重定向→拉取缓存→DNS查询→建立TCP链接→发起请求→接收响应→处理HTML元素→元素加载完成。
1.1.浏览器缓存
浏览器在向服务器发起请求前，会先查询本地是否有相同的文件，如果有，就会直接拉取本地缓存
image.png
浏览器默认的缓存是放在内存内的，内存里的缓存会因为进程的结束或者说浏览器的关闭而被清除，硬盘里的缓存能够被长期保留下去。我们在network面板中各请求的size项里，会看到两种不同的状态：from memory cache 和 from disk cache，前者指缓存来自内存，后者指缓存来自硬盘。
而控制缓存存放位置的，不是别人，就是我们在服务器上设置的Etag字段。
在浏览器接收到服务器响应后，会检测响应头部（Header），如果有Etag字段，那么浏览器就会将本次缓存写入硬盘中。
拉取缓存会出现200、304两种不同的状态码，取决于浏览器是否有向服务器发起验证请求。 只有向服务器发起验证请求并确认缓存未被更新，才会返回304状态码。
强缓存，浏览器会直接拉取本地缓存，不会与服务器发生任何通信，也就是说，如果我们在服务器端更新了文件，并不会被浏览器得知，就无法替换失效的缓存。
1.2.资源打包压缩
浏览器缓存工作，只有在用户第二次访问我们的页面才能起到效果。
如果首次打开页面就实现优良的性能，必须对资源进行优化。
我们常将网络性能优化措施归结为三大方面：减少请求数、减小请求资源体积、提升网络传输速率。
①JS压缩
②HTML压缩
③提取公共资源
|____抽离第三方插件
|____抽离自定义公共代码
④提取css并压缩
.
.
.
1.3.图片资源优化
①不要在HTML里缩放图像
②使用雪碧图
③使用字体图标
④使用CDN
2. 页面渲染性能优化
2.1页面渲染过程
image.png
浏览器内部的渲染引擎、解释器等组件的关系，
image.png
Chrome（现在使用的是Blink引擎）和Safari使用的Webkit引擎，Firefox使用的Gecko引擎，指的就是渲染引擎。
而在渲染引擎内，还包括着我们的HTML解释器（渲染时用于构造DOM树）、CSS解释器（渲染时用于合成CSS规则）还有我们的JS解释器。不过后来，由于JS的使用越来越重要，工作越来越繁杂，所以JS解释器也渐渐独立出来，成为了单独的JS引擎，就像众所周知的V8引擎
2.2DOM渲染层与GPU硬件加速
image.png
页面是由多个DOM元素渲染层（Layers）组成的，页面在构建完render tree之后，是经历了这样的流程才最终呈现在我们面前的：
①浏览器会先获取DOM树并依据样式将其分割成多个独立的渲染层
②CPU将每个层绘制进绘图中
③将位图作为纹理上传至GPU（显卡）绘制
④GPU将所有的渲染层缓存（如果下次上传的渲染层没有发生变化，GPU就不需要对其进行重绘）并复合多个渲染层最终形成我们的图像
从上面的步骤我们可以知道，布局是由CPU处理的，而绘制则是由GPU完成的
2.3.重排与重绘
①重排（reflow）：渲染层内的元素布局发生修改，都会导致页面重新排列，比如窗口的尺寸发生变化、删除或添加DOM元素，修改了影响元素盒子大小的CSS属性（诸如：width、height、padding）。
②重绘（repaint）：绘制，即渲染上色，所有对元素的视觉表现属性的修改，都会引发重绘
不论是重排还是重绘，都会阻塞浏览器。要提高网页性能，就要降低重排和重绘的频率和成本，近可能少地触发重新渲染。
2.4.优化策略
- 通过切换class或者style.csstext属性去批量操作元素样式
- 将没用的元素设为不可见：visibility: hidden，这样可以减小重绘的压力，必要的时候再将元素显示
- 压缩DOM的深度，一个渲染层内不要有过深的子元素，少用DOM完成页面样式，多使用伪元素或者box-shadow取代
- 图片在渲染前指定大小：因为img元素是内联元素，所以在加载图片后会改变宽高，严重的情况会导致整个页面重排，所以最好在渲染前就指定其大小，或者让其脱离文档流
JS阻塞性能
在编程的过程中，如果我们使用了闭包后未将相关资源加以释放，或者引用了外链后未将其置空（比如给某DOM元素绑定了事件回调，后来却remove了该元素），都会造成内存泄漏的情况发生，进而大量占用用户的CPU，造成卡顿或死机。
作者：jerryOnlyZRJ
链接：https://juejin.im/post/5b6fa8c86fb9a0099910ac91
来源：掘金
网友评论