Comparing Turbopack and webpack
We've built Turbopack as the successor of webpack: much faster, but just as flexible and extensible.
Turbopack's incremental architecture outstrips webpack's speed on several key metrics.
The main problem we found with webpack was development server startup time. If you end up importing a lot of modules in a certain page and open that page in your browser, the initial compile will take a few seconds. If you change routes in your development environment, you have to wait for a similar compile again for your new page.
We designed Turbopack to be as lazy as possible, only doing work when it's requested. In a dev server, this means on incoming requests we do exactly the work the user asked for. No more unnecessary bundling of on demand loaded code before the user needs it. You can learn more in our core concepts docs.
This means that Turbopack's dev server starts up much faster than webpack. Next.js 12, which uses webpack under the hood, can start up a build server on a 1,000 module application in 3.6s. Turbopack starts up in 1.5s - 2.5x faster.
As we continued to optimize webpack, we found a performance ceiling on how much faster we could make Fast Refresh. With around 2,000 components, the best number we could produce was 500ms. This mark was a tremendous feat in Next.js 12. Previously, that process would have taken around 10 seconds.
With Turbopack, we achieved the goal we were aiming for: Fast Refresh performance that stays near-constant, no matter your application size. Instead of scaling with your application size, it scales based on the size of the changes made.
In a 1,000 module application, Turbopack can react to file changes 5.6x faster than webpack. In a 30,000 module application, this is 217.3x faster.
webpack has an extraordinary collection of plugins (opens in a new tab) to customize its behavior. Composing plugins lets you create custom toolchains which can support a huge variety of bundler features.
As of Next.js 13.2, Turbopack introduced a compatibility layer to support webpack's loaders and resolve aliases. See Customizing Turbopack for how to configure them. In the future, we plan to make Turbopack just as extensible as webpack - though likely with an altered API.