前端性能优化(知识总结)

一、浏览器渲染引擎

主要模块

• 一个渲染引擎主要包括：HTML解析器，CSS解析器，javascript引擎，布局layout模块，绘图模块
• HTML解析器：解释HTML文档的解析器，主要作用是将HTML文本解释成DOM树。
• CSS解析器：它的作用是为DOM中的各个元素对象计算出样式信息，为布局提供基础设施
• Javascript引擎：使用Javascript代码可以修改网页的内容，也能修改css的信息，javascript引擎能够解释javascript代码，并通过DOM接口和CSS树接口来修改网页内容和样式信息，从而改变渲染的结果。
• 布局（layout）：在DOM创建之后，Webkit需要将其中的元素对象同样式信息结合起来，计算他们的大小位置等布局信息，形成一个能表达这所有信息的内部表示模型
• 绘图模块（paint）：使用图形库将布局计算后的各个网页的节点绘制成图像结果

  备注：文档对象模型（Document Object Model，简称DOM）

渲染过程

• 浏览器渲染页面的整个过程：浏览器会从上到下解析文档。
  1. 遇见 HTML 标记，调用HTML解析器解析为对应的 token （一个token就是一个标签文本的序列化）并构建 DOM 树（就是一块内存，保存着tokens，建立它们之间的关系）。
  2. 遇见 style/link 标记 调用解析器 处理 CSS 标记并构建 CSS样式树。
  3. 遇见 script 标记 调用 javascript解析器 处理script标记，绑定事件、修改DOM树/CSS树 等
  4. 将 DOM树 与 CSS树 合并成一个渲染树。
  5. 根据渲染树来渲染，以计算每个节点的几何信息（这一过程需要依赖图形库）。
  6. 将各个节点绘制到屏幕上。

以上这些模块依赖很多其他的基础模块，包括要使用到网络 存储 2D/3D图像 音频视频解码器 和 图片解码器。
所以渲染引擎中还会包括如何使用这些依赖模块的部分。

二、阻塞渲染

1.关于css阻塞：

声明：只有link引入的外部css才能够产生阻塞。
1.style标签中的样式：
    (1). 由html解析器进行解析；
    (2). 不阻塞浏览器渲染（可能会产生“闪屏现象”）；
    (3). 不阻塞DOM解析；
    
2.link引入的外部css样式（推荐使用的方式）：
    (1). 由CSS解析器进行解析。
    (2). 阻塞浏览器渲染(可以利用这种阻塞避免“闪屏现象”)。       
    (3). 阻塞其后面的js语句的执行：
    (4). 不阻塞DOM的解析：
                 
3.优化核心理念：尽可能快的提高外部css加载速度
    	(1).使用CDN节点进行外部资源加速。
	    (2).对css进行压缩(利用打包工具，比如webpack,gulp等)。
	    (3).减少http请求数，将多个css文件合并。
	    (4).优化样式表的代码

2.关于js阻塞：

1.阻塞DOM解析:
    	原因：浏览器不知道后续脚本的内容，如果先去解析了下面的DOM，而随后的js删除了后面所有的DOM，
          那么浏览器就做了无用功，浏览器无法预估脚本里面具体做了什么操作，例如像document.write
          这种操作，索性全部停住，等脚本执行完了，浏览器再继续向下解析DOM。	
2.阻塞页面渲染:
    	原因：js中也可以给DOM设置样式，浏览器同样等该脚本执行完毕，再继续干活，避免做无用功。
3.阻塞后续js的执行:
    原因：维护依赖关系，例如：必须先引入jQuery再引入bootstrap

3.备注

【备注1】：css的解析和js的执行是互斥的（互相排斥），css解析的时候js停止执行，js执行的时候css停止解析。

【备注2】：无论css阻塞，还是js阻塞，都不会阻塞浏览器加载外部资源（图片、视频、样式、脚本等）
            原因：浏览器始终处于一种：“先把请求发出去”的工作模式，只要是涉及到网络请求的内容，
                无论是：图片、样式、脚本，都会先发送请求去获取资源，至于资源到本地之后什么时候用，
                由浏览器自己协调。这种做法效率很高。
                
