前端性能优化原理与实践
知识体系： 从一道面试题说起
从输入 URL 到页面加载完成，发生了什么？
在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作。
我们将这个过程切分为如下的过程片段：
- DNS 解析
- TCP 连接
- HTTP 请求抛出
- 服务端处理请求，HTTP 响应返回
- 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户 我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。
具体来说，DNS 解析花时间，可以减少解析次数或者把解析前置，浏览器 DNS 缓存和 DNS prefetch。TCP 每次的三次握手解决方案？——长连接、预连接、接入 SPDY 协议。HTTP 请求方面？——可以在减少请求次数和减小请求体积方面 部署时就把静态资源放在离我们更近的 CDN
以上提到的都是网络层面的性能优化。再往下走就是浏览器端的性能优化——这部分涉及资源加载优化、服务端渲染、浏览器缓存机制的利用、DOM 树的构建、网页排版和渲染过程、回流与重绘的考量、DOM 操作的合理规避等等
webpack 性能调优与 Gzip 原理
网络层面的性能优化
涉及到网络层面的，有三个主要过程：
- DNS 解析
- TCP 连接
- HTTP 请求/响应
对于 DNS 解析和 TCP 连接两个步骤前端可以做的努力非常有限。相比之下，HTTP 连接这一层面的优化才是我们网络优化的核心。因此我们开门见山，抓主要矛盾，直接从 HTTP 开始讲起。
HTTP 优化有两个大的方向：
- 减少请求次数
- 减少单次请求所花费的时间
这两个优化点直直地指向了我们日常开发中非常常见的操作——资源的压缩与合并
webpack 优化方案
构建过程提速策略 不要让 loader 做太多事情——以 babel-loader 为例 babel-loader 无疑是强大的，但它也是慢的。
最常见的优化方式是，用 include 或 exclude 来帮我们避免不必要的转译，比如 webpack 官方在介绍 babel-loader 时给出的示例：
module: {
rules: [
{
test: /\.js$/,
exclude: /(node_modules|bower_components)/,
use: {
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env']
}
}
}
]
}
规避了对庞大的 node_modules 文件夹或者 bower_components 文件夹的处理
开启缓存将转译结果缓存至文件系统，则至少可以将 babel-loader 的工作效率提升两倍。要做到这点，我们只需要为 loader 增加相应的参数设定：
loader: 'babel-loader?cacheDirectory=true'
不要放过第三方库
推荐 DllPlugin
DllPlugin 是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。 用 DllPlugin 处理文件，要分两步走：
- 基于 dll 专属的配置文件，打包 dll 库
- 基于 webpack.config.js 文件，打包业务代码
Happypack——将 loader 由单进程转为多进程
删除冗余代码
一个比较典型的应用，就是 Tree-Shaking。 意思是基于 import/export 语法，Tree-Shaking 可以在编译的过程中获悉哪些模块并没有真正被使用，这些没用的代码，在最后打包的时候会被去除。
按需加载
Gzip 压缩原理
说到压缩，可不只是构建工具的专利。我们日常开发中，其实还有一个便宜又好用的压缩操作：开启 Gzip。
具体的做法非常简单，只需要你在你的 request headers 中加上这么一句：
accept-encoding:gzip
Gzip 的内核就是 Deflate，目前我们压缩文件用得最多的就是 Gzip。可以说，Gzip 就是 HTTP 压缩的经典例题。
该不该用 Gzip
项目不是极端迷你的超小型文件，建议Gzip。
Gzip 是万能的吗
Gzip 是高效的，压缩后通常能帮我们减少响应 70% 左右的大小。
但它并非万能。Gzip 并不保证针对每一个文件的压缩都会使其变小。
Gzip 压缩背后的原理，是在一个文本文件中找出一些重复出现的字符串、临时替换它们，从而使整个文件变小。根据这个原理，文件中代码的重复率越高，那么压缩的效率就越高，使用 Gzip 的收益也就越大。反之亦然。
webpack 的 Gzip 和服务端的 Gzip
Gzip 压缩是服务器的活儿：服务器了解到我们这边有一个 Gzip 压缩的需求，它会启动自己的 CPU 去为我们完成这个任务。而压缩文件这个过程本身是需要耗费时间的，大家可以理解为我们以服务器压缩的时间开销和 CPU 开销（以及浏览器解析压缩文件的开销）为代价，省下了一些传输过程中的时间开销。
既然存在着这样的交换，那么就要求我们学会权衡。服务器的 CPU 性能不是无限的，如果存在大量的压缩需求，服务器也扛不住的。服务器一旦因此慢下来了，用户还是要等。Webpack 中 Gzip 压缩操作的存在，事实上就是为了在构建过程中去做一部分服务器的工作，为服务器分压。
因此，这两个地方的 Gzip 压缩，谁也不能替代谁
图片优化
不同业务场景下的图片方案选型
前置知识：二进制位数与色彩的关系
在计算机中，像素用二进制数来表示。不同的图片格式中像素与二进制位数之间的对应关系是不同的。一个像素对应的二进制位数越多，它可以表示的颜色种类就越多，成像效果也就越细腻，文件体积相应也会越大。
一个二进制位表示两种颜色（0|1 对应黑|白），如果一种图片格式对应的二进制位数有 n 个，那么它就可以呈现 2^n 种颜色。
JPEG/JPG
JPG 适用于呈现色彩丰富的图片，在我们日常开发中，JPG 图片经常作为大的背景图、轮播图或 Banner 图出现。
JPG 的缺陷
有损压缩在上文所展示的轮播图上确实很难露出马脚，但当它处理矢量图形和 Logo 等线条感较强、颜色对比强烈的图像时，人为压缩导致的图片模糊会相当明显。
此外，JPEG 图像不支持透明度处理，透明图片需要召唤 PNG 来呈现。
PNG-8 与 PNG-24
无损压缩、质量高、体积大、支持透明 复杂的、色彩层次丰富的图片，用 PNG 来处理的话，成本会比较高，我们一般会交给 JPG 去存储。考虑到 PNG 在处理线条和颜色对比度方面的优势，我们主要用它来呈现小的 Logo、颜色简单且对比强烈的图片或背景等。
SVG
文本文件、体积小、不失真、兼容性好
Base64
文本文件、依赖编码、小图标解决方案
Base64 并非一种图片格式，而是一种编码方式。是作为小图标解决方案而存在的
Base64 是一种用于传输 8Bit 字节码的编码方式，通过对图片进行 Base64 编码，
我们可以直接将编码结果写入 HTML 或者写入 CSS，从而减少 HTTP 请求的次数。
既然 Base64 这么棒，我们何不把大图也换成 Base64 呢？
Base64 编码后，图片大小会膨胀为原文件的 4/3（这是由 Base64 的编码原理决定的）。如果我们把大图也编码到 HTML 或 CSS 文件中，后者的体积会明显增加，即便我们减少了 HTTP 请求，也无法弥补这庞大的体积带来的性能开销，得不偿失。 在传输非常小的图片的时候，Base64 带来的文件体积膨胀、以及浏览器解析 Base64 的时间开销，与它节省掉的 HTTP 请求开销相比，可以忽略不计，这时候才能真正体现出它在性能方面的优势。
因此，Base64 并非万全之策，我们往往在一张图片满足以下条件时会对它应用 Base64 编码：
- 图片的实际尺寸很小（大家可以观察一下掘金页面的 Base64 图，几乎没有超过 2kb 的）
- 图片无法以雪碧图的形式与其它小图结合（合成雪碧图仍是主要的减少 HTTP 请求的途径，Base64 是雪碧图的补充）
- 图片的更新频率非常低（不需我们重复编码和修改文件内容，维护成本较低）
Base64 编码工具推荐
这里最推荐的是利用 webpack 来进行 Base64 的编码——webpack 的 url-loader 非常聪明，它除了具备基本的 Base64 转码能力，还可以结合文件大小，帮我们判断图片是否有必要进行 Base64 编码。
WebP
WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。但兼容性不好
先进行了兼容性的预判，在浏览器环境支持 WebP 的情况下，优先使用 WebP 格式，否则就把图片降级为 JPG 格式（本质是对图片的链接地址作简单的字符串切割）。
还有另一个维护性更强、更加灵活的方案——把判断工作交给后端，由服务器根据 HTTP 请求头部的 Accept 字段来决定返回什么格式的图片。当 Accept 字段包含 image/webp 时，就返回 WebP 格式的图片，否则返回原图。这种做法的好处是，当浏览器对 WebP 格式图片的兼容支持发生改变时，我们也不用再去更新自己的兼容判定代码，只需要服务端像往常一样对 Accept 字段进行检查即可。
浏览器缓存机制介绍与缓存策略剖析
强缓存和协商缓存
实现强缓存，过去一直用 expires。当服务器返回响应时，在 Response Headers 中将过期时间写入 expires 字段。如 expires: Wed, 11 Sep 2019 16:12:18 GMT， 如果我们试图再次向服务器请求资源，浏览器就会先对比本地时间和 expires 的时间戳，如果本地时间小于 expires 设定的过期时间，那么就直接去缓存中取这个资源。它最大的问题在于对“本地时间”的依赖。如果服务端和客户端的时间设置可能不同，或者我直接手动去把客户端的时间改掉，那么 expires 将无法达到我们的预期。，HTTP1.1 新增了 Cache-Control 字段来完成 expires 的任务。
public 与 private
public 与 private 是针对资源是否能够被代理服务缓存而存在的一组对立概念。
no-store与no-cache
no-cache 绕开了浏览器：我们为资源设置了 no-cache 后，每一次发起请求都不会再去询问浏览器的缓存情况，而是直接向服务端去确认该资源是否过期（协商缓存的路线）。
no-store 比较绝情，顾名思义就是不使用任何缓存策略。
协商缓存：浏览器与服务器合作之下的缓存策略
从 Last-Modified 到 Etag
Last-Modified（If-Modified-Since） 存在一些弊端，这其中最常见的就是这样两个场景：
-
我们编辑了文件，但文件的内容没有改变。服务端并不清楚我们是否真正改变了文件，它仍然通过最后编辑时间进行判断。因此这个资源在再次被请求时，会被当做新资源，进而引发一次完整的响应——不该重新请求的时候，也会重新请求。
-
当我们修改文件的速度过快时（比如花了 100ms 完成了改动），由于 If-Modified-Since 只能检查到以秒为最小计量单位的时间差，所以它是感知不到这个改动的——该重新请求的时候，反而没有重新请求了。
Etag（If-None-Match） 是由服务器为每个资源生成的唯一的标识字符串，这个标识字符串是基于文件内容编码的，只要文件内容不同，它们对应的 Etag 就是不同的，反之亦然。因此 Etag 能够精准地感知文件的变化。
