-
Notifications
You must be signed in to change notification settings - Fork 0
build performance.cn
Make sure you don't do a full rebuild. Webpack has a great caching layer that allows you to keep already compiled modules in memory. There are some tools that help to use it:
- webpack-dev-server: Serves all webpack assets from memory. Best performance.
- webpack-dev-middleware: The same performance as webpack-dev-server for advanced users.
-
webpack --watch or [[
watch: true| node.js API]]: Caches stuff but write assets to disk. Ok performance.
确保你不必全量重新构建。 Webpack拥有很强大的缓存层，让你在内存中维持已编译的模块。使其生效的一些协作工具：
- webpack-dev-server: 从内存提供所有webpack的资源。最佳的性能（译者注：大项目->内存怪兽）
-
webpack-dev-middleware: 与
webpack-dev-server同等的性能，高级用户专用。 -
webpack --watch or [[
watch: true| node.js API]]: 虽缓存数据但将资源写入磁盘。性能表现还可以。
With noParse you can exclude big libraries from parsing, but this can break stuff.
使用 noParse，解析时可以将大型的库排除在外。但可能破坏可用性。
There is an analyse tool which can perform a detailed analysis and provide useful information on how to optimize your build size and performance.
You can generate the required JSON file by running webpack --profile --json > stats.json
有个分析工具可以对构建进行详细分析并提供关于如何优化构建尺寸以及构建性能的有用信息。
你可以通过运行webpack --profile --json > stats.json生成所需的JSON文件
Generating the source file from internal representation is expensive. Each chunk is cached on it's own, but only if nothing changes in this chunk. Most chunks only depend on the included modules, but the entry chunk is also considered as dirty if the additional chunk name changes. So by using [hash] or [chunkhash] in filenames the entry chunks need to be regenerated on (nearly) every change.
By using HMR the entry chunk need to embed the hash of the compilation and is also considered as dirty on every compilation.
从编译器的内部表示来生成源文件是性能昂贵的。每个打包块都是自我缓存的，当且仅当这个块本身没有变动。大部分的打包块只依赖于包含的模块。但如果依赖的打包块名称改变，入口打包块会被视为脏的（译者注：即需重新构建）。所以一旦文件名中使用了[hash] 或 [chunkhash]，几乎出现任何变动都会导致入口打包块被重新生成。
如果使用HMR，入口打包块需要嵌入一次编译的哈希值，因而也是在每次编译被视为脏的
Perfect SourceMaps are slow. 完美的SourceMaps是缓慢的
devtool: "source-map" cannot cache SourceMaps for modules and need to regenerate complete SourceMap for the chunk. It's something for production.
devtool: "eval-source-map" is really as good as devtool: "source-map", but can cache SourceMaps for modules. It's much faster for rebuilds.
devtool: "eval-cheap-module-source-map" offers SourceMaps that only maps lines (no column mappings) and are much faster.
devtool: "eval-cheap-source-map" is similar but doesn't generate SourceMaps for modules (i.e., jsx to js mappings).
devtool: "eval" has the best performance, but it only maps to compiled source code per module. In many cases this is good enough. (Hint: combine it with output.pathinfo: true.)
devtool: "source-map" 不能为模块缓存SourceMaps，需要为打包块重新生成完整SourceMap。一般用于产品发布阶段。
devtool: "eval-source-map" 跟 devtool: "source-map"一样缓慢, 但可以缓存模块的SourceMaps。对于重建，速度更快。
devtool: "eval-cheap-module-source-map" 提供只映射行的SourceMaps（没有列映射）和速度更快。
devtool: "eval-cheap-source-map" 与上类同，但不为模块生成 SourceMaps(i.e., jsx 到 js 的映射).
devtool: "eval" 具有最佳性能，但它只是映射到每个模块的编译后源码。在许多情况下，这是足够好。 (提示: 结合 output.pathinfo: true 使用)
The UglifyJsPlugin uses SourceMaps to map errors to source code. And SourceMaps are slow. As you should only use this in production, this is fine. If your production build is really slow (or doesn't finish at all) you can disable it with new UglifyJsPlugin({ sourceMap: false }).
UglifyJsPlugin使用SourceMaps，映射压缩时错误到源代码。而SourceMaps是缓慢的。正如你应该只在生产中使用这功能，这是应该的。如果你的发布构建是真的慢（或根本没有完成）可以用new UglifyJsPlugin({ sourceMap: false })禁用它。
Only use resolve.modulesDirectories for nested paths. Most paths should use resolve.root. This can give significant performance gains. See also this discussion.
仅对嵌套路径使用 resolve.modulesDirectories . 绝大部分路径应该使用 resolve.root. 这可以获得 显著的性能提升. 另参见 this discussion.
Only use optimization plugins in production builds.
只在产品发布构建时使用优化插件
If you have a bunch of rarely changing modules (i. e. vendor libs) and chunking doesn't give you enough performance (CommonsChunkPlugin), there are two plugins to create a bundle of these modules in a separate build step while still referencing these modules from the app bundle.
如果你有一堆很少更改模块（即vendor libs），并分块给不了你足够的性能（CommonsChunkPlugin），有两个插件用来在单独构建步骤中创建这些模块的打包，同时app bundle主应用包中还引用着这些模块。
To create the DLL bundle beforehand you need to use the DllPlugin. Here is an example. This emits a public bundle and a private manifest file.
要预先创建DLL包你需要使用DllPlugin。下面是一个示例。这会产生一个public bundle公共包[此处翻译不顺！]和私有打包清单。
To use the DLL bundle from the app bundle you need to use the DllReferencePlugin. Here is an example. This stops following the dependency graph of your app when a module from the DLL bundle is found.
要想在主应用包中使用DLL包，你需要使用DllReferencePlugin。下面是一个示例。当一个模块在DLL包中被找到时，这会阻止遵循你主应用的依赖关系图