关于前端:前端性能优化到底该怎么做下-直捣黄龙

前言

在上一篇 前端性能优化到底该怎么做（上）— 单刀直入 一文中介绍了和前端性能优化相干的一些前置常识，那么本篇就针对优化计划进行总结，外围的方向还是上篇文章中提到的内容：

• 保障资源更快的 加载速度：达到越快渲染越快，视图展示就越快
• 保障视图更快的 渲染速度 / 交互速度：用户与页面交互，前提是页面要渲染进去，其次是页面须要尽早反馈，目标就是保障用户良好的体验性

其实将上述两点再进行翻译，那么其实指的就是 网络层面的优化 和 浏览器层面的优化，这样看来其实前端性能优化方向还是很明确的，只不过明确的方向中还是会波及不同方面的具体优化伎俩。

还是不得不回顾 从输出 URL 到页面加载实现 的外围过程：

• 进行 DNS 解析
• 建设 TCP 连贯
• 客户端发送 HTTP 申请
• 服务端响应 HTTP 资源
• 浏览器获取响应内容，进行解析和渲染

从上述的内容来看，不难发现每一步都是须要耗费肯定的工夫，那么优化的方向就能够围绕着这些内容来思考。

长文预警❗️❗️❗️ 长文预警❗️❗️❗️ 长文预警❗️❗️❗️ 长文预警❗️❗️❗️

如何保障资源更快的加载速度？

上面内容次要针对 DNS 解析 、TCP 连贯、HTTP 申请 / 响应 等阶段来谈的优化，外围优化外围其实就是 网络层面。

应用 dns-prefetch 缩小 DNS 的查问工夫

dns-prefetch 可能 提前解析 后续可能会用到的 不同域的域名 ，使解析后果 缓存到零碎缓存 中，缩短 DNS 解析工夫以进步网站的访问速度。

比方在掘金中的体现如下：

【扩大】DNS 解析的外围过程

当浏览器拜访一个域名时需解析一次 DNS，以取得对应域名的 IP 地址：

• 浏览器 会从本身的 缓存中 查问是否存在对应域名的 IP 地址，若存在返回，若不存在进入下一步
• 客户机查问操作系统中的 /etc/hosts 文件中查问是否有对应域名的 IP 地址，若存在则返回，若不存在进入下一步
• 客户机申请 本地域名服务器（LDNS） 进行解析，本地域名服务器收到客户机的申请后，先查问本人的缓存信息是否有对应域名的 IP 地址，若存在返回后果，没有则进行下一步
• 本地域名服务器申请 根域名服务器 解析该域名，根域名通知本地域名服务器去找对应的 一级域名服务器
• 本地域名服务器申请一级域名服务器解析这个域名，一级域名服务器通知它去找对应的 二级域名服务器
• 本地域名服务器申请二级域名服务器解析这个域名，二级域名服务器通知它去找对应的 子域名服务器
• 本地域名服务器申请子域名服务器解析这个域名，子域名服务器返回对应的 IP 地址
• 本地域名服务器将 IP 地址记录到缓存中，并返回给客户机（会缓存起来），客户机依据收到的 IP 地址拜访该网站

应用 preconnect 提前建设连贯

preconnect 的作用是提前和第三方资源建设连贯，设置了它浏览器就会做好晚期的连贯工作，但这个连贯通常只会维持 10 s。

比方在以后域申请一个资源前，可能会波及 DNS 寻址、TLS 握手、TCP 握手、重定向等，这过程也会破费肯定的工夫。

比方在掘金中的体现如下：

应用 preload / prefetch 事后加载资源

preload

preload 的作用是提前加载页面对应的 要害资源 放慢页面的渲染，preload 的优先级程序和 as 属性相干， 具体可见。

【留神】as 属性肯定要设置，除了下面提到的设置优先级外，还波及到浏览辨认的问题：如果没有设置 as 属性，后续遇到该申请就会被作为一个 XHR 申请，把意味着资源预加载的性能可能会生效，因为可能会每次都发动新的申请获取

