From 7d7a16ffd2ad6987fe8b704336a09dc28d93ea04 Mon Sep 17 00:00:00 2001 From: Tobias Koppers Date: Wed, 13 Jul 2016 11:35:47 +0200 Subject: [PATCH] added more information to example --- examples/http2-aggressive-splitting/README.md | 51 +++++++++++++++++-- .../http2-aggressive-splitting/template.md | 24 ++++++++- 2 files changed, 69 insertions(+), 6 deletions(-) diff --git a/examples/http2-aggressive-splitting/README.md b/examples/http2-aggressive-splitting/README.md index 8477e1e1f0d..2da88021240 100644 --- a/examples/http2-aggressive-splitting/README.md +++ b/examples/http2-aggressive-splitting/README.md @@ -1,11 +1,52 @@ +This example demonstrates the AggressiveSplittingPlugin for splitting the bundle into multiple smaller chunks to improve caching. This works best with a HTTP2 web server elsewise there is an overhead for the increased number of requests. + +The AggressiveSplittingPlugin split every chunk until it reaches the specified `maxSize`. In this example it tries to create chunks with <50kB code (after minimizing this reduces to ~10kB). It groups modules together by folder structure. We assume modules in the same folder as similar likely to change and minimize and gzip good together. + +The AggressiveSplittingPlugin records it's splitting in the webpack records and try to restore splitting from records. This ensures that after changes to the application old splittings (and chunks) are reused. They are probably already in the clients cache. Therefore it's heavily recommended to use records! + +Only chunks which are bigger than the specified `minSize` are stored into the records. This ensures that these chunks fill up as your application grows, instead of creating too many chunks for every change. + +Chunks can get invalid if a module changes. Modules from invalid chunks go back into the module pool and new chunks are created from all modules in the pool. + +There is a tradeoff here: + +The caching improves with smaller `maxSize`, as chunks change less often and can be reused more often after an update. + +The compression improves with bigger `maxSize`, as gzip works better for bigger files. It's more likely to find duplicate strings, etc. + +The backward compatibility (non HTTP2 client) improves with bigger `maxSize`, as the number of requests decreases. + +``` js +var path = require("path"); +var webpack = require("../../"); +module.exports = { + entry: "./example", + output: { + path: path.join(__dirname, "js"), + filename: "[chunkhash].js", + chunkFilename: "[chunkhash].js" + }, + plugins: [ + new webpack.optimize.AggressiveSplittingPlugin({ + minSize: 30000, + maxSize: 50000 + }), + new webpack.DefinePlugin({ + "process.env.NODE_ENV": JSON.stringify("production") + }) + ], + recordsOutputPath: path.join(__dirname, "js", "records.json") +}; +``` + # Info ## Uncompressed ``` Hash: db9e88642ccb12a1264f -Version: webpack 2.1.0-beta.15 -Time: 1010ms +Version: webpack 2.1.0-beta.16 +Time: 1044ms Asset Size Chunks Chunk Names 8fcb4106a762189b462e.js 52.9 kB 7 [emitted] 42f9c68ce2db0b310159.js 55.7 kB 0 [emitted] @@ -217,8 +258,8 @@ chunk {13} c3adbf94e7e39acf7373.js 33.1 kB [initial] [rendered] ``` Hash: db9e88642ccb12a1264f -Version: webpack 2.1.0-beta.15 -Time: 2561ms +Version: webpack 2.1.0-beta.16 +Time: 2704ms Asset Size Chunks Chunk Names 8fcb4106a762189b462e.js 11.2 kB 7 [emitted] 42f9c68ce2db0b310159.js 10.4 kB 0 [emitted] @@ -840,4 +881,4 @@ chunk {13} c3adbf94e7e39acf7373.js 33.1 kB [initial] [rendered] } ] } -``` \ No newline at end of file +``` diff --git a/examples/http2-aggressive-splitting/template.md b/examples/http2-aggressive-splitting/template.md index 75ad6b50553..c599d5837d3 100644 --- a/examples/http2-aggressive-splitting/template.md +++ b/examples/http2-aggressive-splitting/template.md @@ -1,3 +1,25 @@ +This example demonstrates the AggressiveSplittingPlugin for splitting the bundle into multiple smaller chunks to improve caching. This works best with a HTTP2 web server elsewise there is an overhead for the increased number of requests. + +The AggressiveSplittingPlugin split every chunk until it reaches the specified `maxSize`. In this example it tries to create chunks with <50kB code (after minimizing this reduces to ~10kB). It groups modules together by folder structure. We assume modules in the same folder as similar likely to change and minimize and gzip good together. + +The AggressiveSplittingPlugin records it's splitting in the webpack records and try to restore splitting from records. This ensures that after changes to the application old splittings (and chunks) are reused. They are probably already in the clients cache. Therefore it's heavily recommended to use records! + +Only chunks which are bigger than the specified `minSize` are stored into the records. This ensures that these chunks fill up as your application grows, instead of creating too many chunks for every change. + +Chunks can get invalid if a module changes. Modules from invalid chunks go back into the module pool and new chunks are created from all modules in the pool. + +There is a tradeoff here: + +The caching improves with smaller `maxSize`, as chunks change less often and can be reused more often after an update. + +The compression improves with bigger `maxSize`, as gzip works better for bigger files. It's more likely to find duplicate strings, etc. + +The backward compatibility (non HTTP2 client) improves with bigger `maxSize`, as the number of requests decreases. + +``` js +{{webpack.config.js}} +``` + # Info ## Uncompressed @@ -16,4 +38,4 @@ ``` {{js/records.json}} -``` \ No newline at end of file +```