前端性能优化

输入URL，页面发生了什么

从输入URL到页面加载完成的过程：

• DNS查询，如果这一步做了智能DNS解析的话，会访问速度最快的IP地址回来
• 接着是TCP握手，应用层会下发数据层给传输层，这里TCP协议会指明两端的端口好，然后下发给网络层。网络层中的IP协议会确定Ip 地址，并且指示数据传输中如何跳转路由器。然后包会再被封装数据链路层的数据帧结构中，最后就是无力层面的传输了。
• TCP 握手结束后会进行 TLS 握手，然后就开始正式的传输数据
• 数据在进入服务端之前，可能还会先经过负责负载均衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时假设服务端会响应一个 HTML 文件
• 首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向，这里会有个重定向计数器，避免过多次的重定向，超过次数也会报错
• 浏览器开始解析文件，如果是 gzip 格式的话会先解压一下，然后通过文件的编码格式知道该如何去解码文件。
• 件解码成功后会正式开始渲染流程，先会根据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话，会判断是否存在 async 或者 defer ，前者会并行进行下载并执行 JS，后者会先下载文件，然后等待 HTML 解析完成后顺序执行，如果以上都没有，就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件，这里如果使用 HTTP 2.0 协议的话会极大的提高多图的下载效率。
• 初始的 HTML 被完全加载和解析后会触发 DOMContentLoaded 事件
• CSSOM 树和 DOM 树构建完成后会开始生成 Render 树，这一步就是确定页面元素的布局、样式等等诸多方面的东西
• 在生成 Render 树的过程中，浏览器就开始调用 GPU 绘制，合成图层，将内容显示在屏幕上了

我们从输入 URL 到显示页面这个过程中，涉及到网络层面的，有三个主要过程：

• DNS 解析
• TCP 连接
• HTTP 请求/响应

对于 DNS 解析和 TCP 连接两个步骤，我们前端可以做的努力非常有限。相比之下，HTTP 连接这一层面的优化才是我们网络优化的核心。

HTTP 优化有两个大的方向：

• 减少请求次数

• 减少单次请求所花费的时间

缓存浏览器

浏览器缓存机制有四个方面，它们按照获取资源时请求的优先级依次排列如下：

• Memory Cache

• Service Worker Cache

• HTTP Cache

• Push Cache

MemoryCache

      MemoryCache，是指存在内存中的缓存。从优先级上来说，它是浏览器最先尝试去命中的一种缓存。从效率上来说，它是响应速度最快的一种缓存。浏览器秉承的是“节约原则”，我们发现，Base64 格式的图片，几乎永远可以被塞进 memory cache，这可以视作浏览器为节省渲染开销的“自保行为”；此外，体积不大的 JS、CSS 文件，也有较大地被写入内存的几率——相比之下，较大的 JS、CSS 文件就没有这个待遇了，内存资源是有限的，它们往往被直接甩进磁盘。

Service Worker Cache

      Service Worker 是一种独立于主线程之外的 Javascript 线程。它脱离于浏览器窗体，因此无法直接访问 DOM。这样独立的个性使得 Service Worker 的“个人行为”无法干扰页面的性能，这个“幕后工作者”可以帮我们实现离线缓存、消息推送和网络代理等功能。我们借助 Service worker 实现的离线缓存就称为 Service Worker Cache。

HTTP Cache

    它又分为强缓存和协商缓存。优先级较高的是强缓存，在命中强缓存失败的情况下，才会走协商缓存。

对一条http get 报文的基本缓存处理过程包括7个步骤：

• 接收

• 解析

• 查询，缓存查看是否有本地副本可用，如果没有，就获取一份副本

• 新鲜度检测， 缓存查看已缓存副本是否足够新鲜，如果不是，就询问服务器是否有任何更新。

• 创建响应，缓存会用新的首部和已缓存的主体来构建一条响应报文。

• 发送，缓存通过网络将响应发回给客服端。

• 日志

强缓存

     强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的。强缓存中，当请求再次发出时，浏览器会根据其中的 expires 和 cache-control 判断目标资源是否“命中”强缓存，若命中则直接从缓存中获取资源，不会再与服务端发生通信。

是否足够新鲜时期：

通过 Expires: XXXX XXX XXX GMT （绝对日期时间，http/1.0） 或者 Cache-Control:max-age=XXXX （相对日期时间，http/1.1）在文档标明过期日期。

Cache-Control 相对于 expires 更加准确，它的优先级也更高。当 Cache-Control 与 expires 同时出现时，我们以 Cache-Control 为准。