比方在掘金中的体现如下：

比方在 vue-cli 的默认 webpack 配置，如下：

prefetch

preload 是对资源的预加载，它虽提前加载但只在须要执行时执行，即这个资源肯定是以后页面所须要的资源，如果是须要为下一个页面提前加载资源，那么应该应用 prefetch，它会在 浏览器闲暇时 下载资源。

比方在 vue-cli 的默认 webpack 配置，如下：

压缩资源体积

资源是须要通过 http 数据包的形式在网络中进行传输的，那么只有能缩小传输数据包的体积，也是可能使得资源更快达到客户端，这也是压缩资源体积的外围目标。

HTTP 压缩

HTTP 压缩中一个典型代表就是 gzip，它是一种优良的压缩算法，可对 http 申请中的一些文件资源进行压缩解决，一般来讲是要在服务端解决的，可通过在响应头中设置 Content-encoding: gzip 示意以后资源应用的压缩形式（如：gzip、deflate、br 等），便于客户端应用正确的形式解压。

【留神 】gzip 并不是万能的，它不能保障针对每个文件的压缩都能使其体积变小，对于 Content-Encoding 的内容 可点此查阅，或者可参考 content-encoding 除了 gzip 之外，你还晓得哪些？

比方在京东中的体现:

比方在掘金中的体现：

Webpack 压缩

有 HTTP 压缩 不就够了吗？为什么还须要 Webpack 压缩？

首先必须要明确的是压缩的过程自身就是会耗费工夫的，如果所有资源都等到被拜访的时候再由服务端进行压缩，在压缩实现之前客户端还是得处于期待状态，即仍 不能保障资源以最快的速度达到客户端。

那么优化计划就是将压缩资源的工夫放到打包构建中，毕竟只有真正须要公布线上生产环境时才须要执行一系列的打包优化的操作，而这相比于 http 的 申请 / 响应 速度，略微缩短产物打包工夫没有什么大问题。

上面会列举一些 Webpack 插件，但并不会去讲其中的具体用法，因为这些只是达到目标的不同计划而已，每个计划要是细讲都能够独占一篇文章，在这是没有必要的，具体用法可自行查阅。

应用 CompressionPlugin 压缩文件

webpack 文档 提供插件合集中就蕴含了该插件，它的作用就是：Prepare compressed versions of assets to serve them with Content-Encoding.

应用 HtmlWebpackPlugin 压缩 HTML 文件

通常咱们须要 HtmlWebpackPlugin 插件来生成对应 HTML 或 对已有的 HTML 模板主动注入 webpack bundles 资源，除此之外，它还可配置 minify 选项实现压缩模板的目标。

能够在 vue 我的项目下执行 vue inspect --mode production > webpack.config.js 来查看脚手架的默认 webpack 配置内容，比方：

应用 SplitChunksPlugin 自定义分包策略

Webpack 默认会将尽可能多的模块代码打包在一起，这种默认规定的带来的长处和毛病都很显著:

• 长处：能缩小最终页面的 HTTP 申请数

• 毛病：

  • 页面初始代码包过大，影响首屏渲染性能
  • 无奈无效利用浏览器缓存

SplitChunksPlugin 是 Webpack 4 之后内置实现的最新分包计划，与 Webpack 3 中的 CommonsChunkPlugin 相比，它可能基于一些更灵便、正当的启发式规定将 Module 编排进不同的 Chunk，最终构建出 性能更佳、缓存更敌对 的利用产物。

比方在 vue-cli 的默认 webpack 配置，如下：

应用 MiniCssExtractPlugin 抽离和压缩 CSS

MiniCssExtractPlugin 会将 CSS 提取到独自的文件中，为每个蕴含 CSS 的 JS 文件创建一个 CSS 文件，并且反对 CSS 和 SourceMaps 的 按需加载。

比方在 vue-cli 的默认 webpack 配置，如下：

应用 ImageMinimizerWebpackPlugin 压缩图片资源

