webpack性能优化——CommonsChunkPlugin

前言:

相信大家对webpack并不陌生&＃xff0c;用webpack打包也是非常常见的事&＃xff0c;但是webpack在打包的时候有很多配置可以对打包就行优化。
最近正好在研究这方面的东西&＃xff0c;所以在此记录一下&＃xff0c;以便日后查看。

一、webpack-bundle-analyzer

在进入正文之前先说一个“好玩”的东西&＃xff0c;是一个对webpack打包之后的文件进行分析的工具——webpack-bundle-analyzer

1. 安装

虽然是在webpack的配置文件中使用&＃xff0c;但并不是webpack官方提供的插件&＃xff0c;需要使用npm进行安装&＃xff1a;

npm install webpack-bundle-analyzer --save-dev

2. 使用

首先在webpack的配置文件中引入webpack-bundle-analyzer&＃xff0c;比如我的文件名是webpack.demo.config.js&＃xff1a;

// webpack.demo.config.jsvar BundleAnalyzerPlugin &＃61; require(&＃39;webpack-bundle-analyzer&＃39;).BundleAnalyzerPlugin

接着使用引入的BundleAnalyzerPlugin&＃xff1a;

// webpack.demo.config.jsnew BundleAnalyzerPlugin({analyzerMode: &＃39;server&＃39;,analyzerHost: &＃39;127.0.0.1&＃39;,analyzerPort: 8888,reportFilename: &＃39;report.html&＃39;,defaultSizes: &＃39;parsed&＃39;,openAnalyzer: true,generateStatsFile: false,statsFilename: &＃39;stats.json&＃39;,statsOptions: null,logLevel: &＃39;info&＃39;
})

可以看到里面的参数还是很多的&＃xff1a;

• analyzerMode&＃xff1a;表示已什么方式查看分析结果&＃xff0c;可选参数为server, static or disabled。

• analyzerHost&＃xff1a;analyzerMode为server的时候生效&＃xff0c;表示启动http服务的IP地址。

• analyzerPort&＃xff1a;analyzerMode为server的时候生效&＃xff0c;表示启动http服务的端口号。

• reportFilename&＃xff1a;analyzerMode为static的时候生效&＃xff0c;表示输出静态文件的文件名&＃xff0c;输出路径output路径相同。

• defaultSizes&＃xff1a;表示默认显示的数据模式&＃xff0c;可选参数为stat, parsed or gzip。

• openAnalyzer&＃xff1a;true|false&＃xff0c;表示是否在打包完成之后自动打开分析界面。

• generateStatsFile&＃xff1a;true|false&＃xff0c;表示是否生成.json文件。

• statsFilename&＃xff1a;设置generateStatsFile为true的时候生成的.json文件名。

• statsOptions&＃xff1a;通过修改生成的.json文件中的source:false来排除模块的源码。

• logLevel&＃xff1a;日志的显示方式&＃xff0c;可选参数为info, warn, error or silent。

3. 效果

    无论是通过http服务还是通过打开静态文件的方式效果都是一样的&＃xff1a;

    从上面就可以看出上面的数据有三种&＃xff0c;分别是defaultSizes的三个参数&＃xff0c;由于我设置的是parsed所以默认显示parsed的大小。

简单解释一下defaultSizes三个参数的含义&＃xff1a;
stat&＃xff1a;是指打包之前的文件大小
parsed&＃xff1a;是指打包之后的文件大小
gzip&＃xff1a;是指通过gzip压缩之后的文件大小

    如果默认设置了parsed,但是我想看stat时候的文件大小视图改怎么办呢&＃xff1f;
    当然可以在这个分析界面中去调整&＃xff1a;

4. 小结

    把最近看到的好东西拿出来分享一下&＃xff0c;觉得使用这个东西一眼就能看出打包后的结构&＃xff0c;每个模块分的很清晰&＃xff0c;而且通过视图中每个模块占的面积大小很直观的能看出各个文件的体积比例&＃xff0c;这对打包的分析很有帮助&＃xff0c;并且使用简单&＃xff0c;不需要进行什么复杂的配置。

