In my last article I have covered features of Next.js 13. One of these features is a significant performance improvement. As the Turbopack, a new alpha Next.js bundler, as the page states, is up to 700 times faster than Webpack.

Also, it is significantly faster than Vite. Here is a screen shot from the Turbopack we site that tells about it:

It says Turbopack is ten times faster than Vite. It didn’t go without the attention of Evan You, Vite bundler creator.

Since Vercel didn’t provide at that time benchmarks used to back up their numbers for HMR, Evan ran his own, and it appeared Next.js 13 with Turbopack (both from Vercel company) was only two times faster than Vite for root:

Going further, he noticed that the performance difference may be caused by Vite using Babel on default, rather than SWC.

According to Evan switching Vite to SWC is easy, and after doing it he got these results:

Meaning, both were comparably fast for root, but again Next.js 13 with Turbopack being almost two times faster for a leaf than Next.js with Vite.

In a response to Evan’s post, Vercel published their benchmarks and improved them based on provided feedback. Here are the detailed results for HMR:

According to the chart Turbopack is faster than Vite several times for small number of modules. The difference is growing significantly as a function of module count.

Discussing the benchmark result Evan You stated that:

To sum up, the "10x faster than Vite" claim only holds if all of the following are true:

Vite is not using the same SWC transform

The application contains over 30k modules

The benchmark only measures the time for the hot updated module to be evaluated, but not when the changes are actually applied.

And, after additional analysis that:

I believe it makes more sense to use hmr_to_commit as the measurement metrics. This would bring the speed advantage to below 2x (~100ms vs ~54ms), which aligns with the numbers I’m seeing from my benchmarks.

Summary

Vercel’s Turbopack based on the benchmarks by the company is ten times faster than Vite in specific conditions. Evan You does not seem to argue about.

What he says is that in other conditions Turbopack is only two times faster. That seems to be a result he agrees to accept.

For Vite to accomplish the result, the default Babel has to be switched to SWC. On one hand it makes sense to call it comparing apples to apples.

On the other hand it makes you wonder, why not compare default, suggested settings of Turbopack vs Vite resembling how people actually can use both.

Surely Vite has some possibilities to improve the performance for the users by helping them transition to SWC. The information may be interesting for the Vite users who, as I believe, chose it purely for performance benefits.

Maybe Turbopack won’t be ten times faster in HMR than Vite. Maybe it will be only two times faster. But it still accounts to 10 seconds of waiting rather than 20. Given the tests are made on the latest and most expensive hardware it is easy to guess HMR will be working much slower on an average development system.

Still, it’s great we have an another solution to improve development performance. Hot Module Reload is one, single feature that helps develop complex apps faster and better.

I can’t wait for benchmarks from independent developers to see what is the real result. But I am sure, we may find our tool sets to gain significant performance improvements in the following years.

Subscribe, also via e-mail, clap, like and share for more articles!