关键字理解

     public 与 private 是针对资源是否能够被代理服务缓存而存在的一组对立概念。如果我们为资源设置了 public，那么它既可以被浏览器缓存，也可以被代理服务器缓存；如果我们设置了 private，则该资源只能被浏览器缓存。private 为默认值。

       no-store与no-cache，no-cache 绕开了浏览器：我们为资源设置了 no-cache 后，每一次发起请求都不会再去询问浏览器的缓存情况，而是直接向服务端去确认该资源是否过期（即走我们下文即将讲解的协商缓存的路线）。no-store 比较绝情，顾名思义就是不使用任何缓存策略。在 no-cache 的基础上，它连服务端的缓存确认也绕开了，只允许你直接向服务端发送请求、并下载完整的响应。

协商缓存

协商缓存依赖于服务端与浏览器之间的通信。协商缓存机制下，浏览器需要向服务器去询问缓存的相关信息，进而判断是重新发起请求、下载完整的响应，还是从本地获取缓存的资源。如果服务端提示缓存资源未改动（Not Modified），资源会被重定向到浏览器缓存，这种情况下网络请求对应的状态码是 304。

push Cache

Push Cache 是指 HTTP2 在 server push 阶段存在的缓存。

Push Cache 是缓存的最后一道防线。浏览器只有在 Memory Cache、HTTP Cache 和 Service Worker Cache 均未命中的情况下才会去询问 Push Cache。

Push Cache 是一种存在于会话阶段的缓存，当 session 终止时，缓存也随之释放。

不同的页面只要共享了同一个 HTTP2 连接，那么它们就可以共享同一个 Push Cache。

CDN初识

CDN 的核心点有两个，一个是缓存，一个是回源。

“缓存”就是说我们把资源 copy 一份到 CDN 服务器上这个过程，“回源”就是说 CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程。

CDN 往往被用来存放静态资源。所谓“静态资源”，就是像 JS、CSS、图片等不需要业务服务器进行计算即得的资源。而“动态资源”，顾名思义是需要后端实时动态生成的资源，较为常见的就是 JSP、ASP 或者依赖服务端渲染得到的 HTML 页面。

那“非纯静态资源”呢？它是指需要服务器在页面之外作额外计算的 HTML 页面。具体来说，当我打开某一网站之前，该网站需要通过权限认证等一系列手段确认我的身份、进而决定是否要把 HTML 页面呈现给我。这种情况下 HTML 确实是静态的，但它和业务服务器的操作耦合，我们把它丢到CDN 上显然是不合适的。

另外，CDN的域名必须和主业务服务器的域名不一样，要不，同一个域名下面的Cookie各处跑，浪费了性能流量的开销，CDN域名放在不同的域名下，可以完美地避免了不必要的 Cookie 的出现！

图片优化

二进制位数与色彩的关系

在计算机中，像素用二进制数来表示。不同的图片格式中像素与二进制位数之间的对应关系是不同的。一个像素对应的二进制位数越多，它可以表示的颜色种类就越多，成像效果也就越细腻，文件体积相应也会越大。

一个二进制位表示两种颜色（0|1 对应黑|白），如果一种图片格式对应的二进制位数有 n 个，那么它就可以呈现 2^n 种颜色。

计算图片大小

对于一张 100 100 像素的图片来说，图像上有 10000 个像素点，如果每个像素的值是 RGBA 存储的话，那么也就是说每个像素有 4 个通道，每个通道 1 个字节（8 位 = 1个字节），所以该图片大小大概为 39KB（10000 1 * 4 / 1024）。

但是在实际项目中，一张图片可能并不需要使用那么多颜色去显示，我们可以通过减少每个像素的调色板来相应缩小图片的大小。
了解了如何计算图片大小的知识，那么对于如何优化图片，想必大家已经有 2 个思路了：

• 减少像素点

减少每个像素点能够显示的颜色

图片类型要点

JPEG/JPG 特点：有损压缩、体积小、加载快、不支持透明,JPG 最大的特点是有损压缩。这种高效的压缩算法使它成为了一种非常轻巧的图片格式。另一方面，即使被称为“有损”压缩，JPG的压缩方式仍然是一种高质量的压缩方式：当我们把图片体积压缩至原有体积的 50% 以下时，JPG 仍然可以保持住 60% 的品质。但当它处理矢量图形和 Logo 等线条感较强、颜色对比强烈的图像时，人为压缩导致的图片模糊会相当明显。

