浅谈webpack4.0 性能优化(转)

时间:2024-01-16 10:22:44

前言:在现实项目中,我们可能很少需要从头开始去配置一个webpack 项目,特别是webpack4.0发布以后,零配置启动一个项目成为一种标配。正因为零配置的webpack对项目本身提供的“打包”和“压缩”功能已经做了优化,所以实际应用中,我们可以把精力更多专注在业务层面上,而无需分心于项目构建上的优化。然而从学习者的角度,我们需要了解webpack在项目的构建和打包压缩过程中做了哪些的优化,以及在原有默认配置上,还可以做哪些性能方面上的改进。
       最近在完成vue的单页面应用后萌生了一个想法,抛弃掉vue-cli的构建配置,从零开始进行webpack优化,并将过程中的思路和体会分享在这篇文章中。webpack的初始配置在我之前写的另一篇手把手教你从零认识webpack4.0文章中,以下内容也不对基本的webpack配置做过多阐述。

一,优化的方向

1.1 项目开发

对开发者而言,我们希望webpack这个工具可以给我们带来流畅的开发体验。比如,当不断修改代码时,我们希望代码的变更能及时的通知浏览器刷新页面,而不是手动去刷新页面。更进一步的我们希望,代码的修改只会局部更换某个模块,而不是整个页面的刷新。这样可以使我们不需要在等待刷新中浪费很多时间,大大提高了页面的开发效率。

1.2 项目部署

项目部署上线时,性能优化是我们考虑的重点,有两个方向可以作为核心考虑的点,一个是减少HTTP请求,我们知道在网速相同的条件下,下载一个100KB的图片比下载两个50KB的图片要快,因此,我们要求webpack将多个文件打包成一个或者少量个文件;另一个优化的重点是减少单次请求的时间,也就是尽可能减少请求文件的体积大小。
       webpack中在性能优化所做的努力,也大抵围绕着这两个大方向展开。另外在构建项目中,我们也希望能持续的提高构建效率。

二, 提升开发效率

2.1 减少体积

开发环境下,我们依然对代码的体积有一定的要求,更小的体积可以让加载速度更快,开发效率更高,当然配置也相对简单。

// webpack.dev.js 开发环境webpack配置
module.exports = {
devServer: {
contentBase: path.join(__dirname, 'dist'),
port: 9000,
compress: true, // 代码压缩
},
}

2.2 模块热更新(HMR)

开发过程中,我们希望修改代码的过程中,页面能实时且不需要手动的刷新。因此使用HRM, HMR 既避免了频繁手动刷新页面,也减少了页面刷新时的等待,大幅度提高了开发效率。

// webpack.dev.js
module.exports = {
devServer: {
compress: true,
hot: true // 开启配置
},
plugins: [
new webpack.NamedModulesPlugin(),
new webpack.HotModuleReplacementPlugin(),
],
}

三,构建体积优化

3.1 生产中的sourcemap 模式

webpack 在构建中提供了不少于7种的sourcemap模式,其中eval模式虽然可以提高构建效率,但是构建后的脚本较大,因此生产上并不适用。而source-map 模式可以通过生成的 .map 文件来追踪脚本文件的 具体位置,进而缩小脚本文件的体积,这是生产模式的首选,并且在生产中,我们需要隐藏具体的脚本信息,因此可以使用 cheap 和module 模式来达到目的。
综上,在生产的webpack devtool选项中,我们使用 cheap-module-source-map的配置

// webpack.pro.js 生产webpack配置脚本
module.exports = {
mode: 'production',
devtool: 'cheap-module-source-map',
}

3.2 独立css 文件

以单入口文件而论,通常我们会将页面的所有静态资源都打包成一个JS 文件,这已经实现了1.2 中的优化部分,将代码合并成一个静态资源,减少了HTTP 请求。

分离前

浅谈webpack4.0 性能优化(转)
但是接下来,我们需要将css代码独立开来,为什么呢?最主要的一点是我们希望更好的利用浏览器的缓存,当单独修改了样式时,独立的css文件可以不需要应用去加载整个的脚本文件,提高效率。并且,当遇到多页面的应用时,可以单独将一些公共部分的样式抽离开来,加载一个页面后,接下来的页面同样可以利用缓存来减少请求。

webpack4.0 中提供了抽离css文件的插件,mini-css-extract-plugin,只需要简单的配置便可以将css文件分离开来

const MiniCssExtractPlugin = require('mini-css-extract-plugin')

module.exports = {
···
plugins: [
new MiniCssExtractPlugin({
filename: "[name].[contenthash].css",
chunkFilename: "[name].[contenthash].css"
})
],
module: {
rules: {
test: /\.(css|scss)$/,
use: [process.env.NODE_ENV == 'production' ? MiniCssExtractPlugin.loader : 'style-loader', {
loader: 'css-loader',
options: {
sourceMap: true
},
}, "sass-loader"]
}
}
···
}
分离后

浅谈webpack4.0 性能优化(转)