【备注3】：WebKit 和 Firefox 都进行了【预解析】这项优化。在执行js脚本时，浏览器的其他线程会解析文档的其余部分，
          找出并加载需要通过网络加载的其他资源。通过这种方式，资源可以在并行连接上加载，
          从而提高总体速度。请注意，预解析器不会修改 DOM 树

在上述的过程中，网页在加载和渲染过程中会触发“DOMContentloaded”和“onload”事件
分别是在DOM树构建（解析）完成之后，以及DOM树构建完并且网页所依赖的资源都加载完之后

• 上面介绍的是一个完整的渲染过程，但现代网页很多都是动态的，这意味着在渲染完成之后，由于网页的动画或者用户的交互，
  浏览器其实一直在不停地重复执行渲染过程。（重绘重排），以上的数字表示的是基本顺序，这不是严格一致的，
  这个过程可能重复也可能交叉

三、图层与重绘重排

css图层

浏览器在渲染一个页面时，会将页面分为很多个图层，图层有大有小，每个图层上有一个或多个节点。
在渲染DOM的时候，浏览器所做的工作实际上是：
1. 获取DOM后分割为多个图层
2. 对每个图层的节点计算样式结果 （Recalculate style–样式重计算）
3. 为每个节点生成图形和位置 （Layout–重排,回流）
4. 将每个节点绘制填充到图层位图中 （Paint–重绘）
5. 图层作为纹理上传至GPU
6. 组合多个图层到页面上生成最终屏幕图像 （Composite Layers–图层重组）

图层创建的条件

Chrome浏览器满足以下任意情况就会创建图层：
1. 拥有具有3D变换的CSS属性
2. 使用加速视频解码的节点
3. 节点
4. CSS3动画的节点
5. 拥有CSS加速属性的元素(will-change)

重绘(Repaint)

重绘是一个元素外观的改变所触发的浏览器行为，例如改变outline、背景色等属性。浏览器会根据元素的新属性重新绘制，
使元素呈现新的外观。重绘不会带来重新布局，所以并不一定伴随重排。

需要注意的是：重绘是以图层为单位，如果图层中某个元素需要重绘，那么整个图层都需要重绘。
比如一个图层包含很多节点，其中有个gif图，gif图的每一帧，都会重回整个图层的其他节点，然后生成最终的图层位图。
所以这需要通过特殊的方式来强制gif图属于自己一个图层（translateZ(0)或者translate3d(0,0,0)
CSS3的动画也是一样（好在绝大部分情况浏览器自己会为CSS3动画的节点创建图层）

重排(Reflow 回流)

渲染对象在创建完成并添加到渲染树时，并不包含位置和大小信息。计算这些值的过程称为布局或重排

"重绘"不一定需要"重排"，比如改变某个网页元素的颜色，就只会触发"重绘"，不会触发"重排"，因为布局没有改变。
 但是，"重排"必然导致"重绘"，比如改变一个网页元素的位置，就会同时触发"重排"和"重绘"，因为布局改变了。

触发重绘的属性

    * color								* background									* outline-color
    * border-style						* background-image								* outline
    * border-radius						* background-position							* outline-style
    * visibility						* background-repeat								* outline-width
    * text-decoration					* background-size								* box-shadow

触发重排(回流)的属性

盒子模型相关属性会触发重布局			定位属性及浮动也会触发重布局：				改变节点内部文字结构也会触发重布局：
		* width							* top											* text-align
		* height						* bottom										* overflow-y
		* padding						* left											* font-weight
		* margin						* right											* overflow
		* display						* position										* font-family
		* border-width					* float											* line-height
		* border							* clear											* vertival-align
		* min-height																		* white-space

常见的触发重排的操作

Reflow 的成本比 Repaint 的成本高得多的多。DOM Tree 里的每个结点都会有 reflow 方法，
一个结点的 reflow 很有可能导致子结点，甚至父点以及同级结点的 reflow。在一些高性能的电脑上也许还没什么，
但是如果 reflow 发生在手机上，那么这个过程是非常痛苦和耗电的。