PNG 特点：无损压缩、质量高、体积大、支持透明，PNG（可移植网络图形格式）是一种无损压缩的高保真的图片格式。8 和 24，这里都是二进制数的位数。按照我们前置知识里提到的对应关系，8 位的 PNG 最多支持 256 种颜色，而 24 位的可以呈现约 1600 万种颜色。PNG 图片具有比 JPG 更强的色彩表现力，对线条的处理更加细腻，对透明度有良好的支持。它弥补了上文我们提到的 JPG 的局限性，唯一的 BUG 就是体积太大。

SVG 特点：文本文件、体积小、不失真、兼容性好，SVG（可缩放矢量图形）是一种基于 XML 语法的图像格式。它和本文提及的其它图片种类有着本质的不同：SVG 对图像的处理不是基于像素点，而是是基于对图像的形状描述。

Base64 特点：文本文件、依赖编码、小图标解决方案，Base64 并非一种图片格式，而是一种编码方式。Base64 和雪碧图一样，是作为小图标解决方案而存在的。

WebP 特点：年轻的全能型选手，WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。但是毕竟年轻，兼容性存在一些问题。

渲染优化

客户端渲染

在客户端渲染模式下，服务端会把渲染需要的静态文件发送给客户端，客户端加载过来之后，自己在浏览器里跑一遍 JS，根据 JS 的运行结果，生成相应的 DOM。页面上呈现的内容，你在 html 源文件里里找不到——这正是它的特点。

服务端渲染

在服务端渲染的模式下，当用户第一次请求页面时，由服务器把需要的组件或页面渲染成HTML字符串，然后把它返回给客户端。页面上呈现的内容，我们在 html 源文件里也能找到。服务端渲染解决了一个非常关键的性能问题——首屏加载速度过慢，也解决了SEO搜索引擎的问题。

浏览器渲染过程解析

 

浏览器的渲染机制一般分为以下几个步骤：

• 处理 HTML 并构建 DOM 树。

• 处理 CSS 构建 CSSOM 树

• 将 DOM 与 CSSOM 合并成一个渲染树。

• 根据渲染树来布局，计算每个节点的位置。

• 调用 GPU 绘制，合成图层，显示在屏幕上。

在渲染DOM的时候，浏览器所做的工作实际上是：

• 获取DOM后分割为多个图层

• 对每个图层的节点计算样式结果（Recalculate style–样式重计算）

• 为每个节点生成图形和位置（Layout–回流和重布局）

• 将每个节点绘制填充到图层位图中（Paint Setup和Paint–重绘）

• 图层作为纹理上传至GPU

• 复合多个图层到页面上生成最终屏幕图像（Composite Layers–图层重组）

基于渲染流程的CSS优化建议

CSS 选择符是从右到左进行匹配的，比如 #myList li {}实际开销相当高。

• 避免使用通配符，只对需要用到的元素进行选择。

• 关注可以通过继承实现的属性，避免重复匹配重复定义。

• 少用标签选择器。如果可以，用类选择器替代。错误：#dataList li{} 正确：.dataList{}

• 不要画蛇添足，id 和 class 选择器不应该被多余的标签选择器拖后腿。错误：.dataList#title 正确：#title

• 减少嵌套。后代选择器的开销是最高的，因此我们应该尽量将选择器的深度降到最低（最高不要超过三层），尽可能使用类来关联每一个标签元素。

CSS的阻塞

CSS 是阻塞的资源。浏览器在构建 CSSOM 的过程中，不会渲染任何已处理的内容。即便 DOM 已经解析完毕了，只要 CSSOM 不 OK，那么渲染这个事情就不 OK。我们将 CSS 放在 head 标签里 和尽快 启用 CDN 实现静态资源加载速度的优化。

JS的阻塞

JS 引擎是独立于渲染引擎存在的。我们的 JS 代码在文档的何处插入，就在何处执行。当 HTML 解析器遇到一个 script 标签时，它会暂停渲染过程，将控制权交给 JS 引擎。JS 引擎对内联的 JS 代码会直接执行，对外部 JS 文件还要先获取到脚本、再进行执行。等 JS 引擎运行完毕，浏览器又会把控制权还给渲染引擎，继续 CSSOM 和 DOM 的构建。

DOM渲染优化

先了解回流和重绘

• 回流：当我们对 DOM 的修改引发了 DOM 几何尺寸的变化（比如修改元素的宽、高或隐藏元素等）时，浏览器需要重新计算元素的几何属性（其他元素的几何属性和位置也会因此受到影响），然后再将计算的结果绘制出来。这个过程就是回流（也叫重排）。

