Is Turbopack really 10x Faster than Vite?

An article published by Evan You on 2022.11.1. The reason for publishing this article was a tweet released by Vercel at 1.35 on 2022.10.26, which introduced Turbopack, the next Rust-based successor to Webpack. The official statement claimed:

1. Nearly 700 times faster than Webpack.
2. 10 times faster than Vite and potentially up to 20 times faster in larger applications.
3. Native incremental architecture built with Rust.
4. Support for RSC.
5. Basic capabilities including TS, JSX, CSS, etc.

Let's take a brief look at Turbopack, this exciting build tool.

From GitHub, we can see that Turbopack is a Rust-based build tool led by Tobias Koppers, the author of Webpack (currently in alpha stage).

The official article mainly discusses Turbopack's performance in terms of "how fast it is", "why it's so fast", and "future plans".

• In the "how fast" section, it introduces Turbopack's new incremental architecture built for the fastest possible development experience (Rust has incremental compilation enabled by default), showing good progress in test results.

• In the "why it's so fast" section, it introduces how Turbopack's architecture combines innovations in incremental computation from tools like Turborepo and Bazel(Google), focusing on using caching to avoid doing the same work repeatedly. Turbopack's caching capabilities are as follows:

  1. Result caching at function granularity. Can cache the results of any function in the program, as long as the function's inputs haven't changed, the function won't be re-executed. This refined architecture allows the program to skip a lot of work at the function execution level.
  2. Supports memory caching, with plans for persistent caching and remote caching in the future.

  Evan You also praised Turbopack's powerful caching capabilities, stating that he would use Turbopack to replace esbuild and rollup at an appropriate time in the future.

• In the "future plans" section, it introduces that Turbopack will be used in Next.js 13 development environment to provide lightning-fast HMR capabilities, with native support for RSC, TypeScript, JSX, CSS, etc. It will gradually become part of Next.js production builds. It also calls for Webpack users to migrate to Turbopack and help build the Turbopack ecosystem.

How the Turbopack Engine Works

In a Turbopack-driven program, certain functions can be marked as "to be remembered". When these functions are called, the Turbo engine remembers what they were called with and what they returned. Then it saves this in a memory cache. Here's a simplified example: First, readFile is called in both api.ts​ and sdk.ts​ files. Then these files are bundled, concatenated together, and finally fullBundle is obtained. The results of all these function calls are saved in the cache for later use.

Since the sdk.ts​ file has changed, it needs to be bundled again. But the api.ts​ file hasn't changed. We can just read the result from the api.ts cache and pass it to concat. Therefore, a lot of time is saved through the on-demand bundling process.

The Turbo engine currently stores its cache in memory. This means the Turbo cache time will match the program process runtime. Later, there are plans to persist the cache, either to the file system or to a remote cache like Turborepo. This means Turbopack can remember work completed across runs and machines.

This approach makes Turbopack very fast at computing incremental updates to applications, optimizing Turbopack to handle updates in development, meaning the Dev server will always respond quickly to changes.

Back to the beginning, Evan You published an article with the title. The content tests various benchmarks with the argument "investigating whether Turbopack is 10 times faster than Vite". Evan You acknowledged that Turbopack is faster, but not ten times faster than Vite, and Vercel's marketing data was incorrect. Evan You used Next 13 (with Turbopack) and Vite 3.2 to compare their HMR performance. The following benchmarks were used:

root: Root component. The component imports 1000 different child components and renders them together;

leaf: Leaf component. The component is imported by the root component and has no child components itself.

1. Is RSC Enabled?

The initial benchmark measured Next 13's HMR performance using root and leaf components in server mode. The results showed that Next 13 was actually slower in both cases, with the difference being more pronounced for leaf components. The test method and results are as follows. Later, Evan You also noticed that comparing with RSC enabled was unfair to Next 13. Therefore, client mode was used for testing, and it was found that Next 13's HMR did improve significantly, being 2x faster than Vite, but not reaching the 10x claimed in Vercel's marketing.

2. Does Vite Use SWC(rust-based) Instead of Babel(js-based) for React Transform?

React HMR and JSX transformation are not coupled with the build tool, they can be done through Babel(js-based) or SWC(rust-based). Esbuild can also transform JSX, but lacks support for HMR. Vite uses Babel by default for handling React HMR and JSX with the React preset. SWC is obviously much faster than Babel (20x faster in single thread, 70x faster in multi-core). The reasons why Vite doesn't use SWC at this stage:

1. Large installation size. It adds significant package size (58M itself while Vite is only 19M)
2. Some users need to rely on Babel's capabilities for transformation, so Babel is indispensable for some users.

When Vite uses SWC for parsing, the conclusion is that Next/turbo is 4 times slower for root components than leaf components, while Vite is only 2.4 times slower. This means Vite HMR scales better in larger components. Additionally, switching to SWC can also improve Vite's cold start metrics in Vercel's benchmarks.

Vercel's Clarification

After Evan You published the benchmarks, Vercel released a blog post clarifying their benchmarking methodology and made their benchmarks available for public verification. Evan You immediately commented that they should have done this on the first day. The key points of the article are as follows:

