前端性能优化之webpack性能优化
webpack性能优化
在这部分的内容中,我们会聚焦于以下三个知识点
- 有哪些方式可以减少 Webpack 的打包时间
- 有哪些方式可以让 Webpack 打出来的包更小
- 监视和分析应用程序
减少 Webpack 打包时间
优化 Loader
对于 Loader 来说,影响打包效率首当其冲必属 Babel 了。因为 Babel 会将代码转为字符串生成 AST(抽象语法树),然后对 AST 继续进行转变最后再生成新的代码,项目越大,转换代码越多,效率就越低。当然了,我们是有办法优化的。
首先我们可以优化 Loader 的文件搜索范围
module.exports = {
module: {
rules: [
{
// js 文件才使用 babel
test: /\.js$/,
loader: 'babel-loader',
// 只在 src 文件夹下查找
include: [resolve('src')],
// 不会去查找的路径
exclude: /node_modules/
}
]
}
}
对于 Babel 来说,我们肯定是希望只作用在 JS 代码上的,然后 node_modules
中使用的代码都是编译过的,所以我们也完全没有必要再去处理一遍。
当然这样做还不够,我们还可以将 Babel 编译过的文件缓存起来,下次只需要编译更改过的代码文件即可,这样可以大幅度加快打包时间
loader: 'babel-loader?cacheDirectory=true'
HappyPack
受限于 Node 是单线程运行的,所以 Webpack 在打包的过程中也是单线程的,特别是在执行 Loader 的时候,长时间编译的任务很多,这样就会导致等待的情况。
HappyPack 可以将 Loader 的同步执行转换为并行的,这样就能充分利用系统资源来加快打包效率了
module: {
loaders: [
{
test: /\.js$/,
include: [resolve('src')],
exclude: /node_modules/,
// id 后面的内容对应下面
loader: 'happypack/loader?id=happybabel'
}
]
},
plugins: [
new HappyPack({
id: 'happybabel',
loaders: ['babel-loader?cacheDirectory'],
// 开启 4 个线程
threads: 4
})
]
DllPlugin
DllPlugin 可以将特定的类库提前打包然后引入。这种方式可以极大的减少打包类库的次数,只有当类库更新版本才有需要重新打包,并且也实现了将公共代码抽离成单独文件的优化方案。
接下来我们就来学习如何使用 DllPlugin
// 单独配置在一个文件中
// webpack.dll.conf.js
const path = require('path')
const webpack = require('webpack')
module.exports = {
entry: {
// 想统一打包的类库
vendor: ['react']
},
output: {
path: path.join(__dirname, 'dist'),
filename: '[name].dll.js',
library: '[name]-[hash]'
},
plugins: [
new webpack.DllPlugin({
// name 必须和 output.library 一致
name: '[name]-[hash]',
// 该属性需要与 DllReferencePlugin 中一致
context: __dirname,
path: path.join(__dirname, 'dist', '[name]-manifest.json')
})
]
}
然后我们需要执行这个配置文件生成依赖文件,接下来我们需要使用 DllReferencePlugin 将依赖文件引入项目中
// webpack.conf.js
module.exports = {
// ...省略其他配置
plugins: [
new webpack.DllReferencePlugin({
context: __dirname,
// manifest 就是之前打包出来的 json 文件
manifest: require('./dist/vendor-manifest.json'),
})
]
}
代码压缩
在 Webpack3 中,我们一般使用 UglifyJS
来压缩代码,但是这个是单线程运行的,为了加快效率,我们可以使用 webpack-parallel-uglify-plugin
来并行运行 UglifyJS
,从而提高效率。
在 Webpack4 中,我们就不需要以上这些操作了,只需要将 mode
设置为 production
就可以默认开启以上功能。代码压缩也是我们必做的性能优化方案,当然我们不止可以压缩 JS 代码,还可以压缩 HTML、CSS 代码,并且在压缩 JS 代码的过程中,我们还可以通过配置实现比如删除 console.log
这类代码的功能。
一些小的优化点
-
resolve.extensions
:用来表明文件后缀列表,默认查找顺序是['.js', '.json']
,如果你的导入文件没有添加后缀就会按照这个顺序查找文件。我们应该尽可能减少后缀列表长度,然后将出现频率高的后缀排在前面 -
resolve.alias
:可以通过别名的方式来映射一个路径,能让 Webpack 更快找到路径 -
module.noParse
:如果你确定一个文件下没有其他依赖,就可以使用该属性让 Webpack 不扫描该文件,这种方式对于大型的类库很有帮助
减少 Webpack 打包后的文件体积
按需加载
想必大家在开发 SPA (单页应用)
项目的时候,项目中都会存在十几甚至更多的路由页面。如果我们将这些页面全部打包进一个 JS 文件的话,虽然将多个请求合并了,但是同样也加载了很多并不需要的代码,耗费了更长的时间。那么为了首页能更快地呈现给用户,我们肯定是希望首页能加载的文件体积越小越好,这时候我们就可以使用按需加载,将每个路由页面单独打包为一个文件。当然不仅仅路由可以按需加载,对于 loadash
这种大型类库同样可以使用这个功能。
按需加载的代码实现这里就不详细展开了,因为鉴于用的框架不同,实现起来都是不一样的。当然了,虽然他们的用法可能不同,但是底层的机制都是一样的。都是当使用的时候再去下载对应文件,返回一个 Promise
,当 Promise
成功以后去执行回调。
Scope Hoisting
Scope Hoisting 会分析出模块之间的依赖关系,尽可能的把打包出来的模块合并到一个函数中去。
比如我们希望打包两个文件
// test.js
export const a = 1
// index.js
import { a } from './test.js'
对于这种情况,我们打包出来的代码会类似这样
[
/* 0 */
function (module, exports, require) {
//...
},
/* 1 */
function (module, exports, require) {
//...
}
]
但是如果我们使用 Scope Hoisting 的话,代码就会尽可能的合并到一个函数中去,也就变成了这样的类似代码
[
/* 0 */
function (module, exports, require) {
//...
}
]
这样的打包方式生成的代码明显比之前的少多了。如果在 Webpack4 中你希望开启这个功能,只需要启用 optimization.concatenateModules
就可以了。
module.exports = {
optimization: {
concatenateModules: true
}
}
Tree Shaking
**当您使用 ES 模块时,**webpack 变得能够进行Tree Shaking。 Tree Shaking就是当捆绑器遍历整个依赖关系树,检查使用了哪些依赖关系,并删除未使用的依赖关系。 因此,如果你使用 ES 模块语法,webpack 可以消除未使用的代码:
Tree Shaking 可以实现删除项目中未被引用的代码,比如
// test.js
export const a = 1
export const b = 2
// index.js
import { a } from './test.js'
对于以上情况,test 文件中的变量 b 如果没有在项目中使用到的话,就不会被打包到文件中。
如果你使用 Webpack 4 的话,开启生产环境就会自动启动这个优化功能。
监视和分析应用程序
即使你把 webpack 设置成尽可能小的应用程序,跟踪它并了解它包含的内容仍然很重要。 否则,你可以安装一个依赖项,使应用程序的大小增加一倍,甚至不会注意到它!
记录bundle的大小
为了监控应用程序的大小,在开发过程中使用 webpack-dashboard 并在 CI(持续集成) 上捆绑
webpack-dashboard
一个用于 webpack 开发服务器的 CI 仪表盘,当使用 webpack 时,特别是对于开发服务器,你可能会经常看到这样的东西:
这很酷,但是大部分都是噪音和噪音,没什么帮助。 这个插件改变了这一点。
这个仪表板有助于跟踪大型依赖项——如果您添加了一个,您将立即在模块部分中看到它!
要启用它,请安装 webpack-dashboard 包:
npm install webpack-dashboard --save-dev
然后把这个插件添加到配置文件的插件部分:
// webpack.config.js
const DashboardPlugin = require('webpack-dashboard/plugin');
module.exports = {
plugins: [
new DashboardPlugin(),
],
};
或者使用 compiler.apply () ,如果您使用的是基于 express 的 dev 服务器:
compiler.apply(new DashboardPlugin());
通过仪表板,找到可能的地方改进! 例如,在 Modules 部分中滚动查找哪些库太大,可以用较小的替代品替换
bundlesize
Bundleize 验证 webpack 资产没有超过指定的大小。 当应用程序变得太大时,将其与 CI 集成,以获得通知:
安装与配置
就是这样! 现在,如果您运行 npm run check-size 或者 push 代码,您将看到输出文件是否足够小:
总结:
- 删除不必要的字节。压缩所有内容,删除未使用的代码,明智地添加依赖项
- 按路由分割代码。现在只加载真正需要的内容,以后再延迟加载其他内容
- 缓存代码。 你的应用程序的某些部分比其他部分更新得少。 将这些部分分离成文件,以便只在必要时重新下载
- 记录大小。 使用像
webpack-dashboard
和webpack-bundle-analyzer
这样的工具来了解你的应用程序有多大。 每隔几个月重新审视一下你的应用程序的整体性能
不要忘记阅读 webpack 文档-他们有很多其他有用的信息。