面试过程中面试官问到前端性能优化有哪些，当我咔咔一顿输出之后面试官追问：前端可以做的性能优化有哪些呢？

前端优化大概可以有以下几个方向：

网络优化
页面渲染优化
JS优化
图片优化
webpack打包优化
React优化
Vue优化

网络优化

DNS预解析

link标签的rel属性设置dns-prefetch，提前获取域名对应的IP地址

使用缓存

减轻服务端压力，快速得到数据(强缓存和协商缓存可以看这里)

使用 CDN（内容分发网络）

用户与服务器的物理距离对响应时间也有影响。

内容分发网络（CDN）是一组分散在不同地理位置的 web 服务器，用来给用户更高效地发送内容。典型地，选择用来发送内容的服务器是基于网络距离的衡量标准的。例如：选跳数（hop）最少的或者响应时间最快的服务器。

压缩响应

压缩组件通过减少 HTTP 请求产生的响应包的大小，从而降低传输时间的方式来提高性能。从 HTTP1.1 开始，Web 客户端可以通过 HTTP 请求中的 Accept-Encoding 头来标识对压缩的支持（这个请求头会列出一系列的压缩方法）

如果 Web 服务器看到请求中的这个头，就会使用客户端列出的方法中的一种来压缩响应。Web 服务器通过响应中的 Content-Encoding 头来告知 Web 客户端使用哪种方法进行的压缩

目前许多网站通常会压缩 HTML 文档，脚本和样式表的压缩也是值得的（包括 XML 和 JSON 在内的任何文本响应理论上都值得被压缩）。但是，图片和 PDF 文件不应该被压缩，因为它们本来已经被压缩了。

使用多个域名

Chrome 等现代化浏览器，都会有同域名限制并发下载数的情况，不同的浏览器及版本都不一样，使用不同的域名可以最大化下载线程，但注意保持在 2~4 个域名内，以避免 DNS 查询损耗。

避免图片src为空

虽然 src 属性为空字符串，但浏览器仍然会向服务器发起一个 HTTP 请求：

IE 向页面所在的目录发送请求； Safari、Chrome、Firefox 向页面本身发送请求； Opera 不执行任何操作。

页面渲染优化

Webkit 渲染引擎流程：

处理 HTML 并构建 DOM 树
处理 CSS 构建 CSS 规则树(CSSOM)
DOM Tree 和 CSSOM Tree 合成一棵渲染树 Render Tree。
根据渲染树来布局，计算每个节点的位置
调用 GPU 绘制，合成图层，显示在屏幕上

避免css阻塞

css影响renderTree的构建，会阻塞页面的渲染，因此应该尽早（将 CSS 放在 head 标签里）和尽快（启用 CDN 实现静态资源加载速度的优化)的将css资源加载

降低css选择器的复杂度

浏览器读取选择器，遵循的原则是从选择器的右边到左边读取。

减少嵌套：最多不要超过三层，并且后代选择器的开销较高，慎重使用
避免使用通配符，对用到的元素进行匹配即可
利用继承，避免重复匹配和定义
正确使用类选择器和id选择器

避免使用CSS 表达式

css 表达式会被频繁地计算。

避免js阻塞

js可以修改CSSOM和DOM，因此js会阻塞页面的解析和渲染，并且会等待css资源的加载。也就是说js会抢走渲染引擎的控制权。所以我们需要给js资源添加defer或者async，延迟js脚本的执行。

使用外链式的js和css

在现实环境中使用外部文件通常会产生较快的页面，因为 JavaScript 和 CSS 有机会被浏览器缓存起来。对于内联的情况，由于 HTML 文档通常不会被配置为可以进行缓存的，所以每次请求 HTML 文档都要下载 JavaScript 和 CSS。所以，如果 JavaScript 和 CSS 在外部文件中，浏览器可以缓存它们，HTML 文档的大小会被减少而不必增加 HTTP 请求数量。

使用字体图标 iconfont 代替图片图标

图片会增加网络请求次数，从而拖慢页面加载时间
iconfont可以很好的缩放并且不会添加额外的请求

首屏加载优化

使用骨架屏或者动画优化用户体验
资源按需加载，首页不需要的资源延迟加载

减少重绘和回流

增加多个节点使用documentFragment：不是真实dom的部分，不会引起重绘和回流
用 translate 代替 top ，因为 top 会触发回流，但是translate不会。所以translate会比top节省了一个layout的时间
使用 visibility 替换 display: none ，因为前者只会引起重绘，后者会引发回流（改变了布局）；opacity 代替 visiability，visiability会触发重绘（paint），但opacity不会。
把 DOM 离线后修改，比如：先把 DOM 给 display:none (有一次 Reflow)，然后你修改 100 次，然后再把它显示出来
不要把 DOM 结点的属性值放在一个循环里当成循环里的变量
for (let i = 0; i < 1000; i++) { // 获取 offsetTop 会导致回流，因为需要去获取正确的值 console.log(document.querySelector('.test').style.offsetTop) } 复制代码
尽量少用table布局，table布局的话，每次有单元格布局改变，都会进行整个tabel回流重绘；
最好别频繁去操作DOM节点，最好把需要操作的样式，提前写成class，之后需要修改。只需要修改一次，需要修改的时候，直接修改className，做成一次性更新多条css DOM属性，一次回流重绘总比多次回流重绘要付出的成本低得多；
动画实现的速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame
每次访问DOM的偏移量属性的时候，例如获取一个元素的scrollTop、scrollLeft、scrollWidth、offsetTop、offsetLeft、offsetWidth、offsetHeight之类的属性，浏览器为了保证值的正确也会回流取得最新的值，所以如果你要多次操作，最取完做个缓存。更加不要for循环中访问DOM偏移量属性，而且使用的时候，最好定义一个变量，把要需要的值赋值进去，进行值缓存，把回流重绘的次数减少；
将频繁运行的动画变为图层，图层能够阻止该节点回流影响别的元素。比如对于 video 标签，浏览器会自动将该节点变为图层。

JS中的性能优化

使用事件委托

防抖和节流

尽量不要使用JS动画

css3动画和canvas动画都比JS动画性能好

多线程

复杂的计算开启webWorker进行计算，避免页面假死

计算结果缓存

减少运算次数，比如vue中的computed

图片的优化

雪碧图

借助减少http请求次数来进行优化

图片懒加载

在图片即将进入可视区域的时候进行加载（判断图片进入可视区域请参考这里）

使用CSS3代替图片

有很多图片使用 CSS 效果（渐变、阴影等）就能画出来，这种情况选择 CSS3 效果更好

图片压缩

压缩方法有两种，一是通过在线网站进行压缩，二是通过 webpack 插件 image-webpack-loader。它是基于 imagemin 这个 Node 库来实现图片压缩的。

使用渐进式jpeg

使用渐进式jpeg，会提高用户体验参考文章

使用 webp 格式的图片

webp 是一种新的图片文件格式，它提供了有损压缩和无损压缩两种方式。在相同图片质量下，webp 的体积比 png 和 jpg 更小。

webpack打包优化

缩小loader 匹配范围

优化loader配置
test、include、exclude三个配置项来缩?loader的处理范围
推荐include

include: path.resolve(__dirname, "./src"),
复制代码

resolve.modules

resolve.modules用于配置webpack去哪些目录下寻找第三方模块，默认是 node_modules。

寻找第三方，默认是在当前项目目录下的node_modules里面去找，如果没有找到，就会去上一级目录../node_modules找，再没有会去../../node_modules中找，以此类推，和Node.js的模块寻找机制很类似。

如果我们的第三?模块都安装在了项?根?录下，就可以直接指明这个路径。

module.exports={
 resolve:{
 modules: [path.resolve(__dirname, "./node_modules")]
 }
}

复制代码

resolve.extensions

resolve.extensions在导?语句没带?件后缀时，webpack会?动带上后缀后，去尝试查找?件是否存在。

后缀尝试列表尽量的?
导?语句尽量的带上后缀。

如果想优化到极致的话，不建议用extensionx, 因为它会消耗一些性能。虽然它可以带来一些便利。

抽离css

借助mini-css-extract-plugin:本插件会将 CSS 提取到单独的文件中，为每个包含 CSS 的 JS 文件创建一个 CSS 文件，并且支持 CSS 和 SourceMaps 的按需加载。。

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
 {
 test: /\.less$/,
 use: [
 // "style-loader", // 不再需要style-loader，?MiniCssExtractPlugin.loader代替
  MiniCssExtractPlugin.loader,
  "css-loader", // 编译css
  "postcss-loader",
  "less-loader" // 编译less
 ]
 },
plugins: [
  new MiniCssExtractPlugin({
   filename: "css/[name]_[contenthash:6].css",
   chunkFilename: "[id].css"
  })
 ]
复制代码

代码压缩

JS代码压缩

mode:production，使用的是terser-webpack-plugin

module.exports = {
    // ...
    optimization: {
        minimize: true,
        minimizer: [
            new TerserPlugin({}),
        ]
    }
}
复制代码

CSS代码压缩

css-minimizer-webpack-plugin

module.exports = {
    // ...
    optimization: {
        minimize: true,
        minimizer: [
            new CssMinimizerPlugin({})
        ]
    }
}
复制代码

Html文件代码压缩

module.exports = {
    ...
    plugin:[
        new HtmlwebpackPlugin({
            ...
            minify:{
                minifyCSS:false, // 是否压缩css
                collapseWhitespace:false, // 是否折叠空格
                removeComments:true // 是否移除注释
            }
        })
    ]
}
复制代码

设置了minify，实际会使用另一个插件html-minifier-terser

文件大小压缩

对文件的大小进行压缩，减少http传输过程中宽带的损耗

npm install compression-webpack-plugin -D
复制代码

new ComepressionPlugin({
    test:/.(css|js)$/,  // 哪些文件需要压缩
    threshold:500, // 设置文件多大开始压缩
    minRatio:0.7, // 至少压缩的比例
    algorithm:"gzip", // 采用的压缩算法
})
复制代码

图片压缩

一般来说在打包之后，一些图片文件的大小是远远要比 js 或者 css 文件要来的大，所以图片压缩较为重要

配置方法如下：

module: {
  rules: [
    {
      test: /.(png|jpg|gif)$/,
      use: [
        {
          loader: 'file-loader',
          options: {
            name: '[name]_[hash].[ext]',
            outputPath: 'images/',
          }
        },
        {
          loader: 'image-webpack-loader',
          options: {
            // 压缩 jpeg 的配置
            mozjpeg: {
              progressive: true,
              quality: 65
            },
            // 使用 imagemin**-optipng 压缩 png，enable: false 为关闭
            optipng: {
              enabled: false,
            },
            // 使用 imagemin-pngquant 压缩 png
            pngquant: {
              quality: '65-90',
              speed: 4
            },
            // 压缩 gif 的配置
            gifsicle: {
              interlaced: false,
            },
            // 开启 webp，会把 jpg 和 png 图片压缩为 webp 格式
            webp: {
              quality: 75
            }
          }
        }
      ]
    },
  ]
} 
复制代码

Tree shaking 去除死代码

Tree Shaking 是一个术语，在计算机中表示消除死代码，依赖于ES Module的静态语法分析（不执行任何的代码，可以明确知道模块的依赖关系）

在webpack实现Tree shaking有两种不同的方案：

usedExports：通过标记某些函数是否被使用，之后通过Terser来进行优化的
sideEffects：跳过整个模块/文件，直接查看该文件是否有副作用

两种不同的配置方案，有不同的效果

usedExports

配置方法也很简单，只需要将usedExports设为true

module.exports = {
    ...
    optimization:{
        usedExports
    }
}
复制代码

使用之后，没被用上的代码在webpack打包中会加入unused harmony export mul注释，用来告知 Terser 在优化时，可以删除掉这段代码

sideEffects

sideEffects用于告知webpack compiler哪些模块时有副作用，配置方法是在package.json中设置sideEffects属性

如果sideEffects设置为false，就是告知webpack可以安全的删除未用到的exports

如果有些文件需要保留，可以设置为数组的形式

"sideEffecis":[
    "./src/util/format.js",
    "*.css" // 所有的css文件
]
复制代码

上述都是关于javascript的tree shaking，css同样也能够实现tree shaking

css tree shaking

css进行tree shaking优化可以安装PurgeCss插件

npm install purgecss-plugin-webpack -D
复制代码

const PurgeCssPlugin = require('purgecss-webpack-plugin')
module.exports = {
    ...
    plugins:[
        new PurgeCssPlugin({
            path:glob.sync(`${path.resolve('./src')}/**/*`), {nodir:true}// src里面的所有文件
            satelist:function(){
                return {
                    standard:["html"]
                }
            }
        })
    ]
}
复制代码

paths：表示要检测哪些目录下的内容需要被分析，配合使用glob
默认情况下，Purgecss会将我们的html标签的样式移除掉，如果我们希望保留，可以添加一个safelist的属性

babel-plugin-transform-runtime减少ES6转化ES5的冗余

Babel 插件会在将 ES6 代码转换成 ES5 代码时会注入一些辅助函数。在默认情况下， Babel 会在每个输出文件中内嵌这些依赖的辅助函数代码，如果多个源代码文件都依赖这些辅助函数，那么这些辅助函数的代码将会出现很多次，造成代码冗余。为了不让这些辅助函数的代码重复出现，可以在依赖它们时通过 require('
babel-runtime/helpers/createClass') 的方式导入，这样就能做到只让它们出现一次。
babel-plugin-transform-runtime 插件就是用来实现这个作用的，将相关辅助函数进行替换成导入语句，从而减小 babel 编译出来的代码的文件大小。

代码分离

将代码分离到不同的bundle中，之后我们可以按需加载，或者并行加载这些文件

默认情况下，所有的JavaScript代码（业务代码、第三方依赖、暂时没有用到的模块）在首页全部都加载，就会影响首页的加载速度

代码分离可以分出更小的bundle，以及控制资源加载优先级，提供代码的加载性能

这里通过splitChunksPlugin来实现，该插件webpack已经默认安装和集成，只需要配置即可

默认配置中，chunks仅仅针对于异步（async）请求，我们可以设置为initial或者all

module.exports = {
    ...
    optimization:{
        splitChunks:{
            chunks:"all"
        }
    }
}
复制代码

splitChunks主要属性有如下：

Chunks，对同步代码还是异步代码进行处理
minSize：拆分包的大小, 至少为minSize，如何包的大小不超过minSize，这个包不会拆分
maxSize：将大于maxSize的包，拆分为不小于minSize的包
minChunks：被引入的次数，默认是1

多线程打包提升打包速度

vue

v-for添加key
路由懒加载
第三方插件按需引入
合理使用computed和watch
v-for的同时避免使用v-if
destory时销毁事件：比如addEventListener添加的事件、setTimeout、setInterval、bus.$on绑定的监听事件等

react

map循环展示添加key
路由懒加载
第三方插件按需引入
使用scu，memo或者pureComponent避免不必要的渲染
合理使用useMemo、memo、useCallback
他们三个的应用场景都是缓存结果，当依赖值没有改变时避免不必要的计算或者渲染。
useCallback 是针对函数进行“记忆”的，当它依赖项没有发生改变时，那么该函数的引用并不会随着组件的刷新而被重新赋值。当我们觉得一个函数不需要随着组件的更新而更新引用地址的时候，我们就可以使用 useCallback 去修饰它。
React.memo 是对组件进行 “记忆”，当它接收的 props 没有发生改变的时候，那么它将返回上次渲染的结果，不会重新执行函数返回新的渲染结果。
React.useMemo是针对 值计算 的一种“记忆“，当依赖项没有发生改变时，那么无需再去计算，直接使用之前的值，对于组件而言，这带来的一个好处就是，可以减少一些计算，避免一些多余的渲染。当我们遇到一些数据需要在组件内部进行计算的时候，可以考虑一下 React.useMemo

笔者近半年一直在参与项目重构，在重构过程中大量应用性能优化和设计模式两方面的知识。性能优化和设计模式两方面的知识不管在工作还是面试时都是高频应用场景，趁着这次参与大规模项目重构的机会，笔者认真梳理出一些常规且必用的性能优化建议，同时结合日常开发经验整理出笔者在网易四年来实践到的认为有用的所有性能优化建议，与大家一起分享分享！(由于篇幅有限，那设计模式在后面再专门出一篇文章呗)

可能有些性能优化建议已被大家熟知，不过也不影响这次分享，当然笔者也将一些平时可能不会注意的细节罗列出来。

平时大家认为性能优化是一种无序的应用场景，但在笔者看来它是一种有序的应用场景且很多性能优化都是互相铺垫甚至一带一路。从过程趋势来看，性能优化可分为网络层面和渲染层面；从结果趋势来看，性能优化可分为时间层面和体积层面。简单来说就是要在访问网站时使其快准狠地立马呈现在用户眼前。

所有的性能优化都围绕着两大层面两小层面实现，核心层面是网络层面和渲染层面，辅助层面是时间层面和体积层面，而辅助层面则充满在核心层面里。于是笔者通过本文整理出关于前端性能优化的九大策略和六大指标。当然这些策略和指标都是笔者自己定义，方便通过某种方式为性能优化做一些规范。

因此在工作或面试时结合这些特征就能完美地诠释性能优化所延伸出来的知识了。前方高能，不看也得收藏，走起！！！

所有代码示例为了凸显主题，只展示核心配置代码，其他配置并未补上，请自行脑补
复制代码

九大策略

网络层面

网络层面的性能优化，无疑是如何让资源体积更小加载更快，因此笔者从以下四方面做出建议。

构建策略：基于构建工具(Webpack/Rollup/Parcel/Esbuild/Vite/Gulp)
图像策略：基于图像类型(JPG/PNG/SVG/WebP/Base64)
分发策略：基于内容分发网络(CDN)
缓存策略：基于浏览器缓存(强缓存/协商缓存)

上述四方面都是一步接着一步完成，充满在整个项目流程里。构建策略和图像策略处于开发阶段，分发策略和缓存策略处于生产阶段，因此在每个阶段都可检查是否按顺序接入上述策略。通过这种方式就能最大限度增加性能优化应用场景。

构建策略

该策略主要围绕webpack做相关处理，同时也是接入最普遍的性能优化策略。其他构建工具的处理也是大同小异，可能只是配置上不一致。说到webpack的性能优化，无疑是从时间层面和体积层面入手。

笔者发现目前webpack v5整体兼容性还不是特别好，某些功能配合第三方工具可能出现问题，故暂未升级到v5，继续使用v4作为生产工具，故以下配置均基于v4，但总体与v5的配置出入不大
复制代码

笔者对两层面分别做出6个性能优化建议总共12个性能优化建议，为了方便记忆均使用四字词语概括，方便大家消化。?表示减少打包时间，表示减少打包体积。

减少打包时间：缩减范围、缓存副本、定向搜索、提前构建、并行构建、可视结构
减少打包体积：分割代码、摇树优化、动态垫片、按需加载、作用提升、压缩资源

?缩减范围

配置include/exclude缩小Loader对文件的搜索范围，好处是避免不必要的转译。node_modules目录的体积这么大，那得增加多少时间成本去检索所有文件啊？

include/exclude通常在各大Loader里配置，src目录通常作为源码目录，可做如下处理。当然include/exclude可根据实际情况修改。

export default {
    // ...
    module: {
        rules: [{
            exclude: /node_modules/,
            include: /src/,
            test: /\.js$/,
            use: "babel-loader"
        }]
    }
};
复制代码

?缓存副本

配置cache缓存Loader对文件的编译副本，好处是再次编译时只编译修改过的文件。未修改过的文件干嘛要随着修改过的文件重新编译呢？

大部分Loader/Plugin都会提供一个可使用编译缓存的选项，通常包含cache字眼。以babel-loader和eslint-webpack-plugin为例。

import EslintPlugin from "eslint-webpack-plugin";

export default {
    // ...
    module: {
        rules: [{
            // ...
            test: /\.js$/,
            use: [{
                loader: "babel-loader",
                options: { cacheDirectory: true }
            }]
        }]
    },
    plugins: [
        new EslintPlugin({ cache: true })
    ]
};
复制代码

?定向搜索

配置resolve提高文件的搜索速度，好处是定向指定必须文件路径。若某些第三方库以常规形式引入可能报错或希望程序自动索引特定类型文件都可通过该方式解决。

alias映射模块路径，extensions表明文件后缀，noParse过滤无依赖文件。通常配置alias和extensions就足够。

export default {
    // ...
    resolve: {
        alias: {
            "#": AbsPath(""), // 根目录快捷方式
            "@": AbsPath("src"), // src目录快捷方式
            swiper: "swiper/js/swiper.min.js"
        }, // 模块导入快捷方式
        extensions: [".js", ".ts", ".jsx", ".tsx", ".json", ".vue"] // import路径时文件可省略后缀名
    }
};
复制代码

?提前构建

配置DllPlugin将第三方依赖提前打包，好处是将DLL与业务代码完全分离且每次只构建业务代码。这是一个古老配置，在webpack v2时已存在，不过现在webpack v4+已不推荐使用该配置，因为其版本迭代带来的性能提升足以忽略DllPlugin所带来的效益。

DLL意为动态链接库，指一个包含可由多个程序同时使用的代码库。在前端领域里可认为是另类缓存的存在，它把公共代码打包为DLL文件并存到硬盘里，再次打包时动态链接DLL文件就无需再次打包那些公共代码，从而提升构建速度，减少打包时间。

配置DLL总体来说相比其他配置复杂，配置流程可大致分为三步。

首先告知构建脚本哪些依赖做成DLL并生成DLL文件和DLL映射表文件。

import { DefinePlugin, DllPlugin } from "webpack";

export default {
    // ...
    entry: {
        vendor: ["react", "react-dom", "react-router-dom"]
    },
    mode: "production",
    optimization: {
        splitChunks: {
            cacheGroups: {
                vendor: {
                    chunks: "all",
                    name: "vendor",
                    test: /node_modules/
                }
            }
        }
    },
    output: {
        filename: "[name].dll.js", // 输出路径和文件名称
        library: "[name]", // 全局变量名称：其他模块会从此变量上获取里面模块
        path: AbsPath("dist/static") // 输出目录路径
    },
    plugins: [
        new DefinePlugin({
            "process.env.NODE_ENV": JSON.stringify("development") // DLL模式下覆盖生产环境成开发环境(启动第三方依赖调试模式)
        }),
        new DllPlugin({
            name: "[name]", // 全局变量名称：减小搜索范围，与output.library结合使用
            path: AbsPath("dist/static/[name]-manifest.json") // 输出目录路径
        })
    ]
};
复制代码

然后在package.json里配置执行脚本且每次构建前首先执行该脚本打包出DLL文件。

{
    "scripts": {
        "dll": "webpack --config webpack.dll.js"
    }
}
复制代码

最后链接DLL文件并告知webpack可命中的DLL文件让其自行读取。使用html-webpack-tags-plugin在打包时自动插入DLL文件。

import { DllReferencePlugin } from "webpack";
import HtmlTagsPlugin from "html-webpack-tags-plugin";

export default {
    // ...
    plugins: [
        // ...
        new DllReferencePlugin({
            manifest: AbsPath("dist/static/vendor-manifest.json") // manifest文件路径
        }),
        new HtmlTagsPlugin({
            append: false, // 在生成资源后插入
            publicPath: "/", // 使用公共路径
            tags: ["static/vendor.dll.js"] // 资源路径
        })
    ]
};
复制代码

为了那几秒钟的时间成本，笔者建议配置上较好。当然也可使用autodll-webpack-plugin代替手动配置。

?并行构建

配置Thread将Loader单进程转换为多进程，好处是释放CPU多核并发的优势。在使用webpack构建项目时会有大量文件需解析和处理，构建过程是计算密集型的操作，随着文件增多会使构建过程变得越慢。

运行在Node里的webpack是单线程模型，简单来说就是webpack待处理的任务需一件件处理，不能同一时刻处理多件任务。

文件读写与计算操作无法避免，能不能让webpack同一时刻处理多个任务，发挥多核CPU电脑的威力以提升构建速度呢？thread-loader来帮你，根据CPU个数开启线程。

在此需注意一个问题，若项目文件不算多就不要使用该性能优化建议，毕竟开启多个线程也会存在性能开销。

import Os from "os";

export default {
    // ...
    module: {
        rules: [{
            // ...
            test: /\.js$/,
            use: [{
                loader: "thread-loader",
                options: { workers: Os.cpus().length }
            }, {
                loader: "babel-loader",
                options: { cacheDirectory: true }
            }]
        }]
    }
};
复制代码

?可视结构

配置BundleAnalyzer分析打包文件结构，好处是找出导致体积过大的原因。从而通过分析原因得出优化方案减少构建时间。BundleAnalyzer是webpack官方插件，可直观分析打包文件的模块组成部分、模块体积占比、模块包含关系、模块依赖关系、文件是否重复、压缩体积对比等可视化数据。

可使用webpack-bundle-analyzer配置，有了它，我们就能快速找到相关问题。

import { BundleAnalyzerPlugin } from "webpack-bundle-analyzer";

export default {
    // ...
    plugins: [
        // ...
        BundleAnalyzerPlugin()
    ]
};
复制代码

分割代码

分割各个模块代码，提取相同部分代码，好处是减少重复代码的出现频率。webpack v4使用splitChunks替代CommonsChunksPlugin实现代码分割。

splitChunks配置较多，详情可参考官网，在此笔者贴上常用配置。

export default {
    // ...
    optimization: {
        runtimeChunk: { name: "manifest" }, // 抽离WebpackRuntime函数
        splitChunks: {
            cacheGroups: {
                common: {
                    minChunks: 2,
                    name: "common",
                    priority: 5,
                    reuseExistingChunk: true, // 重用已存在代码块
                    test: AbsPath("src")
                },
                vendor: {
                    chunks: "initial", // 代码分割类型
                    name: "vendor", // 代码块名称
                    priority: 10, // 优先级
                    test: /node_modules/ // 校验文件正则表达式
                }
            }, // 缓存组
            chunks: "all" // 代码分割类型：all全部模块，async异步模块，initial入口模块
        } // 代码块分割
    }
};
复制代码

摇树优化

删除项目中未被引用代码，好处是移除重复代码和未使用代码。摇树优化首次出现于rollup，是rollup的核心概念，后来在webpack v2里借鉴过来使用。

摇树优化只对ESM规范生效，对其他模块规范失效。摇树优化针对静态结构分析，只有import/export才能提供静态的导入/导出功能。因此在编写业务代码时必须使用ESM规范才能让摇树优化移除重复代码和未使用代码。

在webpack里只需将打包环境设置成生产环境就能让摇树优化生效，同时业务代码使用ESM规范编写，使用import导入模块，使用export导出模块。

export default {
    // ...
    mode: "production"
};
复制代码

动态垫片

通过垫片服务根据UA返回当前浏览器代码垫片，好处是无需将繁重的代码垫片打包进去。每次构建都配置@babel/preset-env和core-js根据某些需求将Polyfill打包进来，这无疑又为代码体积增加了贡献。

@babel/preset-env提供的useBuiltIns可按需导入Polyfill。

false：无视target.browsers将所有Polyfill加载进来
entry：根据target.browsers将部分Polyfill加载进来(仅引入有浏览器不支持的Polyfill，需在入口文件import "core-js/stable")
usage：根据target.browsers和检测代码里ES6的使用情况将部分Polyfill加载进来(无需在入口文件import "core-js/stable")

在此推荐大家使用动态垫片。动态垫片可根据浏览器UserAgent返回当前浏览器Polyfill，其思路是根据浏览器的UserAgent从browserlist查找出当前浏览器哪些特性缺乏支持从而返回这些特性的Polyfill。对这方面感兴趣的同学可参考polyfill-library和polyfill-service的源码。

在此提供两个动态垫片服务，可在不同浏览器里点击以下链接看看输出不同的Polyfill。相信IExplore还是最多Polyfill的，它自豪地说：我就是我，不一样的烟火。

官方CDN服务：polyfill.io/v3/polyfill…
阿里CDN服务：polyfill.alicdn.com/polyfill.mi…

使用html-webpack-tags-plugin在打包时自动插入动态垫片。

import HtmlTagsPlugin from "html-webpack-tags-plugin";

export default {
    plugins: [
        new HtmlTagsPlugin({
            append: false, // 在生成资源后插入
            publicPath: false, // 使用公共路径
            tags: ["https://polyfill.alicdn.com/polyfill.min.js"] // 资源路径
        })
    ]
};
复制代码

按需加载

将路由页面/触发性功能单独打包为一个文件，使用时才加载，好处是减轻首屏渲染的负担。因为项目功能越多其打包体积越大，导致首屏渲染速度越慢。

首屏渲染时只需对应JS代码而无需其他JS代码，所以可使用按需加载。webpack v4提供模块按需切割加载功能，配合import()可做到首屏渲染减包的效果，从而加快首屏渲染速度。只有当触发某些功能时才会加载当前功能的JS代码。

webpack v4提供魔术注解命名切割模块，若无注解则切割出来的模块无法分辨出属于哪个业务模块，所以一般都是一个业务模块共用一个切割模块的注解名称。

const Login = () => import( /* webpackChunkName: "login" */ "../../views/login");
const Logon = () => import( /* webpackChunkName: "logon" */ "../../views/logon");
复制代码

运行起来控制台可能会报错，在package.json的babel相关配置里接入@
babel/plugin-syntax-dynamic-import即可。

{
    // ...
    "babel": {
        // ...
        "plugins": [
            // ...
            "@babel/plugin-syntax-dynamic-import"
        ]
    }
}
复制代码

作用提升

分析模块间依赖关系，把打包好的模块合并到一个函数中，好处是减少函数声明和内存花销。作用提升首次出现于rollup，是rollup的核心概念，后来在webpack v3里借鉴过来使用。

在未开启作用提升前，构建后的代码会存在大量函数闭包。由于模块依赖，通过webpack打包后会转换成IIFE，大量函数闭包包裹代码会导致打包体积增大(模块越多越明显)。在运行代码时创建的函数作用域变多，从而导致更大的内存开销。

在开启作用提升后，构建后的代码会按照引入顺序放到一个函数作用域里，通过适当重命名某些变量以防止变量名冲突，从而减少函数声明和内存花销。

在webpack里只需将打包环境设置成生产环境就能让作用提升生效，或显式设置concatenateModules。

export default {
    // ...
    mode: "production"
};
// 显式设置
export default {
    // ...
    optimization: {
        // ...
        concatenateModules: true
    }
};
复制代码

压缩资源

压缩HTML/CSS/JS代码，压缩字体/图像/音频/视频，好处是更有效减少打包体积。极致地优化代码都有可能不及优化一个资源文件的体积更有效。

针对HTML代码，使用html-webpack-plugin开启压缩功能。

import HtmlPlugin from "html-webpack-plugin";

export default {
    // ...
    plugins: [
        // ...
        HtmlPlugin({
            // ...
            minify: {
                collapseWhitespace: true,
                removeComments: true
            } // 压缩HTML
        })
    ]
};
复制代码

针对CSS/JS代码，分别使用以下插件开启压缩功能。其中OptimizeCss基于cssnano封装，Uglifyjs和Terser都是webpack官方插件，同时需注意压缩JS代码需区分ES5和ES6。

optimize-css-assets-webpack-plugin：压缩CSS代码
uglifyjs-webpack-plugin：压缩ES5版本的JS代码
terser-webpack-plugin：压缩ES6版本的JS代码

import OptimizeCssAssetsPlugin from "optimize-css-assets-webpack-plugin";
import TerserPlugin from "terser-webpack-plugin";
import UglifyjsPlugin from "uglifyjs-webpack-plugin";

const compressOpts = type => ({
    cache: true, // 缓存文件
    parallel: true, // 并行处理
    [`${type}Options`]: {
        beautify: false,
        compress: { drop_console: true }
    } // 压缩配置
});
const compressCss = new OptimizeCssAssetsPlugin({
    cssProcessorOptions: {
        autoprefixer: { remove: false }, // 设置autoprefixer保留过时样式
        safe: true // 避免cssnano重新计算z-index
    }
});
const compressJs = USE_ES6
    ? new TerserPlugin(compressOpts("terser"))
    : new UglifyjsPlugin(compressOpts("uglify"));

export default {
    // ...
    optimization: {
        // ...
        minimizer: [compressCss, compressJs] // 代码压缩
    }
};
复制代码

针对字体/音频/视频文件，还真没相关Plugin供我们使用，就只能拜托大家在发布项目到生产服前使用对应的压缩工具处理了。针对图像文件，大部分Loader/Plugin封装时均使用了某些图像处理工具，而这些工具的某些功能又托管在国外服务器里，所以导致经常安装失败。具体解决方式可回看笔者曾经发布的《聊聊NPM镜像那些险象环生的坑》一文寻求答案。

鉴于此，笔者花了一点小技巧开发了一个Plugin用于配合webpack压缩图像，详情请参考tinyimg-webpack-plugin。

import TinyimgPlugin from "tinyimg-webpack-plugin";

export default {
    // ...
    plugins: [
        // ...
        TinyimgPlugin()
    ]
};
复制代码

上述构建策略都集成到笔者开源的bruce-cli里，它是一个React/Vue应用自动化构建脚手架，其零配置开箱即用的优点非常适合入门级、初中级、快速开发项目的前端同学使用，还可通过创建brucerc.js文件覆盖其默认配置，只需专注业务代码的编写无需关注构建代码的编写，让项目结构更简洁。详情请戳这里，使用时记得查看文档，支持一个Star哈！

图像策略

该策略主要围绕图像类型做相关处理，同时也是接入成本较低的性能优化策略。只需做到以下两点即可。

图像选型：了解所有图像类型的特点及其何种应用场景最合适
图像压缩：在部署到生产环境前使用工具或脚本对其压缩处理

图像选型一定要知道每种图像类型的体积/质量/兼容/请求/压缩/透明/场景等参数相对值，这样才能迅速做出判断在何种场景使用何种类型的图像。

类型	体积	质量	兼容	请求	压缩	透明	场景
JPG	小	中	高	是	有损	不支持	背景图、轮播图、色彩丰富图
PNG	大	高	高	是	无损	支持	图标、透明图
SVG	小	高	高	是	无损	支持	图标、矢量图
WebP	小	中	低	是	兼备	支持	看兼容情况
Base64	看情况	中	高	否	无损	支持	图标

图像压缩可在上述构建策略-压缩资源里完成，也可自行使用工具完成。由于现在大部分webpack图像压缩工具不是安装失败就是各种环境问题(你懂的)，所以笔者还是推荐在发布项目到生产服前使用图像压缩工具处理，这样运行稳定也不会增加打包时间。

好用的图像压缩工具无非就是以下几个，若有更好用的工具麻烦在评论里补充喔！

工具	开源	收费	API	免费体验
QuickPicture	??	??	??	可压缩类型较多，压缩质感较好，有体积限制，有数量限制
ShrinkMe	??	??	??	可压缩类型较多，压缩质感一般，无数量限制，有体积限制
Squoosh	??	??	??	可压缩类型较少，压缩质感一般，无数量限制，有体积限制
TinyJpg	??	??	??	可压缩类型较少，压缩质感很好，有数量限制，有体积限制
TinyPng	??	??	??	可压缩类型较少，压缩质感很好，有数量限制，有体积限制
Zhitu	??	??	??	可压缩类型一般，压缩质感一般，有数量限制，有体积限制

若不想在网站里来回拖动图像文件，可使用笔者开源的图像批处理工具img-master代替，不仅有压缩功能，还有分组功能、标记功能和变换功能。目前笔者负责的全部项目都使用该工具处理，一直用一直爽！

图像策略也许处理一张图像就能完爆所有构建策略，因此是一种很廉价但极有效的性能优化策略。

分发策略

该策略主要围绕内容分发网络做相关处理，同时也是接入成本较高的性能优化策略，需足够资金支持。

虽然接入成本较高，但大部分企业都会购买一些CDN服务器，所以在部署的事情上就不用过分担忧，尽管使用就好。该策略尽量遵循以下两点就能发挥CDN最大作用。

所有静态资源走CDN：开发阶段确定哪些文件属于静态资源
把静态资源与主页面置于不同域名下：避免请求带上Cookie

内容分发网络简称CDN，指一组分布在各地存储数据副本并可根据就近原则满足数据请求的服务器。其核心特征是缓存和回源，缓存是把资源复制到CDN服务器里，回源是资源过期/不存在就向上层服务器请求并复制到CDN服务器里。

使用CDN可降低网络拥塞，提高用户访问响应速度和命中率。构建在现有网络基础上的智能虚拟网络，依靠部署在各地服务器，通过中心平台的调度、负载均衡、内容分发等功能模块，使用户就近获取所需资源，这就是CDN的终极使命。

基于CDN的就近原则所带来的优点，可将网站所有静态资源全部部署到CDN服务器里。那静态资源包括哪些文件？通常来说就是无需服务器产生计算就能得到的资源，例如不常变化的样式文件、脚本文件和多媒体文件(字体/图像/音频/视频)等。

若需单独配置CDN服务器，可考虑阿里云OSS、网易树帆NOS和七牛云Kodo，当然配置起来还需购买该产品对应的CDN服务。由于篇幅问题，这些配置在购买后会有相关教程，可自行体会，在此就不再叙述了。

笔者推荐大家首选网易树帆NOS，毕竟对自家产品还是挺有信心的，不小心给自家产品打了个小广告了，哈哈！

缓存策略

该策略主要围绕浏览器缓存做相关处理，同时也使接入成本最低的性能优化策略。其显著减少网络传输所带来的损耗，提升网页访问速度，是一种很值得使用的性能优化策略。

通过下图可知，为了让浏览器缓存发挥最大作用，该策略尽量遵循以下五点就能发挥浏览器缓存最大作用。

考虑拒绝一切缓存策略：Cache-Control:no-store
考虑资源是否每次向服务器请求：Cache-Control:no-cache
考虑资源是否被代理服务器缓存：Cache-Control:public/private
考虑资源过期时间：Expires:t/Cache-Control:max-age=t,s-maxage=t
考虑协商缓存：Last-Modified/Etag

同时浏览器缓存也是高频面试题之一，笔者觉得上述涉及到的名词在不同语序串联下也能完全理解才能真正弄懂浏览器缓存在性能优化里起到的作用。

缓存策略通过设置HTTP报文实现，在形式上分为强缓存/强制缓存和协商缓存/对比缓存。为了方便对比，笔者将某些细节使用图例展示，相信你有更好的理解。

整个缓存策略机制很明了，先走强缓存，若命中失败才走协商缓存。若命中强缓存，直接使用强缓存；若未命中强缓存，发送请求到服务器检查是否命中协商缓存；若命中协商缓存，服务器返回304通知浏览器使用本地缓存，否则返回最新资源。

有两种较常用的应用场景值得使用缓存策略一试，当然更多应用场景都可根据项目需求制定。

频繁变动资源：设置Cache-Control:no-cache，使浏览器每次都发送请求到服务器，配合Last-Modified/ETag验证资源是否有效
不常变化资源：设置Cache-Control:max-age=31536000，对文件名哈希处理，当代码修改后生成新的文件名，当HTML文件引入文件名发生改变才会下载最新文件

渲染层面

渲染层面的性能优化，无疑是如何让代码解析更好执行更快。因此笔者从以下五方面做出建议。

CSS策略：基于CSS规则
DOM策略：基于DOM操作
阻塞策略：基于脚本加载
回流重绘策略：基于回流重绘
异步更新策略：基于异步更新

上述五方面都是编写代码时完成，充满在整个项目流程的开发阶段里。因此在开发阶段需时刻注意以下涉及到的每一点，养成良好的开发习惯，性能优化也自然而然被使用上了。

渲染层面的性能优化更多表现在编码细节上，而并非实体代码。简单来说就是遵循某些编码规则，才能将渲染层面的性能优化发挥到最大作用。

回流重绘策略在渲染层面的性能优化里占比较重，也是最常规的性能优化之一。上年笔者发布的掘金小册《玩转CSS的艺术之美》使用一整章讲解回流重绘，本章已开通试读，更多细节请戳这里。

CSS策略

避免出现超过三层的嵌套规则
避免为ID选择器添加多余选择器
避免使用标签选择器代替类选择器
避免使用通配选择器，只对目标节点声明规则
避免重复匹配重复定义，关注可继承属性

DOM策略

缓存DOM计算属性
避免过多DOM操作
使用DOMFragment缓存批量化DOM操作

阻塞策略

脚本与DOM/其它脚本的依赖关系很强：对

面试官问我前端可以做的性能优化有哪些

网络优化

DNS预解析

使用缓存

使用 CDN（内容分发网络）

压缩响应

使用多个域名

避免图片src为空

页面渲染优化

避免css阻塞

降低css选择器的复杂度

避免使用CSS 表达式

避免js阻塞

使用外链式的js和css

使用字体图标 iconfont 代替图片图标

首屏加载优化

减少重绘和回流

JS中的性能优化

使用事件委托

防抖和节流

尽量不要使用JS动画

多线程

计算结果缓存

图片的优化

雪碧图

图片懒加载

使用CSS3代替图片

图片压缩

使用渐进式jpeg

使用 webp 格式的图片

webpack打包优化

缩小loader 匹配范围

resolve.modules

resolve.extensions

抽离css

代码压缩

JS代码压缩

CSS代码压缩

Html文件代码压缩

文件大小压缩

图片压缩

Tree shaking 去除死代码

usedExports

sideEffects

css tree shaking

babel-plugin-transform-runtime减少ES6转化ES5的冗余

代码分离

多线程打包提升打包速度

vue

react

九大策略

网络层面

构建策略

图像策略

分发策略

缓存策略

渲染层面

CSS策略

DOM策略

阻塞策略