二、CommonsChunkPlugin

接下来进入正题&＃xff0c;就是这个webpack本身提供的插件 —— CommonsChunkPlugin

首先&＃xff0c;介绍一下插件的使用格式&＃xff1b;
然后&＃xff0c;分析其中的每个参数的作用&＃xff1b;
最后&＃xff0c;举一个实际的“栗子”。

1. 介绍

    看到CommonsChunkPlugin这个名字&＃xff0c;大概明白这个插件是跟公共模块有关系的。没错&＃xff0c;这个插件就是用来提取出代码中公共的部分&＃xff0c;并且将他们打包到一个单独的文件里面&＃xff0c;这样就避免了重复打包。同时&＃xff0c;由于配置中有minChunks(在文章后面会讲这个参数的作用)这个参数的存在可以满足一些其他的需求&＃xff0c;不仅仅是提取公共部分这么简单了&＃xff0c;而且一个文件中可以使用多次CommonsChunkPlugin插件。

    另外&＃xff0c;还需要知道两个名词&＃xff1a;chunk和chunkName。

    chunk&＃xff1a;通过CommonsChunkPlugin生成的一个文件就是一个chunk&＃xff0c;由于可能多次使用插件&＃xff0c;所以每次打完包可能会很多chunk。

注&＃xff1a;如果是多入口&＃xff0c;每一个入口文件都是一个chunk。

    chunkName&＃xff1a;上面说过每使用一次插件就会生成一个chunk&＃xff0c;那这些chunk通过什么区分呢&＃xff1f;答案就是chunkName。

2. 使用

    由于是webpack提供的插件&＃xff0c;所以就不需要安装了&＃xff0c;直接在配置文件中引入&＃xff0c;同样在此还是以webpack.demo.config.js为配置文件&＃xff1a;

// webpack.demo.config.jsvar CommonsChunkPlugin &＃61; require("webpack/lib/optimize/CommonsChunkPlugin")/*
* 省略其他代码
**/new CommonsChunkPlugin({name: string, // ornames: string[],filename: string,minChunks: number|Infinity|function(module, count) -> boolean,chunks: string[],children: boolean,async: boolean|string,minSize: number,
})


or

当然&＃xff0c;你也可以选择在头部一次引入webpack&＃xff0c;以后内置的插件都可以通过webpack来使用&＃xff0c;像这样&＃xff1a;

// webpack.demo.config.jsvar webpack &＃61; require(&＃39;webpack&＃39;)/*
* 省略其他代码
**/new webpack.optimize.CommonsChunkPlugin({name: string, // ornames: string[],filename: string,minChunks: number|Infinity|function(module, count) -> boolean,chunks: string[],children: boolean,async: boolean|string,minSize: number,
})

3. 参数

name|names&＃xff1a;这里的name就是上面所说的chunkName,如果包括过个chunk,那么就使用names,以数组的形式传入chunkName,如&＃xff1a;

names: [&＃39;vendor&＃39;,&＃39;utils&＃39;]

filename&＃xff1a;打包后的文件名&＃xff0c;可以省略&＃xff0c;如果省略默认文件名为name的值。

minChunks&＃xff1a;定义提取公共部分的规则。

个人觉得这个minChunks是整个插件最屌的没有之一(自行忽略)。
如果值为数字,例&＃xff1a;minChunks:2&＃xff0c;就说明提取文件中最少被引用2次的代码&＃xff0c;
如果值为Infinity,将会直接创建一个公共的chunk,但是里面没有模块&＃xff0c;
如果值为函数&＃xff0c;将会提取出满足函数条件的代码&＃xff0c;生成一个公共chunk&＃xff0c;所以可以在这里实现以下定制化的需求。函数会提供两个参数&＃xff1a;module和count。

