Webpack构建性能优化指南

本指南翻译自webpack官方性能指南文档:https://webpack.js.org/guides/build-performance/

构建性能

本指南涵盖了对增进构建或编译性能的一些有效的提示。


General

以下提示对开发环境或者生产环境都有效。

Stay Up to Date

保持最新的webpack版本。我们总是在改进webpack的性能。目前最新的webpack版本为:v4.41.4
使用最新的Node.js也可以提升性能。同样的,保持npm或者yarn这样的包管理器的版本也同样可以提升性能。新版本拥有更高效的模块树与更快的解析速度。

Loaders

对需要的模块采用对应Loader,例如:

module.exports = {
  //...
  module: {
    rules: [
      {
        test: /\.js$/,
        include: path.resolve(__dirname, 'src'),
        loader: 'babel-loader',
      },
    ],
  },
};

以上示例通过include属性圈定了babel-loader的作用范围,如果不使用该属性,则babel-loader将会对所有的js文件作业。

Bootstrap

每一个额外的Loader或者插件都会消耗一定的启动时间,尝试使用尽可能少的工具。

Resolving

以下几点可以提升解析速度:

  • 降低resolve.modules、resolve.extensions、resolve.mainFiles、resolve.descriptionFiles这些选项中item的数量,因为它们会导致更频繁的IO。
  • 如果不使用symlinks(例如npm link或yarn link),那么将resolve.symlinks设为false。
  • 如果使用了自定义的插件,则将resolve.cacheWithContext设置为false。

Dlls

使用DllPlugin插件将不常变更的代码进行单独编译。尽管这会增加构建的复杂度,但会提高应用的编译速度。

Smaller = Faster

降低被编译文件的体积同样可以提升构建性能。想办法使chunk更小。

  • 使用体积更小/熟练更少的库。
  • 在多页应用中使用SplitChunksPlugin插件。
  • 在多页应用中的async模式下使用SplitChunksPlugin插件。
  • 移除未被使用的代码。
  • 只编译当前你正在开发的代码。

Worker Pool

thread-loader可将开销昂贵的loader转移至线程池执行。不过不能使用太多的线程,这对node.js运行时来说引发过载。另外也要降低线程与主进程模块之间的信息传输,因为IPC是昂贵的。

Persistent cache

通过cache-loader开启持续缓存的能力。

Custom plugins/loaders

对于自定义的插件与loader,请自行分析优化性能。

Progress plugin

移除ProgressPlugin可能会缩短少许的构建时间。但是要记住,这并不会带来可观的构建速度优化,所以在移除该插件之前要平衡好取舍。

Development

以下优化手段在开发环境是尤其有效的。

Incremental Builds

使用webpack的watch模式,别使用其它工具来监听文件的变化再来调用webpack。webpack内建的watch模式会保留时间戳的信息并将该信息给到编译器以使缓存失效。

在一些设置中,监听是靠轮询来完成的。随着监听文件数量的增多,这会增加大量CPU的计算量。在这种情况下,可以通过watchOptions.poll来增加轮询间隔。

Compile in Memory

以下工具通过内存编译以及内存伺服的方式提升了性能,可以尝试使用:

  • webpack-dev-server
  • webpack-hot-middleware
  • webpack-dev-middleware

stats.toJson speed

webpack4默认情况下会通过stats.toJson()输出大量数据。除非在增量步骤中是必须的,否则避免检索stats对象。webpack-dev-server在v3.1.3之后的版本针对于这一问题做了大量的性能方面的优化。

Devtool

不同的devtool设置所引起的性能是不同的,要有这个意识。

  • "eval"拥有最好的性能,不过它不会保留源代码。
  • "cheap-source-map"带来的性能损耗还可以,它会有一些性能损耗。
  • "eval-source-map"用来增量构建。
    在大多数情况下,cheap-module-eval-source-map是最适中的方案。

Avoid Production Specific Tooling

确保工具、插件、loader只是用于生产环境而不是开发环境,否则会带来不需要的资源开销。例如,在开发环境下通常不需要对代码做混淆与压缩,比如使用TerserPlugin来实现这个能力,开发环境下是不需要的。下面这些工具在开发环境下一般都是需要被摘出来的:

  • TerserPlugin
  • ExtractTextPlugin
  • [hash]/[chunkhash]
  • AggressiveSplittingPlugin
  • ModuleConcatenationPlugin

Minimal Entry Chunk

WebPack仅向文件系统发送更新的chunks。对于一些配置选项,(例如:HMR,[name]/[chunkhash]inOutput.chunkfilename,[hash])除更改的chunks外,入口chunk是无效的。

使入口chunk保持小的体量才能使更新的成本更低。下面的代码块会抽取一个包含仅仅是在运行时包含其它子块的chunk:

new CommonsChunkPlugin({
  name: 'manifest',
  minChunks: Infinity,
});

Avoid Extra Optimization Steps

webpack会进行额外的逻辑运算工作来优化输出代码的体量与加载性能。下面优化选项对于小型的项目代码来说是有效的,不过对于大型项目来说那就不太适用了:

module.exports = {
  // ...
  optimization: {
    removeAvailableModules: false,
    removeEmptyChunks: false,
    splitChunks: false,
  },
};

Output Without Path Info

webpack有能力在输出的Bundle中携带路径信息。然而,在有上千个组件的项目中会导致垃圾收集器的压力。可使用以下选项将这个功能关闭:

module.exports = {
  // ...
  output: {
    pathinfo: false,
  },
};

Node.js Versions 8.9.10-9.11.1

在Node.js 8.9.10 ~ 9.11.1的版本区间内,Map和Set的实现在性能方面表现很差,所以这影响到了webpack的编译时间。在这之前与之后的版本都没有受到影响,所以要避免使用这个版本内的Node.js。

#Production
以下优化选项尤其适用于生产环境

Multiple Compilations

当使用多重编译时,下面这些工具可能会帮到你:

  • parallel-webpack 可以在线程池中完成编译。
  • cache-loader 缓存可在多次编译中共享。

Source Maps

SourceMap是非常昂贵的,你真的需要它吗?

一些工具的问题

下面这些工具含有一些问题,这些问题会导致性能上有一些影响:

Babel

  • 降低preset/plugin的数量。

TypeScript

  • 在单独的进程中使用fork-ts-checker-webpack-plugin用于类型检查。
  • 配置loader跳过类型检查。
  • 在happyPackMode: true或transpileOnly: true中使用ts-loader。

Sass

  • node-sass有一个Bug,这个bug会阻断Node.js线程池中的线程。当通过thread-loader使用它时,请将workerParallelJobs设置为2。
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页