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-generation successor to Webpack based on Rust. The official announcement stated:

1. Nearly 700 times faster than Webpack.
2. 10 times faster than Vite, and the gap could reach 20 times 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 build tool based on Rust led by Tobias Koppers, the author of Webpack (currently in alpha stage).

The official article mainly elaborates on 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 that Turbopack established a completely new incremental architecture to achieve the fastest possible development experience (Rust has incremental compilation enabled by default), and the test results show good progress.

• In the "why it's so fast" section, it introduces that 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. It 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 executed repeatedly. This refined architecture allows the program to skip a lot of work at the function execution level.
  2. Support for 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 contribute to 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. However, 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 this on-demand bundling process.

The Turbo engine currently stores its cache in memory. This means the Turbo cache time will be consistent with 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.

Returning 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 10 times faster than Vite, and Vercel's marketing data was incorrect. Evan You used Next 13 (equipped 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 test 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, he conducted the test in client mode and found that Next 13's HMR did show significant improvement, being about 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 either 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 transformations. While SWC is significantly faster than Babel (20x faster in single-thread, 70x faster in multi-core), Vite currently doesn't use SWC for the following reasons:

1. Large installation size. It would add significant package size (58M itself while Vite is only 19M)
2. Some users need to rely on Babel's capabilities for transformations, making Babel indispensable for these users.

When Vite was tested using SWC for parsing, the conclusion was that Next/turbo was 4 times slower for root components compared to leaf components, while Vite was only 2.4 times slower. This means Vite HMR scales better in larger components. Additionally, switching to SWC could also improve Vite's cold start metrics in Vercel's benchmark tests.

Vercel's Clarification

After Evan You published the benchmark tests, 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 was extremely unfair to Vite.
2. There was a rounding issue with the original numbers for the 1000-component case - 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 benchmark used the "browser evaluation time" of the updated module as the end timestamp, rather than the React component re-rendering time.
4. The blog post's chart showed that Turbopack could be 10 times faster than Vite when the total number of modules exceeded 30k.

Summary of Vercel's Clarification

The claim of "10 times faster than Vite" holds true only 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 actual time to apply changes.

Evan You's Views on Vercel's Clarification:

1. For the vast majority of users, having 30k modules is extremely unlikely. With Vite using SWC, the number of modules required to achieve the 10x claim would become even more unrealistic. While theoretically possible, using this for Turbopack marketing is dishonest.
2. Compared to theoretical "module evaluation" time, users care more about end-to-end HMR performance, i.e., the time from saving to seeing changes. When seeing "10 times faster updates", average users think of the former rather than the latter, which Vercel omitted in their marketing. In reality, the end-to-end HMR of server components (default) in Next is slower than in Vite.

Views on Turbopack as a Competitor

Evan You's Perspective

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

Anthony Fu's Perspective - Core Team Member of Vite

Good design has a much greater impact on performance than the improvements brought by the programming language. The performance boost from the language is 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 hasn't been a good implementation of a plugin system based on native languages (balancing both performance and extensibility). We'll wait and see before Turbopack implements its plugin system.

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 ability to extend the existing ecosystem.

Sean Larkin's Perspective - Core Team Founder of Webpack

1. In my view, Turbopack owes more to SWC's capabilities rather than its own innovative abilities. I hope they could be clearer about this.
2. I'm disappointed with the tight coupling between Turborepo and Next. But 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 tend to think that modules on the development server should still be bundled, because ESM is slower than raw ESM. I need to strip away 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 unfair, and such marketing seems hypocritical 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

It's unreasonable to compare Turbopack to Webpack's successor - these 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 founder wSokra and serving as Webpack's next-generation build tool, quickly gaining widespread attention in the community.

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

1. Without SWC, it would be impossible. The Vercel 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 Perspective - 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 greater vision is to provide 95% of Webpack's features and ideas (including extension capabilities) and make migration easy.
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 in the cache. Further improvements to Turbopack's build speed in the initial build process will be made later.
3. Will no longer concern myself with this topic, as everyone will evaluate this value regardless. As the creator of both projects (Webpack & Turbopack), both projects are valuable, and my evaluation 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