所以，下面这些动作有很大可能会是成本比较高的。
	当你增加、删除、修改 DOM 结点时，会导致 Reflow , Repaint。
	当你移动 DOM 的位置
	当你修改 CSS 样式的时候。
	当你 Resize 窗口的时候（移动端没有这个问题，因为移动端的缩放没有影响布局视口）
	当你修改网页的默认字体时。
	获取某些属性时(width,height...)
	注：display:none 会触发 reflow，而 visibility:hidden 只会触发 repaint，因为没有发生位置变化。

优化方案

如果我们需要使得动画或其他节点渲染的性能提高，需要做的就是减少浏览器在运行时所需要做的工作（尽量减少1234步）
1. 计算需要被加载到节点上的样式结果（Recalculate style–样式重计算）
2. 为每个节点生成图形和位置（Layout–回流和重布局）
3. 将每个节点填充到图层中（Paint Setup和Paint–重绘）
4. 组合图层到页面上（Composite Layers–图层重组）

• 1.元素位置移动变换时尽量使用CSS3的transform来代替对top left等的操作
  变换（transform）和透明度（opacity）的改变仅仅影响图层的组合
• 2.使用opacity来代替visibility
  (1).使用visibility不触发重排，但是依然重绘。
  (2).直接使用opacity即触发重绘，又触发重排（GPU底层设计如此！）。
  (3).opacity配合图层使用，即不触发重绘也不触发重排。
  原因：
  透明度的改变时，GPU在绘画时只是简单的降低之前已经画好的纹理的alpha值来达到效果，并不需要整体的重绘。
  不过这个前提是这个被修改opacity本身必须是一个图层。
• 3.不要使用table布局
  table-cell
• 4.将多次改变样式属性的操作合并成一次操作
  不要一条一条地修改DOM的样式，预先定义好class，然后修改DOM的className
• 5.将DOM离线后再修改
  由于display属性为none的元素不在渲染树中，对隐藏的元素操作不会引发其他元素的重排。
  如果要对一个元素进行复杂的操作时，可以先隐藏它，操作完成后再显示。这样只在隐藏和显示时触发2次重排。
• 6.利用文档碎片(documentFragment)------vue使用了该种方式提升性能。
• 7.不要把获取某些DOM节点的属性值放在一个循环里当成循环的变量
  当你请求向浏览器请求一些 style信息的时候，就会让浏览器flush队列，比如：
  1. offsetTop, offsetLeft, offsetWidth, offsetHeight
  2. scrollTop/Left/Width/Height
  3. clientTop/Left/Width/Height
  4. width,height
  当你请求上面的一些属性的时候，浏览器为了给你最精确的值，需要刷新内部队列，
  因为队列中可能会有影响到这些值的操作。即使你获取元素的布局和样式信息跟最近发生或改变的布局信息无关，
  浏览器都会强行刷新渲染队列。
  8.动画实现过程中，启用GPU硬件加速:transform: tranlateZ(0)
  9.为动画元素新建图层,提高动画元素的z-index

requestAnimationFrame----请求动画帧

 window.requestAnimationFrame()
 
	1.window.requestAnimationFrame() 
	    说明：该方法会告诉浏览器在重绘之前调用你所指定的函数
	    1.参数：该方法使用一个回调函数作为参数，这个回调函数会在浏览器重绘之前调用。
	            回调函数会被自动传入一个参数，DOMHighResTimeStamp，标识requestAnimationFrame()开始触发回调函数的当前时间
	
	    2.返回值：
                一个long整数，也成为请求 ID，是个非零值 ，是回调列表中唯一的标识，没别的意义。
 
	2.window.cancelAnimationFrame(requestID)
 		取消一个先前通过调用window.requestAnimationFrame()方法添加到计划中的动画帧请求。
 		requestID是先前调用window.requestAnimationFrame()方法时返回的ID.

四、缓存

1. 缓存理解

