Logo

菜单

发布于 2026-01-06 4 阅读
0

如何提升 webpack 构建速度？Speed Measure 插件（适用于 webpack）DEV 的全球展示挑战赛，由 Mux 呈现：展示你的项目！

如何提升webpack构建速度？

测速插件
（适用于 webpack）

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

我是如何将项目的 webpack 构建时间缩短一半的？

谁没抱怨过 webpack 构建项目时那漫长的等待时间？
我目前正在开发一个大型 Web 应用，它使用 React/Redux 编写，并采用服务端渲染。
这个应用从 2015 年就存在了，并且从那时起经历了多次迭代（M6web 技术博客）。

6play 网站截图

TLDR；

绝对、绝对、绝对不要在没有监控的情况下进行性能改进或优化！

要想优化作业的执行时间，就必须精确监控作业及其所有子步骤的执行时间。
这样，你才能真正专注于最耗时的任务。
这能避免你把时间浪费在对系统整体影响甚微的优化上。
使用现有的监控工具！如果没有，那就自己创建！

webpack 出了什么问题？

几个星期/几个月以来，我的同事们一直在抱怨我们这yarn build条命令的执行时间过长。
这条命令的目的是使用webpack在生产环境中构建我们应用程序的可分发包。

我甚至还听到过：

  • “这条命令我不再在本地运行了，它太耗时了。”
  • “每次运行这条命令，我的电脑都会剧烈地发出散热声。我没办法再这么做了！”

根据启动构建的机器不同，构建耗时在 5 到 12 分钟之间。
构建过程不可能耗时这么长。
webpack它本身并不是一个慢的打包工具，
而是我们使用了其他webpack工具才导致速度慢。

对焦错误，一个早晨的迷失

由于这条命令会启动 webpack 构建production，我发现问题出在 webpack 配置本身。
鉴于我对 webpack 已经进行了深入研究，我认为解决这个性能问题会很有意思。
事实上，我已经开源了一套从零开始学习如何使用 webpack 的教程（https://webpack-workshop.netlify.com）。

slashgear_

逐步学习 webpack

安托万·卡隆 ・ 2019年7月23日

#webpack #javascript #webdev #showdev

所以在一月底，我花了一天时间来改善这种情况。

我原本以为这项任务会耗费我最多的时间。于是我尝试改进它，花了一整个上午的时间。
结果只提高了17秒。

说实话，我对自己的成绩非常失望。

然而，我的策略中存在的隐患显而易见。
我一开始就预设了一个想法：“这肯定是耗时最长的阶段。”

我的分析完全缺乏客观性。
要提升应用程序的性能，必须关注客观事实。

下午一切顺利

午休回来后，我决心要赢下比那可怜的17秒更多的时间。
这时，我想起了帕累托法则。

帕累托法则（又称80/20法则、关键少数法则或因素稀疏性法则）指出，在许多事件中，大约80%的结果来自20%的原因。
维基百科

webpack 构建过程中，可能有一个步骤占用了大部分时间。
如果将帕累托法则应用于 webpack，则可以理解为“80% 的构建时间是由 20% 的配置造成的”。

我们一起找出罪魁祸首！🎉

我需要确定每个加载器、每个插件的构建时间。
幸运的是，webpack 社区已经提供了一个插件，可以测量所有这些指标。
而且安装起来非常简单。♥️

GitHub 标志 stephencookdev / speed-measure-webpack-plugin

⏱ 查看您的插件和加载器运行速度如何（或缓慢），以便优化您的构建。

测速插件
（适用于 webpack）


优化 webpack 构建速度的第一步，是知道应该把注意力集中在哪里。

该插件用于测量您的 webpack 构建速度，并输出类似如下的内容：

速度测量插件输出预览

安装

npm install --save-dev speed-measure-webpack-plugin
Enter fullscreen mode Exit fullscreen mode

或者

yarn add -D speed-measure-webpack-plugin
Enter fullscreen mode Exit fullscreen mode

要求

SMP 至少需要Node v6。但除此之外，它接受所有 webpack版本（1、2、3 和 4）。

用法

修改你的 webpack 配置

const webpackConfig = {
  plugins: [new MyPlugin(), new MyOtherPlugin()],
};
Enter fullscreen mode Exit fullscreen mode

到

const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");

const smp = new SpeedMeasurePlugin();