1. When testing Vite HMR performance in the benchmarks, they still used Babel, while using SWC for Turbopack and Webpack tests. This is extremely unfair to Vite.
2. The original numbers for the 1000 component case had rounding issues—Turbopack's 15ms was rounded to 0.01s, while Vite's 87ms was rounded to 0.09s. When the original numbers were close to 6 times, this was further marketed as a 10 times advantage;
3. Vercel's benchmarks used the "browser evaluation time" of the updated module as the end timestamp, rather than the React component re-render time;
4. The blog post's charts show that Turbopack can be 10 times faster than Vite when the total number of modules exceeds 30k.

Vercel's Clarification Summary

The claim of "10 times faster than Vite" holds true if all of the following conditions are met:

1. Vite doesn't use the same SWC transformation.
2. The application contains more than 30k modules.
3. The benchmark only measures the evaluation time of hot-updated modules, not the time to actually apply changes.

Evan You's Views on Vercel's Clarification:

1. For the vast majority of users, 30k modules is an extremely unlikely scenario. With Vite using SWC, the number of modules required to reach the 10 times claim would likely become even more unrealistic. While theoretically possible, using it to market Turbopack is dishonest.
2. Users care more about end-to-end HMR performance—the time from save to seeing changes—than theoretical "module evaluation" time. When seeing "10 times faster updates", average users think of the former rather than the latter, and Vercel omitted this caveat in their marketing. In reality, end-to-end HMR in Next with server components (default) is slower than in Vite.

Views on Turbopack as a Competitor

Evan You's Views

Simply put, whether new competitors are complementary to Vite depends on the designers' goals. Turbopack's emergence is a strong competitor for all build tools in the market, with relatively excellent build capabilities compared to other build tools, and can achieve good returns and status in the market. From Evan You's statement, Turbopack can serve as a basic build tool for meta frameworks or as an out-of-the-box spa solution.

Anthony Fu's Views - Core Team Member of Vite

Good design has a much greater impact on performance than language improvements. Language performance improvements are more like a constant coefficient, and simply changing languages can only bring limited improvements. What makes Vite more attractive is its plugin system and the ecosystem built on top of it. This is how improvements can be quickly brought to other areas. Currently, there are no good implementations of plugin systems based on native languages (balancing both performance and extensibility) in the market. We can't evaluate until Turbopack implements its plugin system, so we'll wait and see for now.

How to evaluate Vercel's open-source Turbopack implemented in Rust? – Anthony Fu's answer – Zhihu

TIP

It can be seen that Anthony Fu evaluates a build tool mainly from two aspects. The first aspect is performance factors, and the second aspect is the extensibility of the existing ecosystem.

Sean Larkin's Views - Core Team Founder of Webpack

1. In my view, Turbopack relies more on SWC's capabilities rather than its own innovative capabilities, and I hope they can express this more clearly.
2. I'm disappointed with the tight binding between Turborepo and Next. It can't be helped, Vercel needs to raise more angel funding.
3. It's difficult for average users to migrate from Webpack to Turbopack.
4. I prefer that modules on the dev server are still bundled, because ESM is slower than raw ESM. I need to strip more layers to make independent implementations work.
5. Currently Turbopack is still in alpha stage, so we should be more open-minded, but I still hope for more substance and less marketing.
6. Comparing Turbopack to Webpack's successor is biased, and such marketing seems insincere and misleading to observers. As a successor, Turbopack needs to have the features that Webpack has and make it easy to migrate from Webpack to Turbopack.

TIP

Comparing Turbopack to Webpack's successor is unreasonable, as they are two different tools, in a coexisting relationship rather than a replacement relationship. This contains a lot of marketing tactics, using the identity of Webpack's creator to promote the new build tool, making some community members think this is a new build tool created by Webpack's creator wSokra and serving as Webpack's next-generation build tool, quickly gaining widespread community attention.

Lee Robinson's Response - VP of Developer Experience at Vercel

1. It would be impossible without SWC, and Vercel's development team did a lot of work on SWC in the early stages.
2. Currently focusing on supporting Next 13 version, with future goals to provide support for all frameworks.
3. Migration from Webpack to Turbopack will take time, and we are confident we will embrace the community (plugin extension capabilities).

wSokra's Views - Creator of Webpack and Turbopack

1. Currently comparing Turbopack to Webpack's successor is a marketing tactic, and Webpack will definitely not be abandoned. But Turbopack's bigger vision is to provide 95% of webpack's features and ideas (including extension capabilities) and make it easy to migrate.
2. Turbopack's incremental builds depend only on the size of changed files, not the total compilation size. For Webpack, incremental builds are based on total compilation size because Webpack needs to retrieve all modules from the cache. Further improvements to Turbopack's build speed in the initial build process will be made later.
3. No longer concerned about this topic, as everyone will evaluate its value regardless. As the creator of both projects (Webpack & Turbopack), both projects are valuable, and my evaluation of both in the community would amplify this matter, which isn't friendly to users or supporters of either project.

Contributors

XiSenao SenaoXi

Changelog

Last edited 21 days ago

View full history

9ba4ed7-feat: i18n

64d2bfd-feat: reorganize document directory & change toolbox item to material item

a989f82-chore: format code

eaafd87-chore: reformatting global code

548e2cc-chore: adjust project structure && optimize sidebar

cf57b03-chore: eslint code

61904a6-chore: init project