1. 缓存定义:
2. 浏览器在本地磁盘上将用户之前请求的数据存储起来，当访问者再次需要改数据的时候无需再次发送请求，直接从浏览器本地获取数据
3. 缓存的好处:
4. 减少请求的个数
5. 节省带宽，避免浪费不必要的网络资源
6. 减轻服务器压力
7. 提高浏览器网页的加载速度，提高用户体验

2. 缓存分类

1. 强缓存
2. 不会向服务器发送请求，直接从本地缓存中获取数据
3. 请求资源的的状态码为: 200 ok(from memory cache)
4. 协商缓存
5. 向服务器发送请求，服务器会根据请求头的资源判断是否命中协商缓存
6. 如果命中，则返回304状态码通知浏览器从缓存中读取资源
7. 强缓存 & 协商缓存的共同点
8. 都是从浏览器端读取资源
9. 强缓存 VS 协商缓存的不同点
   1. 强缓存不发请求给服务器
   2. 协商缓存发请求给服务器，根据服务器返回的信息决定是否使用缓存

3. 缓存使用示意图

4. 缓存中的header参数

1、强缓存的header参数

---

1. expires：
2. 这是http1.0时的规范；它的值为一个绝对时间的GMT格式的时间字符串，如Mon, 10 Jun 2015 21:31:12 GMT，如果发送请求的时间在expires之前，那么本地缓存始终有效，否则就会发送请求到服务器来获取资源
3. cache-control：max-age=number
4. 这是http1.1时出现的header信息，主要是利用该字段的max-age值来进行判断，它是一个相对值；资源第一次的请求时间和Cache-Control设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行；
5. cache-control常用的值（做一个简单了解即可）：
6. no-cache: 不使用本地缓存，需要使用协商缓存。先与服务器确认返回的响应是否被更改，如果之前的响应中存在Etag，那么请求的额时候会与服务器端进行验证，如果资源为被更改则使用缓存。
7. no-store: 直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
8. public：可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。
9. private：只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。
10. 注意：当cache-control与Expires共存的时候cache-control的优先级高

2、协商缓存的header参数

---

重点：协商缓存都是由服务器来确定缓存资源是否可用的，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问

• Last-Modified/If-Modified-Since:二者的值都是GMT格式的时间字符串

1. 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上Last-Modified的header，这个header表示这个资源在服务器上的最后修改时间
2. 浏览器再次跟服务器请求这个资源时，在request的header上加上If-Modified-Since的header，这个header的值就是上一次请求时返回的Last-Modified的值
3. 服务器再次收到资源请求时，根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。当服务器返回304 Not Modified的响应时，response header中不会再添加Last-Modified的header，因为既然资源没有变化，那么Last-Modified也就不会改变，这是服务器返回304时的response header
4. 浏览器收到304的响应后，就会从缓存中加载资源
5. 如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified的Header在重新加载的时候会被更新，下次请求时，If-Modified-Since会启用上次返回的Last-Modified值
6. 图例：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-A5dTzKAn-1592643718030)(https://i.imgur.com/GZqqDbS.png)]

---

• Etag/If-None-Match
  1. 这两个值是由服务器生成的每个资源的唯一标识字符串，只要资源有变化就这个值就会改变
  2. 其判断过程与Last-Modified/If-Modified-Since类似

---

• 既生Last-Modified何生Etag
  1. HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题
  2. 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET
  3. 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
  4. 某些服务器不能精确的得到文件的最后修改时间。

---

• 小结：

• 利用Etag能够更加准确的控制缓存，因为Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。

• Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。

5. 强缓存如何重新加载新的资源

• 通过更新页面中引用的资源路径，让浏览器主动放弃加载缓存去加载新的资源
• 示例：https://www.baidu.com/s?t=7aec0h3KB3Ba8lAbuyPg0AC0eDa59IvtDSmtMQBc6eW
• 好处：
  • 每次文件改变后query的值就会发生修改，当query值不同的时候也就是页面引用的资源路径不同。此时浏览器会主动加载新的资源。