added more information to example

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]
     }
   ]
 }
-```
+```

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}}
-```
+```