chunks&＃xff1a;定义从哪些chunk中提取公共模块&＃xff0c;如果省略&＃xff0c;默认为入口chunk。

children&＃xff1a;默认是false&＃xff0c;多个chunk里面的模块可能会有相同的依赖关系&＃xff0c;如果设置为true&＃xff0c;将其中相同的依赖提到父元素中(但是会影响初始加载的时间)。

async&＃xff1a;异步加载的附加公共chunk&＃xff0c; 当下载附加组块时&＃xff0c;它会并行自动下载。

minSize&＃xff1a;创建公共chunk之前&＃xff0c;所有公共模块的的最小体积。

4. 实战

上面说了一堆理论&＃xff0c;讲了一下基本结构&＃xff0c;具体用法现在开始了&＃xff01;

下面是我一个Vue工程的项目结构&＃xff1a;

现在我想要提取出node_modules中以.js结尾的文件和src下以.vue结尾的文件&＃xff0c;将他们分别打到两个文件中。

先看一下入口和出口文件&＃xff1a;

entry: {main: &＃39;./examples/main.js&＃39;
},
output: {path: path.resolve(__dirname, &＃39;../demo&＃39;),filename: &＃39;[name].[chunkhash].js&＃39;,
}

接着&＃xff0c;按照上面说的&＃xff0c;我首先引入CommonsChunkPlugin&＃xff1a;

var CommonsChunkPlugin &＃61; require("webpack/lib/optimize/CommonsChunkPlugin")

接着使用这个插件&＃xff1a;

new CommonsChunkPlugin({name: "list",minChunks: function (module, count) {return (module.resource &&/\.js$/.test(module.resource) &&module.resource.indexOf(path.join(__dirname, &＃39;../node_modules&＃39;)) &＃61;&＃61;&＃61; 0)}
}),
new CommonsChunkPlugin({name: &＃39;components&＃39;,chunks: [&＃39;main&＃39;],minChunks: function (module, count) {return (module.resource &&/\.vue$/.test(module.resource) &&module.resource.indexOf(path.join(__dirname, &＃39;../src&＃39;)) &＃61;&＃61;&＃61; 0)}
}),
new CommonsChunkPlugin({name: "manifest",chunks: [&＃39;list&＃39;, &＃39;components&＃39;]
})

打完包之后的结果是这样的&＃xff0c;确实单独打出了两个文件&＃xff1a;

Asset Size Chunks Chunk Names
components.8ec10c04b75e68ee707a.js 479 kB 1 [emitted] [big] componentsmain.a33511b70c4ad0a4aead.js 738 kB 2 [emitted] [big] mainlist.b2de50f4150e217815ca.js 789 kB 3 [emitted] [big] listmanifest.9412c3435bf535f63115.js 6.07 kB 4 [emitted] manifest

打包生成的文件目录结构是这样的&＃xff1a;

用webpack-bundle-analyzer打开效果是这样的&＃xff1a;

5. 进阶

看着文档很简单&＃xff0c;但是实际操作起来就有许多问题&＃xff0c;比如&＃xff1a;
- 打包之后Chunks那一列数字是什么&＃xff1f;
- 出口文件中的chunkhash是什么&＃xff1f;
- 生成manifest又是什么&＃xff1f;
- minChunks函数中的参数到底有什么作用&＃xff1f;

chunkhash

    首先&＃xff0c;chunkhash既然叫hash&＃xff0c;所以是一种hash值。当然&＃xff0c;你也可以这么定义出口文件&＃xff1a;

filename: &＃39;[name].[hash].js&＃39;

这里解释一下chunkhash与hash的区别&＃xff1a;
- 对于打包生成的每个文件都有单独的hash值&＃xff0c;这个hash值就叫做chunkhash&＃xff1b;
- 而如果我们用[hash]定义出口文件&＃xff0c;打包之后的文件hash值是一致的&＃xff0c;因为这个hash是整个的hash值&＃xff0c;我把出口文件改了之后打包生成的文件放在下面&＃xff0c;可以跟上面打包后的文件对比一下&＃xff1b;
- 所以&＃xff0c;chunkhash与hash的区别就是私有hash与全局hash的关系。