• 重绘：当我们对 DOM 的修改导致了样式的变化、却并未影响其几何属性（比如修改了颜色或背景色）时，浏览器不需重新计算元素的几何属性、直接为该元素绘制新的样式（跳过了上图所示的回流环节）。这个过程叫做重绘。

重绘不一定导致回流，回流一定会导致重绘。回流比重绘做的事情更多，带来的开销也更大。在开发中，要从代码层面出发，尽可能把回流和重绘的次数最小化。

Event Loop

我们先了解javascript运行机制，对渲染是大有帮助的。

事件循环中的异步队列有两种：macro（宏任务）队列和 micro（微任务）队列。

常见的 macro-task 比如：setTimeout、setInterval、 setImmediate、script（整体代码）、 I/O 操作、UI 渲染等。
常见的 micro-task 比如: process.nextTick、Promise、MutationObserver 等。

例子分析：

// task是一个用于修改DOM的回调
setTimeout(task, 0)

上面代码，现在 task 被推入的 macro 队列。但因为 script 脚本本身是一个 macro 任务，所以本次执行完 script 脚本之后，下一个步骤就要去处理 micro 队列了，再往下就去执行了一次 render,必须等待下一次的loop。

Promise.resolve().then(task)

上面代码，我们结束了对 script 脚本的执行，是不是紧接着就去处理 micro-task 队列了？micro-task 处理完，DOM 修改好了，紧接着就可以走 render 流程了——不需要再消耗多余的一次渲染，不需要再等待一轮事件循环，直接为用户呈现最即时的更新结果。

上面说了重绘与回流，Event loop，但很多人不知道的是，重绘和回流其实和 Event loop 有关。

• 当 Event loop 执行完 Microtasks 后，会判断 document 是否需要更新。因为浏览器是 60Hz 的刷新率，每 16ms 才会更新一次。

• 然后判断是否有 resize 或者 scroll ，有的话会去触发事件，所以 resize 和 scroll 事件也是至少 16ms 才会触发一次，并且自带节流功能。

• 判断是否触发了 media query

• 更新动画并且发送事件

• 判断是否有全屏操作事件

• 执行 requestAnimationFrame 回调

• 执行 IntersectionObserver 回调，该方法用于判断元素是否可见，可以用于懒加载上，但是兼容性不好

• 更新界面

• 以上就是一帧中可能会做的事情。如果在一帧中有空闲时间，就会去执行 requestIdleCallback 回调。

节流与防抖

防抖和节流的作用都是防止函数多次调用。区别在于，假设一个用户一直触发这个函数，且每次触发函数的间隔小于设置的时间，防抖的情况下只会调用一次，

且节流的情况会每隔一定时间调用一次函数。

防抖（debounce）：n秒内函数只会执行一次，如果n秒内高频事件再次被触发，则重新计算时间。

当用户进行滚动，触发scroll事件，用户的每一次滚动都将触发我们的监听函数。函数执行是吃性能的，频繁地响应某个事件将造成大量不必要的页面计算。因此，我们需要针对那些有可能被频繁触发的事件作进一步地优化。节流与防抖就很有必要了！

小结：优化前端性能：从这些做起：

1.HTTP 优化：

• 减少请求次数

• 减少单次请求所花费的时间

2 浏览器缓存机制有四个方面：

• Memory Cache

• Service Worker Cache

• HTTP Cache

• Push Cache

3 CDN 的方面

• 缓存，资源 copy 一份到 CDN 服务器上

• 回源，CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程。

4 图片优化

• 减少像素点

• 减少每个像素点能够显示的颜色

5 渲染优化

• css优化,避免使用通配符,少用标签选择器,减少嵌套等

• css 阻塞，将 CSS 放在 head 标签里 和尽快 启用 CDN 实现静态资源加载速度的优化。

• js阻塞

6 避免回流和重绘

7 Event Loop

8 节流与防抖

• 节流：使得一定时间内只触发一次函数。 它和防抖动最大的区别就是，节流函数不管事件触发有多频繁，都会保证在规定时间内一定会执行一次真正的事件处理函数，而防抖动只是在最后一次事件后才触发一次函数
• 防抖动：将几次操作合并为一此操作进行。原理是维护一个计时器，规定在delay时间后触发函数，但是在delay时间内再次触发的话，就会取消之前的计时器而重新设置。这样一来，只有最后一次操作能被触发。