3.3 压缩js, html, css 文件

要想优化构建后的体积,不断减少静态资源文件的大小,我们希望webpack帮助我们尽可能压缩文件的体积。对于js 脚本文件而言,webpack4.0 在mode 为‘production’时,默认会启动代码的压缩。除此之外,我们需要手动对html和css 进行压缩。

针对html 的压缩,只需要对html-webpack-plugin进行相关配置。

// webpack.base.js 

module.exports = {
plugins: [
new HtmlWebpackPlugin({
title: 'minHTML',
filename: 'index.html',
template: path.resolve(__dirname, '../index.html'),
minify: { // 压缩 HTML 的配置
collapseWhitespace: true,
removeComments: true,
useShortDoctype: true
}
}),
]
}

针对css 的压缩, webpack4.0 使用optimize-css-assets-webpack-plugin来压缩单独的css 文件。

const OptimizeCSSAssetsPlugin = require("optimize-css-assets-webpack-plugin");

module.exports = {
plugins: [
new OptimizeCSSAssetsPlugin()
],
}

浅谈webpack4.0 性能优化(转)
浅谈webpack4.0 性能优化(转)
对比之下,我们可以看到明显的效果,关于压缩css 更多的配置可以参考optimize-css-assets-webpack-plugin

3.4. 合并压缩图片

处理完前端的三大块js,html,css后, 接下来优化能想到的是处理图片。前面提到,提升性能的一个重要的条件是降低http请求数,而应用中经常会有大大小小的图片需要处理,对应用中的小图标来说,css sprite 是首选,将各种图标集合成一张大的图片可以很好的减少网络请求数。而对于需要独立开的图片,且大小在合理范围内时,我们可以将图片转换成 base64位编码,内嵌到css 中,同样可以减少请求。

3.4.1 base64 转换

处理图片资源时,webpack 提供了 file-loader 和url-loader 两个loaders供选择,file-loader 和url-loader 的作用,可以用来解析项目中图片文件的url引入问题。两者的区别在于,url-loader 可以将小于指定字节的文件转为DataURL, 大于指定字节 的依旧会使用file-loader 进行解析