图片仍是一个 Web 利用中的必不可少的资源，而图片资源的体积也是首屏页面加载的瓶颈之一，因而，压缩图片也是性能优化须要思考的内容。

ImageMinimizerWebpackPlugin 可用于应用 优化 / 压缩 所有图像，它能够反对 无损（不损失品质）、有损（品质降落） 两种模式的压缩形式。

通过 Tree Shaking 移除无用代码

Tree Shaking 依赖于 ES6 模块语法的 动态构造  个性（如：import 和 export），当 webpack 的模式 mode 为 "production" 时，就能够启用 更多优化项 ，包含 压缩代码 与 Tree Shaking。

但同时咱们就必须保障：

• 尽量应用 ES6 模块语法，即 import 和 export
• 保障没有 编译器（如：babel）将对应的 ES6 模块语法转换为 CommonJS 的语法（如：@babel/preset-env 的默认行为）
• 可在我的项目的 package.json 文件中增加 "sideEffects" 属性，标识以后内容是否存在副作用操作

• 可在通过 /*#__PURE__*/ 正文，将函数调用标记为无副作用[](https://webpack.docschina.org…)

  缩小 http 申请数量

  不同协定 下 申请数量 依然可能成为 申请 / 响应 慢的起因：

• 合并公共资源，如 雪碧图 等
• 内置模块资源，如 生成 base64 图片、通过 symbol 援用 svg 等
• 合并代码块，如构建工具分包策略配合 公共组件封装、组件复用逻辑抽离 等
• 按需加载资源，如 路由懒加载、图片懒加载、上拉加载、分页加载 等

缩小不必要的 cookie

不必要的 cookie 来回传输会造成带宽节约：

• 缩小 cookie 存储的内容
• 对于动态资源采纳 CDN 托管（即非同域），不同域名默认不携带 cookie

CDN 托管动态资源 + HTTP 缓存

CDN 减速的实质是缓存减速，将服务器上存储的静资源容缓存在 CDN 节点上，当后续拜访这些动态内容时，无需拜访服务器源站，抉择就近拜访 CDN 节点即可，从而达到减速的成果，同时加重服务器源站的压力。

在掘金中体现如下：

协定降级为 Http2.0

http1.x 存在的问题：
HTTP 的底层协定是 TCP，而 TCP 是面向连贯即须要 三次握手 能力建设连贯，其中：

• http1.0 中应用的是 短连贯 ，即 一次申请 / 响应 完结后就会断开连接，这个过程比拟耗时

• http1.1 中应用的是 长连贯 ，在 申请 / 响应头 中设置 Connection: keep-alive 即可开启，长处是 长连贯 容许多个申请共用一个 TCP 连贯，毛病是带来了 队头阻塞：

  • 每个 TCP 连贯中的多个申请，须要进行排队，只有队头的申请被响应，能力持续解决下一个申请
  • 其中一个缓解计划就是如果以后 TCP 连贯中产生 队头阻塞，那就将局部申请放到其余 TCP 连贯中
  • 浏览器个别会限度同一个域名建设 6-8 个 TCP 链接，这也就是为什么须要为利用划分子域名、动态资源托管 CDN 的起因之一
• http1.x 中 header 局部的内容可能会很大，而且每一个申请可能都须要携带大量 反复 header 的 文本内容 ，而这些也是导致 申请 / 响应 慢的起因之一

以上问题 http2.0 都可能解决：

• 针对 TCP 连接数 被限度的问题，http2.0 采纳 多路复用 一个域名只对应一个 TCP 连贯
• 针对 http 队头阻塞 问题，http2.0 中通过二进制分帧层为每个 申请 / 响应 增加 stream id 保障 申请 / 响应 一一对应，即不用期待后面的申请解决实现，并且还能够为每个申请增加 优先级

• 针对 header 数据大的问题，http2.0 中传输的 header 帧通过解决后会用 二进制 的形式示意，替换了本来的 文本格式，并应用 HPACK 算法进行压缩

  • 接管 / 发送 两端会保护一个 索引表，通过下标来标识 header，针对后续反复的 header 信息就能够用对应的索引来代替
• 针对传统的 申请 —> 响应 模式，http2.0 中提供了 服务端推送 的能力，让服务端可能被动向客户端推送要害资源，放慢资源加载

比方在掘金中的体现：

如何保障视图更快的渲染和交互？

保障资源疾速达到客户端后，接下来就须要针对 浏览器的解析和渲染 进行优化，当然还包含后续的页面交互的优化，这其实就是 浏览器层面 的优化。

浏览器渲染 HTML 文件的外围过程：

• HTML 解释器：将 HTML 文档通过词法剖析输入 DOM Tree
• CSS 解释器：解析 CSS 文档，生成款式规定 CSSOM
• 款式计算：将 DOM Tree 和 CSSOM 合并生成 Render Tree
• 布局计算：计算 Render Tree 节点在页面中的坐标地位，创立 Layout Tree
• 划分图层：页面中有很多简单的成果，如一些简单的 3D 变换、页面滚动，或应用 z-index 做 z 轴排序等，为了更加不便地实现这些成果，渲染引擎还须要为特定的节点生成专用的图层，生成对应的图层树 Layer Tree

• 图层绘制：

  • 染引擎实现图层的绘制时，会把一个图层的绘制拆分成很多小的 绘制指令 ，并将这些指令依照程序组成一个 待绘制列表
  • 当图层的绘制列表筹备好后，主线程 会把 待绘制列表 提交（commit）给 合成线程

• 栅格化 raster：

  • 因为视口无限，用户只能看到页面的很小一部分，没必要绘制出所有图层内容，因而 合成线程 会将 图层（layer） 划分为 图块（tile）
  • 渲染过程 把 生成图块的指令 发送给 GPU 并执行生成图块的 位图

• 合成和显示：

  • 一旦所有图块都被光栅化，合成线程 就会生成一个绘制图块的命令 —— DrawQuad，而后将该命令提交给 浏览器过程
  • 浏览器过程 外面有一个 viz 组件，会依据 DrawQuad 命令，将其页面内容绘制到内存中，最初再将内存显示在屏幕上

  渲染层面

  缩小阻塞渲染的因素

  真正渲染视图之前，必然要生成 DOM Tree 和 CSSOM，因而必须保障 HTML 解释器 和 CSS 解释器 都尽早解决实现，同时 JavaScript 的加载和执行可能会阻塞这个过程：

• HTML 文档中首次渲染的节点数量要尽量少，防止深层次的嵌套构造，防止大量应用慢标签（如：iframe）等
• CSS 资源放文档头部，升高 CSS 复杂度，比方 正当应用 CSS 选择器

• JavaScript 资源放文档底部，正当应用 defer、async 的加载形式

  懒加载

  懒加载次要是针对数量大、资源加载慢的状况，比方图片资源、大量列表数据展现等：

• 图片资源 ：优先加载在可视区范畴内的图片，可视区外的图片 延后加载，或者说当移入的可视区时再加载
• 列表数据 ：列表数据通常数据里量大，不可能一次渲染完所有数据，个别通过 分页加载、上拉加载 等形式分批次渲染

白屏优化

白屏是因为 SPA 利用须要期待 JavaScript 加载并执行实现后才会生成具体的页面构造内容导致的，即初始化模板中没有任何有意义须要被渲染的 HTML 构造：

• 增加 白屏 loading，可在模板中增加默认的 loading 成果，等到真正页面内容被渲染就能够替换 loading 内容
• 增加 骨架屏，和上述计划统一，在真正页面内容展现进去之前，先展现默认的视图内容，防止白屏

服务端渲染（server-side rendering）

古代框架默认是属于客户端利用框架，即组件的代码会在浏览器中运行，而后向页面输入 DOM 元素，也叫 客户端渲染（client-side rendering，CSR）：

• 长处

  • 用户体验更好 ，基于  前端路由  的形式并不会真正进行  页面跳转，即不会使页面从新刷新、加载，带来更高的晦涩度
  • 占用服务端资源少，CSR 渲染 是交由客户端进行解决，服务端不须要关怀渲染计算的过程，加重了服务端的压力

• 毛病

  • "白屏" 工夫较长 ，次要是因为 CSR 渲染须要 *.js 的反对，而 *.js 又必须保障 *.html 被接管和解析，*.html 又强依赖于以后的  网络环境 ，因而，在差网环境下回导致  白屏工夫过长，特地是在挪动网络环境下
  • 对 SEO 的反对不敌对 ，因为  白屏工夫较长  导致在一段时间内没有重要的内容可能交由  搜索引擎  进行剖析、分类、打标签等，并且  搜索引擎 并不会期待页面渲染实现，因而对 SEO 优化并不敌对

服务端渲染（server-side rendering，SSR） 可将雷同组件在服务渲染成相应的 HTML 字符串，并发送给浏览器进行渲染，即客户端不须要期待所有的 JavaScript 都被下载并执行之后才显示，所以用户能够更快看到残缺的渲染好的内容。

预渲染（prerender）

上述 服务端渲染（server-side rendering，SSR） 尽管可能解决一些客户端存在的问题，但它也带来了别的问题：

• 须要保障开发一致性 ，比方 服务端 和 客户端 可能执行的组件生命周期钩子不同，一些内部库在 服务端渲染 利用中可能须要通过非凡解决
• 须要更多的构建设定和部署要求，一个齐全动态的 SPA 能够部署在任意的动态文件服务器，但服务端渲染利用须要一个可能运行 Node.js 服务器的环境
• 更多的服务端负载，在 Node.js 中渲染一个残缺的利用，会比仅供给动态文件产生更密集的 CPU 运算，并且须要思考拜访流量过大的状况等

因而，并不是所有利用都适合 服务端渲染 ，如果只是心愿通过 SSR 来改善一些  推广页面  (如 /、/about、/contact 等) 的 SEO，那么应该优先思考  预渲染 的形式：

• 预渲染 是在打包构建过程中（离屏状态），针对对应的 routes 路由事后生成对应的页面内容

• 预渲染  须要和  打包构建工具（webpack、rollup 等） 进行配合，如 webpack，就可通过 prerender-spa-plugin 来反对 预渲染

  交互层面

  缩小回流 / 重绘

  重绘 ：页面中元素款式的扭转并不影响它在文档流中的地位时（如：color、background-color、visibility 等），浏览器会将新款式赋予给元素并 从新绘制

回流 ：当 Render Tree 中局部或全副元素的 尺寸、构造、某些属性 产生扭转时，浏览器 从新渲染 局部或全副文档

• 缩小对 DOM 进行频繁操作
• 使常常变动的元素脱离文档流，如具备持续性的动画成果，会始终触发回流和重绘

• 防止拜访或缩小拜访会导致浏览器 强制刷新队列 的属性，如：offsetTop、offsetLeft、offsetWidth 等

  • 【扩大 】浏览器的渲染队列机制会通过 队列 将会触发 回流或重绘 的操作进行存储，等到肯定的工夫或肯定的数量时再执行这些操作
• 防止对 css 进行单个批改，如在 JavaScript 批改多个款式时，尽量应用 css 选择器实现款式的集中变更
• 应用 will-change 开启 GPU 减速，will-change 指定的属性使得浏览器可在元素属性真正发生变化之前提前做好对应的优化

• 事后设定图片尺寸，防止图片资源加载实现后引发回流

  防抖 / 节流

  防抖 ：屡次频繁触发执行操作，以 最初一次 为准，疏忽两头过程

节流 ：在指定的工夫距离内， 只容许 执行一次对应的操作

正当应用 防抖 / 节流 优化利用中的操作，比方 节流 可用于优化 滚动事件、含糊搜寻等， 防抖 可用于优化一些按钮点击操作等。

Web Worker

JavaScript 是单线程的，如果存在须要大量计算的场景（如视频解码），UI 线程就会被阻塞，甚至浏览器间接卡死。

Web Worker 能够使脚本运行在新的线程中，它们独立于主线程，能够进行大量的计算流动，而不会影响主线程的 UI 渲染，但不能滥用 Web Worker。

虚构列表

最罕用的还是 分页加载 的形式：

• 基于 table 表格的渲染，只会渲染固定数量的 DOM
• 基于 上拉加载 列表的渲染，随着加载数据的增多，对应的 DOM 节点也会增多，达到某个限度页面肯定会产生卡顿

虚构列表 外围就是固定渲染的 DOM 数，通过动静切换数据内容实现视图的更新，并保障文档中实在 DOM 的数量不随着数据量增大而增大（其实和 table 分页很像，但它反对滚动）。

想理解其外围实现的，可查看 虚构滚动是怎么做性能优化的?

大文件分片上传

大部分的我的项目总少不了文件上传性能，但对大文件的上传还是有必要进行优化，所谓的 断点续传 、 秒传 都要基于 分片上传 这个外围性能。

想理解其外围实现的，可查看 请问：怎么实现大文件疾速上传？

Excel 导入 / 导出

针对 Excel 导入 / 导出 的性能置信很多人第一印象是后端的活，但大多数状况下，后端接口的处理速度会受各种影响，导致速度方面不是很现实，有时候也是须要前端来进行优化解决的，比方导入时前端不发送文件只发送解析后的 JSON 数据，导出时不须要独自发送额定接口，间接应用以后展现数据实现导出等。

想理解其外围实现的，可查看 给我实现一个前端的 Excel 导入和导出性能

Vue 我的项目的优化

这部分内容置信大家都不生疏，上面就简略列举一些内容（包含但不限于）：

• 缩小响应式数据的生成，对于纯展现、又须要应用在 template 模板中应用的数据，可应用 Object.freeze() 进行解冻，防止被转为 不必要的响应式数据
• Vue 组件初始化是比拟损耗性能的，应用 函数式组件 缩小组件初始化的过程，实用于实现没有业务逻辑只展现内容的简略组件
• 正当应用 v-show 和 v-if、为 v-for 组件设定惟一 key（非 index）、v-for 和 v-if 不要一起应用等
• 应用 KeepAlive 复用组件，防止组件反复的创立、销毁带来的性能损耗
• 应用 () => import(xxx) 形式实现路由懒加载
• 应用 ESM 的形式封装自定义工具库等
• 针对第三方库做到按需引入
• 正当应用闭包，防止造成内存透露
• 及时革除组件中的副作用，比方 setTimeout、setInterval、addEventListener 等

基于 vue.config.js 或 webpack 进行优化，具体可见 如何优化你的 vue-cli 我的项目？

总结

以上优化计划对应到 上一篇 中提到的性能指标，如下：

• 首字节达到工夫（Time to First Byte，TTFB）
• 首次绘制（First Paint，FP）
• 首次内容绘制（First Contentful Paint，FCP）
• 首屏工夫 / 最大内容绘制（Largest Contentful Paint, LCP）
• 累积布局偏移（Cumulative Layout Shift, CLS)
• 首次输出提早（First Input Delay, FID）

要害资源越早达到客户端，证实 TTFB 工夫越短，而这也能间接的缩小 FP 和 FCP 的工夫；对资源进行了压缩解决意味着可能尽可能晋升 LCP 的工夫；缩小了页面的 回流 / 重绘 就能使得 CLS 的数值越小，视图越趋于稳定；FID 是一个用于跟踪浏览器对用户输出做出反馈之前的延迟时间的指标，包含点击和敲击，保障资源的疾速加载和页面尽早渲染，其对应的数值就越小，视图响应就越快。

最初

前端性能优化 的范畴切实太大，以上列举的优化次要围绕着 资源加载、页面渲染 / 交互 两个大的方向，而具体的优化计划其实有很多（包含但不限于上述内容），很多内容随着关注的方向不同而不同。

如果以上内容对你有所帮忙，来个一键三连，须要更多的光！！！