turbopack vs webpack: is it finally ready in 2025? - By Sourav Mishra (@souravvmishra)
vercel's new rust bundler promises to be 700x faster. but does it actually work in production? let's test it out.
for years, webpack was the only way to bundle apps. but as projects got bigger, we started waiting 30 seconds just to start the dev server. lol, not fun.
then came turbopack. it's built in rust and wants to replace webpack completely.
i am sourav mishra, and i tested it out on a massive next.js 16 app at codestam technologies to see if it's actually ready.
the speed test
i moved a huge enterprise app with about 500 pages to turbopack. this wasn't a tiny starter app. we had heavy stuff like three.js, ag-grid, and framer-motion.
| metric | webpack | turbopack | how much better? |
|---|---|---|---|
| dev server start | 4.2s | 0.4s | 10.5x faster |
| hot reload | 1.2s | 0.05s | 24x faster |
| memory used | 1.4gb | 400mb | 3.5x lighter |
| initial build | 12.5s | 1.8s | 6.9x faster |
just like the react 19 compiler speeds up your code, turbopack speeds up your whole workflow.
is it stable yet?
in next.js 16, vercel says turbopack is stable for local dev.
so you should definitely use it (next dev --turbo). it is way faster and doesn't crash randomly like it used to.
what about production?
here is the catch. for production (next build), next.js still defaults to webpack for most people. why? because webpack has a million plugins that haven't been rewritten in rust yet.
when should you switch?
- right now: for local dev. the speed is just too good to ignore.
- later: for production builds. wait until more plugins support it.
wrapping up
turbopack is legit. it is the future of bundling. if you aren't using --turbo on your machine, you are wasting so much time waiting for things to load.
want more ways to speed things up? check out my post on middleware mistakes.
written by sourav mishra, trying to stop staring at loading screens at codestam technologies.