// webpack.base.js
module.exports = {
module: {
rules: [{
test: /\.(png|jpe?g|gif|svg|ttf|woff2|woff)(\?.*)?$/,
use: [{
loader: 'url-loader',
options: {
limit: 10000, // 限制大小
}
},
]
},
}
3.4.2 压缩图片

处理完雪碧图和小图片的base64转换后,对于大图片来说,webpack还可以做到对图片进行压缩,推荐使用image-webpack-loader,插件提供了多种形式的压缩,详细可以参考官网文档

// webpack.base.js
module.exports = {
module: {
rules: [
{
loader: 'image-webpack-loader',
options: {
optipng: { // 使用 imagemin-optipng 压缩 png,enable: false 为关闭
enabled: true,
},
pngquant: { // 使用 imagemin-pngquant 压缩 png
quality: '65-90',
speed: 4
},
}
}
]
}
}

效果对比如下:
浅谈webpack4.0 性能优化(转)
浅谈webpack4.0 性能优化(转)

3.5 依赖库分离

一个中大型应用中,第三方的依赖,庞大得可怕,占据了打包后文件的一半以上。然而,这些依赖模块又是很少变更的资源,和css 代码分离的逻辑相似,分离第三方依赖库,可以更好的利用浏览器缓存,提升应用性能。因此,将依赖模块从业务代码中分离是性能优化重要的一环。
webpack4.0 中,依赖库的分离只需要通过 optimization.splitChunks 进行配置即可。

// webpack.pro.js
module.exports = {
optimization: {
splitChunks: {
cacheGroups: {
vendor: {
chunks: "initial",
test: path.resolve(__dirname, "../node_modules"),
name: "vendor", // 使用 vendor 入口作为公共部分
enforce: true,
},
},
},
},
}

公共库分离后的结果
浅谈webpack4.0 性能优化(转)

3.6 依赖分析

正如前面所讲,在优化分析中,实际影响体积最大的是 node_modules 的第三方库,这一部分的优化可以大大的减少打包后的体积。这里我们使用最新的webpack-bundle-analyzer插件来分析打包好后的模块,它可以将打包后的内容束展示位方便交互的直观树状图,通过它,可以知道项目大致有哪些模块组成,哪个模块占据的体积较大,是否是可替代的。

我们大致可以从几个方向考虑

  • 1.判断依赖是否不可或缺,依赖在项目中使用率是否过低。在项目中,可能针对某个运算,某个功能,我们使用了一个庞大的库,这个库在体积上的占比较大,而功能使用却较少。这个时候我们可以寻找体积更小,且功能满足的替换库,或者手动实现某些依赖的功能来替换他。
  • 2.大型库是否可以通过定制功能的方式减少体积。明显的一个例子是 echart, echart完全版的依赖压缩后也有几百k 之多,这显示是难以接受的。现实项目中,我们可能只需要少量或者部分的echart 功能,这时我们可以通过制定图表的形式,下载图表用到的功能,达到体积最优化。
  • 3.某些不可优化的大型库是否可以通过外部引用的方式减少文件体积。例如像bootstrap,vue这类无法优化的第三方库,通过免费开源的cdn服务不但可以减少文件体积,还可以提高网站的加载速度,也是个优化性能的方法

3.7 按需加载

前面提到依赖分析的方向中,如果大型库不可或缺,而且使用率也不算低的时候,我们可以通过按需加载的形式。这种方式实际上是先把你的代码在一些逻辑断点处分离开,然后在一些代码块中完成某些操作后,立即引用或即将引用另外一些新的代码块。这样加快了应用的初始加载速度,减轻了它的总体体积,因为某些代码块可能永远不会被加载。

webpack中利用require.ensure()实现按需加载,在不使用按需加载的情况下,首屏加载时会把所有的脚本同时加载出来,这往往会拖累首屏显示时间,带来不好的用户体验。例子来说。当项目需要使用大型的图表类库,而首页并不需要时,按需加载往往比同时加载在用户体验上好好得多。

当不需要按需加载的时候,我们的代码可能是这样的:

import test from './components/test.vue'
import test2 from './components/test2.vue'

开启按需加载时,我们的代码修改为:

const test = r => require.ensure([], () => r(require('./components/test.vue')), 'chunk1')
const test2 = r => require.ensure([], () => r(require('./components/test2.vue')), 'chunk2')

webpack 配置修改为

output: {
···
chunkFilename: '[name].[hash].js'
}

这时编译出来的文件会从原来的一个,变成了多个小文件。每个路由加载时会去加载不同的资源。特别在首屏的资源加载上进一步优化了应用的体验。

尽管如此,实际中我们需要根据项目的需求来衡量按需加载的可用性,尽管在首屏优化上取得较大的提升,但按需加载毕竟会将大的文件拆分成多个小文件,增加了http 的请求数。这又违背了性能优化的基础。所以实际中需要取舍,更需要权衡。

3.8 删除冗余代码

代码体积优化到这一步,基本可以优化的地方已经优化完毕了。接下来可以抓住一些细节做更细的优化。比如可以删除项目中上下文都未被引用的代码。这就是所谓的 Tree shaking 优化。webpack 4.0中,mode 为production 默认启动这一优化。但是,如果在项目中使用到babel的 话,需要把babel解析语法的功能关掉。只需要

// .babelrc

{
"presets": [["env", { "modules": false }]]
}

四,构建速度优化

说完如何减少项目构建后的大小后,接下来简单的谈一下如何提高构建的速度。实际上webpack的 构建速度,只需要简单的修改配置便能大幅提高速度。常见的设置如下。

4.1 babel-loader构建时间过长

4.1.1 限定加载器作用范围

由于babel-loader需要将语法进行转换,所耗费的时间较长,所以第一步需要限定babel-loader 作用的范围,让babel-loader 的搜索和转换准确的定位到指定模块。大幅提高构建速度。
例如:

// webpack.base.js
module.exports = {
module:{
rules: [
{
test: /\.js$/,
include: [resolve('src')],// 限定范围
use: {
loader: 'babel-loader',
},
},]
}
}
4.1.2 缓存加载器执行结果

正因为babel-loader在解析转换上耗时太长,所以我们希望能缓存每次执行的结果。webpack的loader中刚好有 cacheDirectory 的选项,默认为false 开启后将使用缓存的执行结果,打包速度明显提升。

// webpack.base.js
module.exports = {
module: {
rules: [
{
test: /\.js$/,
include: [resolve('src')],
use: {
loader: 'babel-loader?cacheDirectory',
},
},]
}
}

4.2 resolve 解析优化

webpack 的resolve 做相关的配置后,也可以让项目的构建速度加快。具体看下文的配置:

  • 当项目中出现 import 'react' 既不是绝对路径也不是相对路径时,指定好搜索的路径,可以不用过多的查询
  • 尽可能少的使用 resolve.alias 来设置路径别名,因为会影响到tree shaking 的优化
  • 后缀自动补全尽可能的少。减少路径查询的工作
  • 当使用的第三方库过大,并且不包含import require define 的调用。可以使用noParse让库不被loaders 解析
// webpack.base.js
module.exports = {
resolve: {
modules: [
path.resolve(__dirname, 'node_modules'),
], extensions: [".js"], // 避免新增默认文件,编码时使用详细的文件路径,代码会更容易解读,也有益于提高构建速度
mainFiles: ['index'],
},
module: {
noParse: function(content){
return /jquery/.test(content)
}
}
}

五,结语

webpack性能优化的瓶颈还是集中在构建时间和构建体积上,作为构建工具业界霸主,webpack一直不停的优化构建打包流程。通过对旧有项目的优化也可以对webpack这个工具以及性能优化的知识有更深的了解。