前语
笔者最近在收拾关于 webpack
相关的知识点,一方面是由于自己把握的知识点比较琐细、不够体系,有时分碰到问题不知从何下手,另外一方面 webpack5.0
已经在路上了,这的确是一个让人头秃的消息。
所以这就促使了我去体系性的回忆了一遍 webpack4.0
的一切知识点,包含 webpack
的由来,各种装备的运用、功能优化、Webpack
的底层原理、相关脚手架的装备剖析,都回忆了一波,大致目录如下图:
笔者把系列的文章都扔 ; r L +在了这个库房:webpack 学习收拾文档,有爱好的同学能够去看一波。
今日这篇文章+ & ` ; t P : u y也是笔者就学习文档中的功能优化这一块内容做的收拾与回忆。} X } N l 3 b d $
文章中运用到的案例代码链接放在了最底部,咱们自取。
为什N C b 4 r m / e么要优化
先来说说为什么要优化?当然假如你的项目很小,构建很快,其实不需求特别重视功能方面的问题。
可是随着项目涉及到的页面越来越多,功能和事务代码也会越来越多,相应的 webpack
的构建时刻也会越来越久,这个时分咱们就不得不考虑功能优化的事情了。
由于这个构建时刻与咱们的日常开发是密切相关,当咱们本地开发发动 devServer
或许 build
的时分,假如时刻过长,会大大下降咱们的工作效率。
试I 3 M s S Y想一个场景,咱们突然碰到一个紧急 bZ ` s F Uug
,项目c b e y – / ` [发动需求花费 3/4
分钟,改完后项目 build
上线也要 3/4
分钟,这个时分脑瓜是不是 duang
、duang
、duang
…
那接下来咱们看一下如何优化 webpack
的功能,进步 webpack
的构建速度。
剖析东西
在着手优化之前,咱们需求有一个量化的指标,得知道影响构建时刻的问题究竟出在哪里,是某个 chuE W [ }nk
文件太大了,仍是哪一个 loader
或许 plugin
耗时太久了等等。
咱们能够对经过一些东西对项目进行相应的 体积 和 速度8 | L : 7 T 剖析, 然后对症下药。
体积剖析h f t
初级剖析
能够经过官方供给x B I的 stat.json
文件协* I O Q z 9 i 助咱们剖析打b b j F R包成果,stat.json
文件^ c f A C X ) q #能够经过下面语句快速生成:
webpack --profile --json && : J z 1 ugt; stats.js# T o t C # -on
接着咱们经b O – R m i %过官网供给的 stats.json 剖析东西 进行剖析,上传 stats.jso. @ K + 2 , GnO | 0 ? C G j P
文件之后,就能够得到如下图所示剖析成果:
其间包含 webpack
的版别、打包时刻、打包进程的 hash] ( t @ q & B v
值、模块数量( modules
)、chunk
数量、打包生层的静态文件 assets
以及打包的正告和错误数。
咱们能够] 7 c剖析其供给 $ V B ~的内容,进行大致问题的定位。
第三方东西
webpack-bundle-analyzer 是打包剖析神器,它的界面个人觉得很美观,而且能很直观的给出每一个打包出来的文件的巨细以及各自的依靠,能够愈加便利的协助咱们对项目进行剖析。
运用如下:
// config/webpace b S u u Yk.common.js
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
co^ 7 x x ` f B F Cnst* f 2 { commonConfigP a _ ] O j ] = {
// ...
plugins: [
new BundleAnalyzerPlugin({
aF 9 j ) M * B BnalyzerPort: 8889, // 指定端口号
openAnalyzer: false,
}),( q ?
]
// ...
}
webpack-bundle-analyzer
其底层也是依靠stat.json
文件的,经过对stat.json
的剖析,得出最后的剖析页面
经过剖析东, W @ p U西的剖析,咱们能够知道哪些文件耗时比较多,打包出来的体积比较大,然后对有问题的文件进行优化。
速度剖析
咱们能够经过 speed-measure-webpack-plugin 这个插件协助咱们剖析整个打包的总耗时,以及每一个loader
和每一个 plugins
构建| F & ; E * 5所消耗的时刻,u ! A S然后协助咱们快速定0 6 I J ` L位到能够优化 Webpack
的装备。
如上图,耗时比较长的会以红色标出。
运用
引进此插件,创立一个 plugins
实例 smp
包} . ; @ n 0 4裹 webpack
装备文w S : d件即可,咱们修正一下 webpack
的公共装备文件L v c _ t N 9 U webpack.common.js
:
// config/webpack.coJ g / w 0mmon.js
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();
// ...
module.exports = (productio9 / ?n) => {
if (production) {
const endProdConfig = merge(commonConfig, prodConfig);
return smp.wrap(endProdConfig);1 _ l ~ R F
} else {
const endDevConfF # g q c 8ig = merge(comv = umonConfig, devConfig);
rc A Eeturn smp.wrap(endDevConfig);
}
};
笔者文章演示的代码装备文件分为三个,别离为 开发环境装备文件,出产环境装备文件,以及前二者共用的公共装备文件,( ~ O % y L $如下:
webpack.dev.js
:开发环境运e O z用的装备文件webpack.prod.js
:出产环境运用的装备文件webpack.common.js
:公共装备文件
执行打G ! ^ 8 y包之. $ t后,能够看到如下作用图:
注意:
speed-me$ $ ? V { Hasure-webpack-plugin
关于webpack
的晋级还不够完善,暂时还无法与你自己编写的挂载在html-webpack-plugiH Y dn
供给的hooks
上的自定义Plugin
(add-asset-html-webpack-plugi[ f e 8 Kn
便是此类)共存,有人已经在 github 上提了 issue 了,可是形似仍是没有处理。
优化战略
经过相应的体积剖析和速度剖析之后,咱们便能够着手进行优化了。
运用新版别
这个是 webpack
功能优化的全能膏药,晋级版别必定能带来功能进步,而且进步很显着。
咱们能够看一张对比图:
从上图中咱们能够看到,
webpao * 6 9 _ i ? v Wck4.0
的构建速度远远快于webpack3.0
,官方也说晋级之后,晋级版别之后,构建时刻能够下降60% - 98%
左右。
在每一个版别的更新,webpack
内部必定会做很多优化,而 webpack
是依靠 Node
的 js
运转环境,晋级他们对应` } q的版别,webpack
的速度必定也能够获得进步。
说不定在
webpack5.0
出来之后,咱们今日讲到的大部分功能优化办– i x r p – 5法都会被集成到webpack
自? } L Z Q `身中去,咱们只需求经过几个简略的装备就能完结功能装备。
一起新版别的包管理东西(Npm
、Yarn
)也能够更快的协助咱们剖析一些包的依靠和引进,然后进步打包速度。
webpack4.l , M % e %0 带来的优化
-
v8
引擎带来的优化(for of
代替forEach
、Map
和Set
代替Object
、includes
代替indexOf
) - 默许运Z l q Y l m c $用更快的
md4 hash
算法 -
webpack AST
能够直接从loader
传递给AST
,削减解析时刻 - 运用字符串办法代替正则表达式
咱们能够在 github
上的 webpack
库的 releases 版别迭代 页面中检查其带来的功能优化:
一个 v4 Q 6 n8
功能优化比方:
咱们能够来M G { ?看一个比方,比较运用 in3 ~ ~cludes
代替 indexOf
之后带来的速度进步,创立 compare-i` C l [ Encludes-indexof.jo t 5 } H Ws
文件,在这个文件中i 9 a 7 ^ : I建一个 10000000
长度的数组,记载两个函数别离消耗的时刻:
const ARR_SIZE = 10000000;
cU p _ons? _ g A W g + = Qt hugeArr = new Array(ARRB | h j * q t B O_SIZE).fill(1);
// includes
const includC W WesTest = () => {
constF H W H s u 1 arrCopy = [];
console.time('ie N ` G O Y - /ncludes')
let i = 0;
while (i < hugeArr.length) {
arrCopy R = $ Z o 5.includes(i++);
}
console.timeEnd('includes');
}
// indexOf
const indexOfTest? 8 y m 6 = () => {
const arrCopy = [];
console.time('ind1 m 6 b u @ %exOf');
for (let item of h# X WugeArr) {
arrCopy.indexOf(item);
}
console.timeEnd('indexOf');
}
includesTest();
indexOfTest();
能够发现 includes
的速度远远快于 indexOf
:
-
includes
:p i y12.224ms
-
indexOf
:147.638ms
所以在项目上尽或许运用比较新的 web; ) @ 9 ; N 0pack
、d h $ x 1Node
、Npm
、Yarn
版别,是咱们进步打包速度的第一步。
体积M h t )优化
webpack
是个项目打包东西,一般项目打完包以后,需求发布到服务器上供用户运用,为了用户体会,咱们的项目体积需求越小越好~ c W ?,所以 webp! l &ack
中打包的体积是 webpack
中重要的一环。
js 紧缩
webpack4.0
默许在r 0 n出产环境的时分是支撑代码E Y S紧缩的,即 mode=production
模式下。
实践上 w; o Z M R , b Rebpack4.0
默许是运用 terser-webpack-c , , C r tplugin 这个紧缩插件,在此之前是运用 uglifyjs-webpack-plu7 . d Agin,两者的区别是后者对O E ` # ES6 的紧缩不是很好,一起咱们[ { j T !能够敞开 parallel
参数,运* p 0 B B o用多进程紧缩,加速紧缩。
// config/webpack.common.js
consd $ U ; %t TerserPlugin = require('terser-webpack-plugin');
//z S h } ..l ; m a j S Z L.
const commonL . w } FConfig = {
// ...
optimization: {
minimC / @ [ {ize: true,
minimizer: [
new TB w S { yersera * Z 3Plugin({
parallel: 4, //C ) ! _ ] 敞开几个进程来处理紧缩,默许是 os.cpus().length - 1
}),
],
},
// ...
}
CSS 紧缩
紧缩 CS^ @ o F tS
咱们能够凭借 optimize-css-assets-webpack-plugin
插件来紧缩 css
,其默许运用的紧缩引擎是 cssnano
。 详细运用V v E – l d @ f如下:
// config/webpack.prod.js
const OptimizeCSSAssetsPlugin = require("optimize-css-assetsi - V-webpack-plugin");
// ...
const prodConfig = {
// ...
optimization: {
minimizer: [
new OptimizeCSSAssetsPlugin({
assetNameRegExp: /.optimize.css$/g,
cssProcessor: require('cssnano'),
cssProcessorP$ M & 3lu4 k A Q kginOptions: {
preset: ['default` / O', {& I ^ j S W W d? [ j 6 d u 7iscardComments: { removeAll: true } }],
},
canPrint: true,
})
]
},
}
擦除无用的 CSS
运用 PurgeCSS
来完结对T j B E + n X W无用 css
的擦除,它需求和 mini-cs* . L [s-extract-plugin
配合运用。
// config/webpack.common.js
const PurgecssPlugin = require('purgecss-webpack-plugin] 4 ] E H');? . , | 4 0
// ...
const PAS A zTHS = {
src: path.join(__dir? a E . A *name, './src')
};
const commonConfig = {
// ...
plugins: [
// ...
new PurP . W Q f { E . TgecssPlugin({
paths: glob.sync(`${PATHS.src}/**/*`,b ? @ n V a { nodir: true }),
}),
]
// ...
}
在未运用此插件之前,比方咱们只用到C | 9 2 7 4了 navcontaU T 7 dct
这个类,其他的都没有用到,咱们在未引进之前打包一下,发现未用到的 cD i ]ss
仍是会被打包进去:
引进插件后,从头进行打包,发现没有用到的 css
都被擦除了:
更多运用咱们可参阅 PurgeCSS 文档。
图片紧缩
一般来说在打包之后,一些图片文件的巨细是远远要比 js
或许 css
文件要来的大,所以咱们首要要做的便是关于图片的优化,咱们能够手动的去经B @ p & g + ) e g过线上的图片紧缩东西,如 tiny png 帮咱们来紧缩图片。
可是这个比较繁琐,在项目中咱们期望能够愈加主动化一点,主动帮咱们做好图片紧缩,这个时分咱们就能够凭借 image-webpack-loader 协助咱们来完结。它是基于 imagemin= x z 这个 Node 库来完结图片紧缩的。
运用很/ f . – V 5 o f J简略,咱们只要在 file-loader
之后参加 image-webpack-loader
即可:
// config/webpack.common.js
// ...
module: {
rules: [[ q 5 G & 2 V M t
{
test: /.(png|jpg|gif)$/,
useW ( - W Q: [
{
loader:. % * e W e 'file-loader',
options: {
name: '[name]w [ k ^ ] R f_[has| _ vh].[ext]',
outputPath: 'images/',
}
},
{
loader: 'image-webpack-loader',
options: {
// 紧缩 jpeg 的装备
mozjpeg: {
progressive: true,
quality: 65
},
// 运用 imageminf % { _ .**-optipng 紧缩 png i c h t,enable: fa~ ! 3lse 为关闭
optipng: {
enabled: false,
},
// 运用 imagemin-pngquant 紧缩 png
pngquant: {
quality: '65-90',
s] + z 2 o R / B dpeed: 4
},
// 紧缩 gif 的装备
gD * 6 h E 0 mifsicle: {
interlaced: false,
}_ 8 i +,
// 敞开 webp,会把 jpgD J R U ~ p K 和 png 图片紧缩为 webp 格式
webp: {
quality: 75
}
}
}
]
},
]
}
// ...
咱们先不运用这个 loA V , h 0 _ k oader
打包一下,图片巨细是 2.1MB
:
运用 image-] z E j ) @ D , Nwebpack-loader
之后,图片巨细是 6i / . O M Y {66KB
:
紧缩的作用仍是很显着的。
拆分代码
有时分咱们写的某些模块根本没有运用,可是仍是被打包了,这样实践上会拖累 webpack
的打包速度,而且也会增 $ y p 9 { @加打包文件的体积,所以咱们能够运用 tree-shaking
将这些代码剔除去。
或许也能U ] ; C [够运用 splitChunksPlugin
把一个大的文件分割成几个小的文件,这样也能够有用的进步 webpack
的打包速度,详细的装备介绍咱们能够看笔者写的 装备 SplitChunksPlugin,里边详细介绍了怎样装备 splitChunks
,以及各参数的用法与意$ w 2义,在这儿就不打开讲了。
速度优化
讲) + v A ~ 0 !完打包体积的优化,咱们来看一下在速度方面的) [ y R T S优化。
分离两套装备
一般来说在项目开发中,咱们会区分开发和出产环境两套装备,各司其职。
在开发阶段:咱们需求 webpack-dev-server
来$ h b #帮咱们进行快速的开发,一起需求 HMR 热更新 帮咱们进行页面的无刷新改动,而这些在 出产环境 中都是不需求的。
在出产阶段:咱们需求进行 代码& s r 紧缩、目录清理、+ | }计算 hash、提取 CSS 等等;
完结起来很简略,咱们前面也提到过,就新建三个 webpack2 E
的装备文件就行:
-
webpack.dev.js
:开发环境的装备文件 -
webpack.prod.js
:出产环境的装备文件 -
webpack.common.js
:公p G R X q ~共装备文件
经过 webpack-merge
来整合两个装备文V L ~ p件共同的装备 webpack.commo- T gn.js
,详细能够参照源码。
削减查找进程
对 webpack
的 resol| , S % m ; Nve
参数进行合理装备,运用 resolve
字段告知 webpack
怎样去查找文件。
合理运用 resolve.extensionsR V 5
在导入语句没带文件后缀时,webpack
会主动带上后缀后去测验问询文件是否存在,查询的次序是依照咱们装备 的 resolveb ; w S ` P y.extensions
次序从前到后查找,webpack
默许支撑的后缀是 js
与 json
。
举个:假如咱们装备 resH s folve.extensions= ['js', 'json']
,那么 webpack
会先找 xxx.js
假如没有则再查找 xxx.json
,所以咱们应该把常用到的文件后缀写在前面,或许 咱们导入模块时,尽量带上文件后缀名。
虽然
extensi1 U , O d k h q jons
会s b +优先查找数组内的值,可是咱们不要一股脑儿的把一切后缀都往) $ / E c T y A |里边塞,这会调用多次文件的查找,这样就会减慢打包速度。
优化 resoL z / M +lv9 Z ^ le.modules
这个特G * D / 6 b X K点告知 webpack
解析模块时应该查找的目录,绝对途径和相对途径都能运用。运用绝对途径之后,将只在给定目录中查找,然后削减模块的查找层级:
// config/wF h a U o . d 6ebpac9 + V ; pk.common.js
// ...
const commonConfig = {
// ...
resolve: {
extensions: ['.js', '.jsx'],
mainFiles: [N b + ! r G u'index',! N o 9 ) { f V 'list'],
alias: {
alias: path.resolve(__2 D C `dirname, '../src/alias'),
},
modules: [
paQ 9 O g 3 6 q fth.resolve(__dirname, 'node_modules'), // 指定当时目录下的 node_modulez { A J + 2 is 优先查找
'node_modules', // 将默许写法放在后边
]
},
// ...
}
// ...
运用 resolve.alias
削减查找进程
alias
的意思为 别名,能把原导入途& I j Z P径映射成一个新的导入途径。
比方咱们项目中或许会有一些相对途径的写法,就能够运用 alias
装备来削减查找进程;
还比方咱们经常运用的 reactD g 8 M d 5 k
库,其实咱们能够直接运用其 dist
目录下打包好的 react.min.js
,这样就能越过耗时的模块解析,详细示例装备如下:
// config/webE m u F ;pack.common.js
// ...
const co[ = ) M 4 K # m wmmonCon9 O s j @ 5 . u !fig = {
// ...
resolve: {
// ...
alias: {
react: path.resolve(__dirname, './nodeW ( ^ L ? -_modules/react/dist/react.min.js')P / Z z r E,
@a6 . U a | slias: path.resolve(__dirname, '../src/alias'),
},
},
// ...
}
// ...
这个笔者在实践项目中没有测验过,不过也是一个思路,咱们有机会能够测验一波。
缩小构建目标
扫除 Web* 3 4 g d R -pack
不需求解析的模块,即运用 loader
的时分,在尽量少的模块中去运用 7。
咱们能够凭借 include
和 exS + 4clude
这两个参L i K a数,规则 loaK Z k , { + P 0 !der
只在那些模块运用和在哪些模块不运用。
咱们修正公共装备文件 webpack.common.js
:
// config/webpack.c0 A @ D Wommon.js
// ...
const commonConfig = {
// ..E % D.
module: {
rules: [V R p 8 R x
{
test: /.js|jsx$/,
exclA I ~ sude: /node_modules/,
include:Q v * n ! 2 ; m 4 path.resolve(__dirname, '../src'),
use: ['babel-loader']
},
// ...
]
},
}
// ...
首要咱们不加 exclude
和 include
两个参数,打包一下 npm run build
,打包时刻 3350ms
左右:
接着咱们加上这两个参数,意思别离是:
-
exJ 3 p 0 0 - . Y :clude: /node_module/ C r #s/
:扫除node_modules
下面的文件 -
incls ~ & #ude: patV _ W Y v # gh.resolve(__dirnam* h d n S d Z v )e, '../src')
:只对src
下面的文件运用
从头打包一下,打包时刻变成了 1400m7 u F W g = 3 9s
左右:
运用多线程进步构建速度
由于运转在 Node.js
之上的 webpack
是单线程模型的,所以 webpack
需求处理的事情需求一件一件的做,不能多件事一起做。
假如 webN 2 t d Z H n bpack
能同一时刻处理多个使命$ w F,发挥多核 CPU
电脑的威力,那么对其打包速度的进步必定是有很大的作用的。
HappyPack
原理:每次 webapck
解析一个模块,HappyPack
会将它及它的依靠分配给 worker
线程中。处理完v H { 4结之后,再将处理好的资源回来给 HappyPack
的主进程,然后加速打包速度。
在
webpack4.0
中运用happypack
需求运用其5.0
版别。
咱们将 HappyPa2 i k + @ I 9 $ 5ck
引进公共装备文件,他的用法便是将相应的 loader
替换成 happypack/loader
,一起将替换的 loader
放入其插件的 loaders
选项,咱们暂时替换一下 babel-loader
:
// config/webpack.common.js
// ...
const makePlugins = (configs) => {
const plugins = [
// ...
new HappyPack({
loaders: ['babel-loae N 0 t i + 8 der']
}),
];
// ...
returT } # 6 W % X Nn plugins;
}
// ...
const commonC: A 5 K 9onfig = {
entry: {
main: "./src/index.js",
entry2: ".: b c R/src/entry2.js",
entry3: "./src/entry3.js",
entry4: "./src/entry4.js",
entry5: "./src/entry5.js",
entry6: "./src/entry6.; ` ^ ; E [js",a z q ) 4 w E
},
// ...
module: {
rules: [{
test: /.jsx?$/,
// exclude: /node4 N ~ . O_modules/,
// iy T q tnclude: path.resolve(Q P 2__dirname, '../src'K 5 T k 9 a),
use: [
'happypack/lor t ? & , R ! Dader'
/? g s/ 'babel-loadern F G ] i k r c'
]
}]
},
// ...
}
// ...
为了让作用愈加显着y L X P一点,咱们在项目下多增加几个进口文件,在不运用 happypack
的情况下,进行一次打包,时刻差不多是 8s
多:
敞开 happypack
之后,咱们能够从操控台中看到,happypack
默许帮咱们敞开了 3
个进程,打包时刻变成了6.5s
左右:
注意:
HappyPack
的作者现在基本上也不保护这个插件了,由于作者对此项意图爱好正在减弱。他也引荐咱/ G , P w们运用webpack
官方 thread-loader。
更多参数咱们能够参阅 Happj V N G } eyPacR m t r i a ~k 官网
thread-loader
webpack
官方推出的一个多进程t # V +计划,用来代替 HappyPa[ T E L } , Y [ck
。
原理和 HappyPack
相似,webpack
每次解析一个模块,thread-loader
会将它及它的依靠分配给 worker
线程中,然后达到多进程打包的意图。
运用很简略! = E z I m |,, ! O M p ?直接在咱们运用的 l$ * Woader
之前加上 thread-loader
就行,咱们需求先注释掉 HappyPae Y 4 & z 0 . * ick
代码:
// config/web@ M X m $ M T cpack.common.js
// ...
const commonConl + k m P M xfig = {
// ...
module: {
rules: [{
test: /.jsx?$/,
// exclude: /node~ R c 5 v M = o_modules/,
// include: path.resolve(__dirnameB , 5 S o E Z !, '../src'. { h g |),
use: [
{
loader: 'thread-loader',
optionsP } %: {
w$ o ) ) } Uorkers: 3, // 敞开几个 worker 进程来处理打包,默许是q S b A os.cpus().length - 1
}
},
'babel-loader'
]
}]
}; { k ( / I,
// ...
}
// ...
咱们X O K Z 2 7 8从头运转一下,也是差不多 6.5s
左右:
预先编译资源模块(DllPlugin)
咱们在打包的时分,一般来说第三方+ – % ? ; M / ? 8模块是不会变化的,所以咱们想只要在第一次打包的时分去打包一下第三方模块,并将第三方模块打包到一个特定的文件中,当第2次 webpacko # Q 2 &
进行打包的时分,就不需求去 node_modules
中去引Q g H o f %进第三方模块,而是直接运用咱们第一次打包的第三方模块的文件就~ % K ` a &行。
webpack} A U.DllPlugin
便是来处理这个问题的插件,运用它能够在第一次编译打包后就生成一份不变的代码供其他模块引证,这样下一次构建的时分就能够节省开发时编译打包的时刻。
增加装备文件
咱们在装备文件目录 config
下新建一个 webpack.dll.js
,此文件用e b b F于将咱们的第三t V j (方包文件打包到 dll
文件夹中去:
// config9 7 n $ c D & i m/webpack.dll.js
const path = require('path');
const webpack = require('webpack');
module.exports = {
mode: 'production', /F g i z F k @ |/ 环境
entry: {
vendors: [m y w % q'lodash'], // 将 lodash 打包到 vendors.js 下
react: ['react', 'reT 3 N Gact-dom'], // 将 react 和 react-dom 打包到 react.js 下
},
output: {
filename: '[name].dll.j8 ; Ls', /u C ] B/ 输出的姓名
path: patY u F dh.resolve(__d A X u g Uirname, '../dll'), //d U 8 b ) C v D 输出的文件目录
library: '[name]' // 将咱们打包出来的文件以全部变量的办法暴露,能够在浏览器变量的姓名进行拜访
},| w [ d 5 3 [ |
plugins: [
// 对生成的V { c x i w库文件进行剖析,生成库文件与事务文件的映射联系,将成果放在 mainfest.json 文件中
new webpack.DllPlugin({
name: '[named I L k]', // 和上面的 liL E A . k 2brary 输出的姓名要相同
path: pathg v Q R Q ( 3 j L.resolve(__dirname, '../dll/[e , , b O | 7 v nname].manifest.json'),
})
]
}
- 上面的
library
的意思其实便是将dll
文件以一个全局变量的办法导出出去,便于接下来引证,如下图: -
mainfest.json
文件是一个映射联系,它的作用便是协助webpack
运用咱们之前打包好的***.D o S S l f _ 2 .dll.js
文件,而不是从头再去node_modules
中去寻找。
咱们在命令行中打包一下L 2 2 g o 8 ( dll
文件,能够@ X n 8 _ X o a看到根目录生成了一个 dll
文件夹,而且在下面生成了相应的文件,而且 loader
打包到了 vendor.dll.js
中,react
和 react-dom
打包到c P K & F / # j了 react.dll.js
中了:
接着咱们需求去修正公共装备文件 webpac= h ;k.common.js
,将咱们Q G q A S [之前生成的 dll
文件导入到 html
中去,假如咱们不想自己手动向 htmlA K w N
文件去增加 dll
文件的时分,咱们能P K n |够凭借一个插件 add-asset-html-webpack-plugin
,此插件望文生义,便是将一些文件加到 html
中去。
一起咱们需求运用 webpack
自带的 DllReferencePlugin
插件@ k 6 C * 8 R 5对 mainfest.json
映射文件进行剖析。
// config/webpack.common.j* f s [ H j fs
const webpack = require('webpack');
const AddAssetHtmlWa I ] aebpackPlugin = require('add-asset-html-webpack-plugin');
// ...
const commonConfig = {
// ...
plugins: [
// ...
new AddAssetHtmlWebpackPlugin({
filepath: path.resolveO c $ g w }(__dirname,v n N g N 2 ~ c '../dll/vendors.dll.js')
}),
new AddAssetHtmlWebpackPlugin({
filepath: path.resoD - lve(_= U R } % b U_dirname, '../dll/react.dlls v W z.js')
}),
new webpack.DllReferencePlugin({
manifest: require(path.rK & xesolve(__dirname, '../dll/vendors.dll.mainfest.json'))
}),
ne/ N O Ow webpack.DllReferencePlugin(r v h c A{
manifest:^ l w [ _ J ~ require(path.resolve(__dirname, '../dll/react.dll.mainfest.json'))
}),
],
// ...
}
// ...
这儿的代码还能够优化,详细咱们能够参阅笔者收拾的笔记中 dll优化 这一节。
咱们进行一次打包,能够看到打包耗时为 1450ms
左右,一起能够看到库文件打包到的 vendors.chunk.js
为 1.22MB
。
咱们注释* 3 h + ( A X c掉对 dll
的引证剖M W Y p r m 5 D析之后,从头打包,打包耗时为 1950ms
左右,一起能够看到 vendors.chunk.js
为 5.28MB
。
缓存 Cache 相关
咱们能够敞开相应 loader
或许 plugin
的缓存,来进步二次构建的速度。一般咱们能够经过下面几项来完结:
-
babel-loader
敞开缓存 -
terser-webpack-plugin
敞开缓存 - 运用
cache-loade / @ ` N Y Br
或许 hard-source-webpack-plugin
假如项目中有缓存的话,在 node_modules
下会有相应的 .cache
目录来存放相应的缓存。
babelt o 3-loaG O z z +der
首要咱们敞开 babel-loader
的缓存,咱们修正 babel-loader
的参数,将参数 cacheDirectory
设置为 true
:
// config/web# e n H # ) pack.common.js
// ...
module: {
rules: [
{
test: /.jsx?$/,
// exclude: /nodeC x [ Q d H t_mQ K R I F Podules/,
// include: path.resolve(__dirname, '../src'),
use: [
{
loader: 'babel-q L y gloader',
options: {
cacheDirectory: true,
}
},
]
},
]
}
// ...
初@ q l ! # M N次打y b + n x B P包时刻为 8.5s
左右,打包完结之后,咱们能够发现在 node_modules
下生成了一个 .cache
目录,0 l e G ` % K a r里边存放了 babel
的缓存文件:
咱们从头打包一次,会发现时刻变成了 6s
左右:
TerserPlugin
咱们经过将 TerserPlugin
中的 cache
设为 true
,就能够7 ~ h R C 1 o U I敞开缓存:
// config/webpack.common.js
const Te3 g T . vrserPlugin = require('terser-webpack-plugin');
// ...
const commG H Q D qonConfig =e % G # . {
// ./ 2 Q = X Q }..
optimization: {
minimize: true,
minimizer: [
new TerserPlugin(_ / R e j{
pa{ z ( #rallel: 4, // 敞开几个进程来处理紧缩. } G G,默许是 os.cpus().leZ z M G ) 7 2 7 kngth - 1
cache: true,
}),
],
},
// ...
}
初次打包时刻为 8-9s
左右,一起在 .cache
目录下生成了 terser-webpack-plugin
缓存目录:
咱们从头打包一次,会发现时刻变成了 5s
左右:
Har# ; B O 6 ( S K edSourceWebpackPlugin
这个插件其实便是用于给模块供给一个中间的缓存。
运用如下,咱们直接在插件中引进就C d z ? ow Ak 了:
// config/wI i V ! { / N N hebpack.common.js
const HardSourceWebpackPlugin = require('hard-source-webpam G [ / Jck-plugin');
// ...
const plugins = [
// ...
new HardSourceWebpaB x UckPlugin(),
];
// ...
咱们打包一下,能够看到在第一次打包的时V U Z E 0 $ J o T分 HardSoU z U I ! | 8 turceWebpackPlugin
就帮咱们开始生成打包文件了,一起在 .cache
目录生成了8 D ? H T k hard-source
目录,第一次打包耗时 6.6s
左右:
咱们从头打包一次,会发现时刻变成了 2_ ` _ K / c ! k v.7s
左右:
合理运用 sourceMap
之前咱们有讲过,之前咱们打包生成 sourceMap
的时分,假t e B +如信息越详细,打包速度就会越慢
所以咱们要在代码打包进程中的时分,在对应的环境运用对应的 sourceMap
很重要。
其他
除了上述咱们提到的一些常用办法,还有其他的一些办法,比方:
- 运用
ES6 Modules
语法,以保证Tree-Shaking
起作用
由于
tree-shaking
只对ES6 Modules
静态引进收效,关于相似于CommonJs
的动 u !态引P ^ s进办法是无效的
- 合理运用
Ployfill
假如咱们关于G } v K引进的
polyfill
不做处理的话,Webpack
会把一切的Polyfill
都加载进来,导致产出文件过大。引荐运用@babel/preset-en - d _ k : 8nv
的useBuiltIns='usage'
计划,此装备项会依据浏览器的兼容性协助咱们按需引进所需的垫片;此d S ` ` H X , K外咱们也能够运用动态polyfill
服务,每次依据浏览器的Userr L % . t I C * d Agent
,下发不同的$ 1 rPolyfill
,详细能够参阅polyfiV V 5 F g ! b y zll.io
。
- 预加载资源
webpack= a Y M M K |Prefetch
运用
webpackPrefetch
来提早预加载一些资源,意思便是 将来或许需求一些模块资源,在核心代码加载完结之后带宽闲暇的时分再n – 7 ) R ~ B g去加载需求用到的模块代码L S a v =。
-
icon
类图片运用css Sprite
来合并图片
假如
icon
类图片太多的话,就运用雪碧图合成一张图片,削减网络恳求,或许运用字体文件。
htm@ . v $ }l-webpack-externals-plugin
此插件能够将一些共用包提取出来运用
cdn
引进,不打入bundle
中,然后削减打包文件巨细,加速打包速# ] v 2 x ;度。
- 合理装备
chunk
的哈希值
在出产环境打包,一定要装备文件的
hash
,这样有助于浏览器缓存咱们的文件,当咱们的代码文件没变化的时分,用户就只需求读取浏览器缓存的文件即可。一般来说javascript
文件运用[chunkhashI { ! s F Z ) j u]
、css
文件运用[contenthash]
、其他资源(例如图片、字体等)运用[hash]
。
更多功能优化办法笔者就不再一一列举了,由于关于 webpack
功能优化的办法实在是太多了,咱们能够依据实践遇到的问题制定相关的优化计划。
小结
今日这篇文章介绍了 webpack
打包的一些优化计划,从项目体积再到对项目速度,咱们提出了一些优化计划,咱们能够在详细$ H } b t : } G h的项目中去进行实践。
当然我还要提一嘴,假如你的项目自身构建就比较快,那么U P , = 4 2 3你其实就不需求运用文章中提到z 3 d ! ; }的办法去对项f Z 1 l f 8 L目进行优化,或许作用会适得其反。
关于文章中有些一笔带过的内容,咱们能够在我的 webpack 学习收拾文档 找到相应的介绍。
实不相瞒,想要个赞!
相L X @ J O @关链接
- webpack 学习收拾文档
- webpack优化——将你的N C | h B . _ i构建效率提速K T 8 D + B N翻倍
- 带你深度解锁webpack系列(优化篇)
- webpack 构建功能优化战略小结
- 极客时刻 玩转we– 4 K * k Ybpack
- 三十分钟把握webpack功能优化
- 运用 webpack 定制前端开发环境
- webpack 官方打包东西
示例代码
示例代码能够看这儿:
- 功能优化 示例代码