Asset Size Chunks Chunk Names
components.26ae71410d030a4f8f66.js 479 kB 1 [emitted] [big] componentsmain.26ae71410d030a4f8f66.js 738 kB 2 [emitted] [big] mainlist.26ae71410d030a4f8f66.js 789 kB 3 [emitted] [big] listmanifest.26ae71410d030a4f8f66.js 5.98 kB 4 [emitted] manifest

manifest

    那么manifest又是什么呢&＃xff1f;其实就是webpack的一个清单文件&＃xff0c;manifest的作用就是将你之前打包好的每个文件的chunkhash利用webpack的缓存机制保存起来&＃xff0c;如果下次没有修给这个chunk里面的文件&＃xff0c;那你打包之后文件的chunkhash是不变的&＃xff0c;修改过的会生成新的chunkhash。
    接下来我修改上文中的其中一个.vue文件&＃xff0c;在重新打包的结果是这样的&＃xff0c;可以跟之前的对比一下&＃xff0c;看是不是其他chunkhash没有变&＃xff1a;

Asset Size Chunks Chunk Names
components.c2315d7bc104f905405c.js 479 kB 1 [emitted] [big] componentsmain.a33511b70c4ad0a4aead.js 738 kB 2 [emitted] [big] mainlist.b2de50f4150e217815ca.js 789 kB 3 [emitted] [big] listmanifest.e3e56878b56c560148b7.js 6.07 kB 4 [emitted] manifest

minChunks

    当minChunks为函数的时候&＃xff0c;webpack会提供两个参数&＃xff1a;module和 count。其中&＃xff0c;module有两个属性module.context和module.resource&＃xff1a;
    - module.resource&＃xff1a;表示正在处理的文件位置(其实就是文件的路径)
    - module.context&＃xff1a;表示文件所在的目录
    - count&＃xff1a;表示文件被引用的次数

有兴趣可以把module.context和module.resource打印出来看一下。

对于count的使用其实很简单&＃xff0c;这里我还是想提一下&＃xff0c;直接把官网的栗子拿过来说&＃xff1a;

new CommonsChunkPlugin({name: "list",minChunks: function (module, count) {// 这里就是说&＃xff0c;将文件路径中存在somelib并且被引用了3次的文件// 如果说没有前面的条件&＃xff0c;完全可以直接设置minChunks:3return module.resource && (/somelib/).test(module.resource) && count &＃61;&＃61;&＃61; 3}
}),

    到这里&＃xff0c;上面写的CommonsChunkPlugin配置基本就很清晰了&＃xff0c;但是对于打包之后的Chunks列数字问题&＃xff0c;我在这里说一下&＃xff0c;那些数字其实叫做Chunks.id&＃xff0c;是自动生成的&＃xff0c;从0开始。这时候细心的人发现我上面的打包结果中并没有0&＃xff0c;是从1开始的&＃xff0c;这是为什么呢&＃xff1f;答案是&＃xff1a;其实是有0的&＃xff0c;只不过打出来的文件与本文并没有关系&＃xff0c;所以让我手动把第一行给删了&＃xff0c;不要纠结&＃xff0c;就是从0开始的&＃xff0c;没毛病。

6. 小节

上面就CommonsChunkPlugin的作用及配置进行了介绍&＃xff0c;并且展示了一个小栗子&＃xff0c;根据结果又分析出了很多东西。但是由于篇幅太长&＃xff0c;配置里面的参数没有一一展示demo&＃xff0c;如果想用可以自己再慢慢探索。

三、总结

    到这里文章就结束了&＃xff0c;主要的目的还是为了记录和学习&＃xff0c;顺便分享一下&＃xff0c;以上都是亲自实践以及一些个人的理解&＃xff0c;有兴趣的话也可以互相交流&＃xff0c;交流是人类进步的阶梯。