Turbopack vs Webpack

Webpack 目前拥有超过 3 百万的下载量，它已是当下市占率最高的 JavaScript 构建工具。即便如此，我们已经碰到了基于 JavaScript 架构的瓶颈。

我们打造 Turbopack 想让它成为 Webpack 的接班人，它的速度更快并且灵活可拓展。

若要了解更多关于 Turbopack 的性能对比与测试方法，您可查阅性能测试章节。

速度

Turbopack 的递增式架构在多项关键指标上性能优于 Webpack。

我们发现 Webpack 的问题主要在开发服务器启动时间上。如果你在一个页面引入了大量模块，这个页面在加载到浏览器时，需要等好几秒完成初次编译。如果你在开发环境里修改了路由，你又得重复等待新页面的编译。

我们在设计 Turbopack 时，就想让它尽可能的「懒」—— 只有在收到请求时才会开始构建。这对于开发服务器来说，构建任务基于用户请求。在用户请求代码之前，代码不提前进行构建。你可以在核心概念章节了解更多详情。

这意味着，Turbopack 的开发服务器要比 Webpack 的快得多。对于底层使用 Webpack 的 Next.js 12，启动一个有 1,000 模块的应用需要花费 3.4s，而 Turbopack 仅需1.1s —— 要快出 3.0x。

Turbopack

turbo

1.1s

Webpack

3.4s

针对 Webpack 的进一步优化，我们发现可以在快速刷新上进一步突破瓶颈。对于刷新一个拥有约有 2,000 个组件的应用，我们测试能够达到的最佳结果是 500ms。这对于 Next.js 12 是一项巨大的更新，在此前这个过程需要花费大约 10 秒。

打造 Turbopack 实现了我们过去一直在追求的目标：无论应用体积如何，快速更新都能保持其性能。影响更新性能的不再是你的应用体积，而是你 对应用进行的修改。

对于有 1,000 模块的应用，Turbopack 的文件更新可以比 Webpack 快出 8.8x；对于有 30,000 模块的应用，Turbopack 可以快出 356.8x。

Turbopack

turbo

15ms

Webpack

134ms

Webpack 拥有丰富插件拓展其功能。通过对插件的整合，你可以自行打造工具链获取各种构建功能支持。

Turbopack 目前处于 alpha 阶段，暂时不支持插件配置。未来，我们计划让 Turbopack 能够像 Webpack 一样具有拓展性，但是 API 很可能会进行变动。