const webpackConfig = smp.wrap({
  plugins: [new MyPlugin(), new MyOtherPlugin()],
});
Enter fullscreen mode Exit fullscreen mode

大功告成！SMP 现在默认会将计时输出打印到控制台。

看看这些例子……

在 GitHub 上查看

以下是我得到的结果：



SMP  ⏱  
General output time took 4 mins, 5.68 secs

 SMP  ⏱  Plugins
IgnorePlugin took 57.73 secs
TerserPlugin took 39.022 secs
ExtractCssChunksPlugin took 3.13 secs
OptimizeCssAssetsWebpackPlugin took 1.6 secs
ManifestPlugin took 1.55 secs
WebpackPwaManifest took 0.326 secs
ContextReplacementPlugin took 0.129 secs
HashedModuleIdsPlugin took 0.127 secs
GenerateSW took 0.059 secs
DefinePlugin took 0.047 secs
EnvironmentPlugin took 0.04 secs
LoadablePlugin took 0.033 secs
Object took 0.024 secs

 SMP  ⏱  Loaders
babel-loader, and 
rev-replace-loader took 2 mins, 11.99 secs
  module count = 2222
modules with no loaders took 1 min, 57.86 secs
  module count = 2071
extract-css-chunks-webpack-plugin, and 
css-loader, and 
postcss-loader, and 
sass-loader took 1 min, 43.74 secs
  module count = 95
css-loader, and 
postcss-loader, and 
sass-loader took 1 min, 43.61 secs
  module count = 95
file-loader, and 
rev-replace-loader took 4.86 secs
  module count = 43
file-loader took 2.67 secs
  module count = 32
raw-loader took 0.446 secs
  module count = 1
@bedrock/package-json-loader took 0.005 secs
  module count = 1
script-loader took 0.003 secs
  module count = 1
Enter fullscreen mode Exit fullscreen mode

不出所料，情况不太妙！
但至少我开始明白罪魁祸首是谁了。
我们可以看到，2222 个 JavaScript 模块耗时 2 分钟，而仅仅 95 个 Sass 文件却只用了 1 分 43 秒🤣。

妈的

该死的 node-sass

从旧版本迁移node-sass到sass新版本（Sass 重新实现）并更新后sass-loader，我简直惊呆了！
由于只有少量破坏性更改，整个过程只用了大约 10 分钟，构建时间却缩短了 1 分 30 秒以上。

sass-loader性能方面有了很大的提升，你一定要确保使用最新版本。

我花了一上午时间才赢了17秒，花了10分钟才赢了1分30秒。🤣

忽略插件，TerserPlugin

  • TerserPlugin用于压缩 JavaScript 代码，以减小其体积并提高可读性。虽然这个过程相对较长，但39 秒仍然太长了。
    仅仅通过将 TerserPlugin 的版本更新为 Webpack 集成的版本，我就成功地将构建时间缩短了 20 秒。

  • IgnorePlugin是我们应用程序中大量使用的核心插件，它用于避免加载某些脚本以减轻网站负载。
    虽然当时这样做是必要的，但如今有了 Webpack，我们可以做得更好。动态导入、上下文替换等等，有很多解决方案。一般来说，我们应该避免编译文件却不使用它们。

来自社区的建议

为了提升构建性能，webpack 提供了一个网页，列出了查找耗时原因的步骤。
我强烈建议您查看一下。

https://webpack.js.org/guides/build-performance/

最终结果



    SMP  ⏱  
    General output time took 2 mins, 18.27 secs
Enter fullscreen mode Exit fullscreen mode

哦，是的

基于精确具体的措施，我大幅提升了应用程序的 webpack 构建性能。
现在，计算机不再因为编译少量 JS 和 SASS 代码而耗费大量资源。
如果我没有精确地测量出哪些因素会影响构建性能，我可能会浪费一整天的时间进行徒劳的修改。

ℹ️

  • 用于Speed Measure Plugin调试 webpack 构建时间
  • 跟踪构建时间的变化，以便在合并前检测到重大变化。
  • 遵循 webpack 性能建议
  • 了解 webpack 的 5 种新缓存策略
  • 保持你的 webpack 配置最新
文章来源：https://dev.to/slashgear_/how-to-boost-the-speed-of-your-webpack-build-16h0
什么是盒模型？🤔 由 Mux 主...
📊 构建 TaskFlow Pr...