在我工作的地方（在启动
Spot.IM中 ，它的大小在中小型之间），Webpack用于构建各种项目。 在对我们的主要产品进行了4年的努力之后，当有太多人为它的代码做出贡献而无法计算时，其初始组装时间达到了90秒，而重新组装的时间达到了14。
每次单击“保存”按钮后，大约需要等待14秒。
借助一些简单的优化（例如任何人都可以在他们的项目中应用），我们能够将上述数字减少到20秒（组装）和1秒（重建项目）。
在本文中，我想谈谈一些简单的更改，使项目可以大大缩短其组装时间。 请注意，如果您使用
CreateReactApp （或其他一些流行的应用程序生成器），那么本文可能对您并不是特别有用。 但是，如果您不使用任何类似方法，那么此处所讨论的内容可能对您非常有用。
测量构建项目所花费的时间
在进行任何类型的优化之前，让我们建立一个指标度量标准，通过它我们可以判断工作结果。 为此，请使用包
speed-measure-webpack-plugin （SMP）：
const webpackConfig = require('./webpack.config') const SpeedMeasurePlugin = require('speed-measure-webpack-plugin') const smp = new SpeedMeasurePlugin({ disable: !process.env.MEASURE, }) module.exports = smp.wrap(webpackConfig)
我们将Webpack配置文件放入SMP包装器中（启动使用环境变量进行性能测量的机制），然后传递Webpack配置对象。 之后，我们可以使用一份令人愉悦的报告，该报告使我们能够了解构建过程中每个引导加载程序完成所需的时间。 使用SMP，我们可以获得双重好处。 首先，在进行了一定的改进之后，我们可以立即了解它如何影响项目的构建时间。 其次，我们可以立即获得一份完整的报告，以了解每个引导加载程序所花费的时间（或更准确地说，是“引导加载程序链”）。
使用speed-measure-webpack-plugin生成的报告缩短项目的初始构建时间
在开始使用SMP之后，我们获得了有关在改进构建过程时项目的构建时间如何变化的信息。 我们开始优化的第一件事是初始构建时间（即Webpack在初始化之后构建软件包所花费的时间）。 为了加快初始构建过程，我们决定使用
cache-loader bootloader。
Cache-loader是一种加载程序，它会将其后的加载程序的工作结果缓存并保存到磁盘（或数据库）中。 这意味着下次启动Webpack时，可以看到构建速度有了显着提高，或者至少可以希望如此。
这是一个例子：
{ rules: [ { test: /\.jsx?$/, use: [ 'cache-loader', 'babel-loader', ], }, { test: /\.scss$/, use: [ 'style-loader', 'cache-loader', 'css-loader', 'postcss-loader', 'sass-loader', ], }, ] }
在
css-loader （对于CSS）之前和
babel-loader （对于JS）之前添加
cache-loader ，可以使我们从项目的初始构建时间中节省大约75秒。
现在让我们开始重新组装。 我们将尝试通过更改
devtool属性来改善这一时间。
Webpack代码卡
在Webpack设置中，您可以找到
devtool属性，根据文档所述，该属性“使您可以选择创建用于改进调试功能的代码卡的样式。 设定点会极大地影响组装和重新组装的速度。”
换句话说，修改
devtool属性会影响在构建项目后开发人员可以使用哪个代码卡。 而这又取决于创建这种代码卡所花费的时间。
具有此属性的实验来自于现场，可以永久改变程序员的寿命。 这对项目的构建速度有很大的影响。 也就是说，我们将
devtool值从
source-map （可能是最慢的模式）更改为
eval-source-map并且能够将项目重组时间从14秒减少到3.5秒：
{ devtool: process.env.NODE_ENV === 'development' ? 'eval-source-map' : 'source-map' }
devtool属性可以接受12个值的变体。 例如，CreateReactApp使用
cheap-module-source-map 。 因此，如果要配置此属性，请进行实验并找到最适合您的值。
应当注意，当使用快速方法来创建代码卡时，所得到的卡的质量会下降。 通过启动调试可以感觉到这些恶化。 幸运的是，现代浏览器紧随TC39。 结果（至少在开发过程中）真正不需要大量代码的转译。 如果配置Babel以便此工具将JavaScript传输到浏览器的最新版本可以理解的水平（如
CRA中所做的那样），则使用代码调试一切都应该没问题，因为代码映射与代码本身不会有太大差异。
如果您决定将代码转置为各种浏览器的最新版本都清楚的状态，则
babel.config.js外观应如下所示：
module.exports = { presets: [ [ '@babel/preset-env', { targets: [ 'last 1 chrome version', 'last 1 safari version', 'last 1 firefox version', ].join(', '), }, ], ], // ... }
仅此而已。 三个简单的步骤，大大减少了我们项目的构建时间。
我想指出，一个开始解决类似问题的人可能希望首先阅读Webpack文档并正确阅读。 但是，这不是唯一的知识来源。
我找到了另一种方法来查找有关构建项目的有价值的信息。 这种方法已经在实践中证明了自己。 它包括分析现有开源项目的
webpack.config文件。 特别是
CreateReactApp项目文件。 彻底阅读此文件，您会发现很多有用的东西。
总结
细心的读者可能会注意到，从一开始，这就是将重新组装时间减少到1秒的问题。 文中提到的该指标的最佳值为3.5秒。 显然，在描述装配过程的优化进度时，省略了一些内容。 就是这样 得益于微妙的优化，这又有可能使项目重新组装的时间缩短到1秒，这又是2.5秒，这很大程度上取决于特定项目（即Spot.IM）的功能。 因此，这里不提供这些改进的描述。
亲爱的读者们！ 您是否优化了项目的构建时间？
