You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/plugins/split-chunks-plugin.md
+32-22Lines changed: 32 additions & 22 deletions
Original file line number
Diff line number
Diff line change
@@ -30,10 +30,10 @@ By default it only affects on-demand chunks, because changing initial chunks wou
30
30
31
31
webpack will automatically split chunks based on these conditions:
32
32
33
-
* New chunk can be shared OR modules are from the `node_modules` folder
34
-
* New chunk would be bigger than 30kb (before min+gz)
35
-
* Maximum number of parallel requests when loading chunks on demand would be lower or equal to 5
36
-
* Maximum number of parallel requests at initial page load would be lower or equal to 3
33
+
- New chunk can be shared OR modules are from the `node_modules` folder
34
+
- New chunk would be bigger than 30kb (before min+gz)
35
+
- Maximum number of parallel requests when loading chunks on demand would be lower or equal to 5
36
+
- Maximum number of parallel requests at initial page load would be lower or equal to 3
37
37
38
38
When trying to fulfill the last two conditions, bigger chunks are preferred.
39
39
@@ -47,6 +47,8 @@ W> The default configuration was chosen to fit web performance best practices, b
47
47
48
48
This configuration object represents the default behavior of the `SplitChunksPlugin`.
49
49
50
+
__webpack.config.js__
51
+
50
52
```js
51
53
module.exports= {
52
54
//...
@@ -85,10 +87,12 @@ By default webpack will generate names using origin and name of the chunk (e.g.
85
87
86
88
### `splitChunks.chunks`
87
89
88
-
`function``string`
90
+
`function | string`
89
91
90
92
This indicates which chunks will be selected for optimization. When a string is provided, valid values are `all`, `async`, and `initial`. Providing `all` can be particularly powerful, because it means that chunks can be shared even between async and non-async chunks.
91
93
94
+
__webpack.config.js__
95
+
92
96
```js
93
97
module.exports= {
94
98
//...
@@ -158,10 +162,12 @@ T> `maxSize` takes higher priority than `maxInitialRequest/maxAsyncRequests`. Ac
158
162
159
163
### `splitChunks.name`
160
164
161
-
`boolean: true``function``string`
165
+
`boolean: true | function | string`
162
166
163
167
The name of the split chunk. Providing `true` will automatically generate a name based on chunks and cache group key. Providing a string or function will allow you to use a custom name. If the name matches an entry point name, the entry point will be removed.
164
168
169
+
__webpack.config.js__
170
+
165
171
```js
166
172
module.exports= {
167
173
//...
@@ -182,6 +188,8 @@ W> When assigning equal names to different split chunks, all vendor modules are
182
188
183
189
Cache groups can inherit and/or override any options from `splitChunks.*`; but `test`, `priority` and `reuseExistingChunk` can only be configured on cache group level. To disable any of the default cache groups, set them to `false`.
184
190
191
+
__webpack.config.js__
192
+
185
193
```js
186
194
module.exports= {
187
195
//...
@@ -207,6 +215,8 @@ A module can belong to multiple cache groups. The optimization will prefer the c
207
215
208
216
If the current chunk contains modules already split out from the main bundle, it will be reused instead of a new one being generated. This can impact the resulting file name of the chunk.
209
217
218
+
__webpack.config.js__
219
+
210
220
```js
211
221
module.exports= {
212
222
//...
@@ -222,22 +232,24 @@ module.exports = {
222
232
};
223
233
```
224
234
225
-
#### `splitChunks.cacheGroups.test`
235
+
#### `splitChunks.cacheGroups.{cacheGroup}.test`
226
236
227
-
`function``RegExp``string`
237
+
`function | RegExp | string`
228
238
229
239
Controls which modules are selected by this cache group. Omitting it selects all modules. It can match the absolute module resource path or chunk names. When a chunk name is matched, all modules in the chunk are selected.
230
240
241
+
__webpack.config.js__
242
+
231
243
```js
232
244
module.exports= {
233
245
//...
234
246
optimization: {
235
247
splitChunks: {
236
248
cacheGroups: {
237
249
vendors: {
238
-
test (chunks) {
250
+
test (module, chunks) {
239
251
//...
240
-
returntrue;
252
+
returnmodule.type==='javascript/auto';
241
253
}
242
254
}
243
255
}
@@ -263,14 +275,14 @@ import 'react';
263
275
//...
264
276
```
265
277
266
-
**Result:** A separate chunk would be created containing `react`. At the import call this chunk is loaded in parallel to the original chunk containing `./a`.
278
+
__Result:__ A separate chunk would be created containing `react`. At the import call this chunk is loaded in parallel to the original chunk containing `./a`.
267
279
268
280
Why:
269
281
270
-
* Condition 1: The chunk contains modules from `node_modules`
271
-
* Condition 2: `react` is bigger than 30kb
272
-
* Condition 3: Number of parallel requests at the import call is 2
273
-
* Condition 4: Doesn't affect request at initial page load
282
+
- Condition 1: The chunk contains modules from `node_modules`
283
+
- Condition 2: `react` is bigger than 30kb
284
+
- Condition 3: Number of parallel requests at the import call is 2
285
+
- Condition 4: Doesn't affect request at initial page load
274
286
275
287
What's the reasoning behind this? `react` probably won't change as often as your application code. By moving it into a separate chunk this chunk can be cached separately from your app code (assuming you are using chunkhash, records, Cache-Control or other long term cache approach).
276
288
@@ -299,14 +311,14 @@ import './more-helpers'; // more-helpers is also 40kb in size
299
311
//...
300
312
```
301
313
302
-
**Result:** A separate chunk would be created containing `./helpers` and all dependencies of it. At the import calls this chunk is loaded in parallel to the original chunks.
314
+
__Result:__ A separate chunk would be created containing `./helpers` and all dependencies of it. At the import calls this chunk is loaded in parallel to the original chunks.
303
315
304
316
Why:
305
317
306
-
* Condition 1: The chunk is shared between both import calls
307
-
* Condition 2: `helpers` is bigger than 30kb
308
-
* Condition 3: Number of parallel requests at the import calls is 2
309
-
* Condition 4: Doesn't affect request at initial page load
318
+
- Condition 1: The chunk is shared between both import calls
319
+
- Condition 2: `helpers` is bigger than 30kb
320
+
- Condition 3: Number of parallel requests at the import calls is 2
321
+
- Condition 4: Doesn't affect request at initial page load
310
322
311
323
Putting the content of `helpers` into each chunk will result into its code being downloaded twice. By using a separate chunk this will only happen once. We pay the cost of an additional request, which could be considered a tradeoff. That's why there is a minimum size of 30kb.
312
324
@@ -316,7 +328,6 @@ Create a `commons` chunk, which includes all code shared between entry points.
316
328
317
329
__webpack.config.js__
318
330
319
-
320
331
```js
321
332
module.exports= {
322
333
//...
@@ -342,7 +353,6 @@ Create a `vendors` chunk, which includes all code from `node_modules` in the who
0 commit comments