构建性能 |
您所在的位置:网站首页 › webpack配置文件中的配置选项有 › 构建性能 |
本指南包含一些改进构建/编译性能的实用技巧。 通用环境无论是在 开发环境 还是在 生产环境 下运行构建脚本,以下最佳实践都会有所帮助。 更新到最新版本使用最新的 webpack 版本。我们会一直坚持进行性能优化。webpack 的最新稳定版本是: 将 Node.js 与 package 管理工具(例如 npm 或者 yarn)更新到最新版本均有助于提高性能。较新的版本能够建立更高效的模块树并提高解析速度。 loader将 loader 应用于最少数量的必要模块。反例: module.exports = { //... module: { rules: [ { test: /\.js$/, loader: 'babel-loader', }, ], }, };使用 include 字段将 loader 应用在实际需要将其转换的模块: const path = require('path'); module.exports = { //... module: { rules: [ { test: /\.js$/, include: path.resolve(__dirname, 'src'), loader: 'babel-loader', }, ], }, };引导(bootstrap)每个额外的 loader/plugin 都有其启动时间。尽量少地使用工具。 解析以下步骤可以提高解析速度: 减少 resolve.modules, resolve.extensions, resolve.mainFiles, resolve.descriptionFiles 中条目数量,因为他们会增加文件系统调用的次数。如果不使用 symlinks(例如 npm link 或者 yarn link),可以设置 resolve.symlinks: false。如果使用自定义解析插件规则,并且没有指定上下文,可以设置 resolve.cacheWithContext: false。dll使用 DllPlugin 为更改不频繁的代码生成单独的编译结果。尽管这增加了构建过程的复杂度,但是可以提高应用程序的编译速度。 小即是快减少编译结果的整体大小以提高构建性能。尽量保持 chunk 体积小。 使用数量更少/体积更小的库在多页面应用程序中使用 SplitChunksPlugin。在多页面应用程序中使用 SplitChunksPlugin,并开启 async 模式。移除未使用的代码。只编译当前正在开发的那些代码。worker 池thread-loader 可以将非常消耗资源的 loader 分流给 worker 池。 警告由于 Node.js 运行时与 loader 都有启动开销,尽量不要使用太多 worker,尝试最小化 worker 与主进程之间的模块传输。进程间通讯非常消耗资源。 持久化缓存在 webpack 配置中使用 cache 选项。使用 package.json 中的 "postinstall" 清除缓存目录。 提示我们支持使用 yarn PnP v3 yarn 2 berry 进行持久缓存。 自定义 plugin/loader请在使用自定义 plugin/loader 前对其进行概要分析以免在此处引入性能问题。 Progress 插件将 ProgressPlugin 从 webpack 中删除可以缩短构建时间。请注意,ProgressPlugin 可能不会为快速构建提供太多价值,因此请权衡利弊再使用。 开发环境以下步骤在开发环境中特别有帮助。 增量编译使用 webpack 的观察模式,而非使用其他工具观察文件、调用 webpack。内置的观察模式会记录时间戳并将此信息传递给编译以使缓存失效。 在某些配置环境中,观察模式会回退到轮询模式。监听过量文件会导致 CPU 大量负载。此时可以使用 watchOptions.poll 增加轮询的间隔时间。 在内存中编译使用下面几个工具实现在内存中(而不是写入磁盘)编译并部署可访问资源以提高性能: webpack-dev-serverwebpack-hot-middlewarewebpack-dev-middleware加速 stats.toJsonwebpack 4 默认使用 stats.toJson() 输出大量数据。但是除非在增量步骤中做必要的统计,否则请避免获取 stats 对象的部分内容。webpack-dev-server 在 v3.1.3 以后的版本,包含一个重要的性能修复,即最小化每个增量构建步骤中会从 stats 对象获取的数据量。 devtool不同的 devtool 设置会导致性能差异。 "eval" 具有最好的性能,但并不能帮助转译代码。如果能接受稍差一些的映射质量,可以使用 cheap-source-map 变体配置提高性能。使用 eval-source-map 变体配置进行增量编译。提示在大多数情况下,最佳选择是 eval-cheap-module-source-map。 避免使用在生产环境下才会用到的工具某些工具、插件与 loader 都只用于生产环境。例如,在开发环境下使用 TerserPlugin 压缩和破坏代码是没有意义的。通常应该在开发环境下排除以下工具: TerserPlugin[fullhash]/[chunkhash]/[contenthash]AggressiveSplittingPluginAggressiveMergingPluginModuleConcatenationPlugin最小化入口 chunkwebpack 只会在文件系统中输出已经更新的 chunk。对于某些配置选项(HMR, output.chunkFilename 中的 [name]/[chunkhash]/[contenthash],[fullhash])而言,除了已更新的 chunk 之外,入口 chunk 也会失效。 尽量在生成入口 chunk 时减小其体积以提高性能。下面的配置为运行时代码创建了一个额外的 chunk,所以它的生成代价较低: module.exports = { // ... optimization: { runtimeChunk: true, }, };避免额外的优化步骤webpack 通过执行额外的算法任务优化输出结果的体积和加载的性能。这些优化适用于小型代码库,但是在大型代码库中却非常耗费性能: module.exports = { // ... optimization: { removeAvailableModules: false, removeEmptyChunks: false, splitChunks: false, }, };输出结果不携带路径信息webpack 会在输出的 bundle 中生成路径信息。然而,在打包数千个模块的项目中,这会带来垃圾回收性能的压力。在 options.output.pathinfo 设置中关闭它: module.exports = { // ... output: { pathinfo: false, }, };Node.js 版本 8.9.10-9.11.1Node.js v8.9.10 - v9.11.1 中的 ES2015 Map 和 Set 实现,存在 性能回退。webpack 大量地使用这些数据结构,因此这些回退也会影响编译时间。 之前和之后的 Node.js 版本不受影响。 TypeScript loader向 loader 传入 transpileOnly 选项,以缩短使用 ts-loader 时的构建时间。使用此选项会关闭类型检查。如果要再次开启类型检查,请使用 ForkTsCheckerWebpackPlugin。使用此插件会将检查过程移至单独的进程,这样可以加快 TypeScript 的类型检查和 ESLint 插入的速度。 module.exports = { // ... test: /\.tsx?$/, use: [ { loader: 'ts-loader', options: { transpileOnly: true, }, }, ], };提示这是一个关于 ts-loader 完整示例 的 GitHub 仓库。 生产环境以下步骤在生产环境中特别有帮助。 警告不要为了很小的性能收益,牺牲应用程序的质量!注意,在大多数情况下,优化代码质量比构建性能更重要。 source mapsource map 相当消耗资源,请确保真的需要它们。 工具相关问题下列工具存在某些可能会降低构建性能的问题: babel最小化项目中的 preset/plugin 数量。TypeScript在单独的进程中使用 fork-ts-checker-webpack-plugin 进行类型检查。配置 loader 跳过类型检查。使用 ts-loader 时,设置 happyPackMode: true 或 transpileOnly: true。sassnode-sass 中存在 bug,会阻塞 Node.js 线程池中的线程。当使用 thread-loader 时,需要设置 workerParallelJobs: 2。 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |