Why is Turbopack bundle size so FREAKING HUGE?? 4.6x larger than Webpack

[billnye2]

Summary

Build with webpack: 0.57 mb transferred --- 1.8 mb resources
Build with turbopack: 2.6mb transferred --- 8.4 mb resources

As recorded by Chrome dev tools network tab, filtered by js only. First page load.

Same exact codebase. Simply running "next build" vs "next build --webpack"

Turbopack is 4.6x larger??

There's gotta be something wrong here because this is atrocious.. please advise.

Additional information

No response

Example

No response

[icyJoseph]

You can, in your dev environment, use next@canary, and then run next experimental-analyze --serve - once again, in canary! then you should be able to see what Turbopack is bundling.

[billnye2]

I think I figured out what is happening and it might not be shown in the bundle analyzer. In the browser, turbopack is loading multiple js files (perhaps preloading other routes) with duplicate code/dependencies in these bundles. Not sure why. Example:

I have a Pages Router app. I use react-dropzone.

With webpack, the react-dropzone code is loaded in one bundle only: the _app-hash.js bundle.
With turbopack, the react-dropzone code is loaded in 11 bundles!! All 11 js files load on first page load. Is this expected behavior?

I am also seeing turbopack produces many more js files. These 11 files I mentioned above are eerily close in file size, and there are other clusters of js files that are also basically 1:1 clones of each other. All loaded on the first page load.

Is turbopack not optimized for Pages Router? I could see that being the reason.

[icyJoseph]

If you can't share a repository, could you instead give me a description I could feed into an LLM to mimic your react-dropzone usage and try to get the same effect? The fresh create-next-app is already showing Turbopack at 1.3MB and Webpack at 2.3MB in dev mode. In build it is the same download, 483kb including images and other assets in all cases, no only JS.

[brijeshb42]

Here is a repo if you still want to look into this -

https://github.com/mui/base-ui

The next.js based docs (statically exported) is in docs folder.

Currently, turbopack is setup and used in production. But webpack can be used by pnpm -F exec next build --webpack.

Measured with Playwright Chromium on May 26, 2026, using CDP Network.setCacheDisabled plus no-cache headers. Cache hits were 0 for every page on both sites. Sizes below are first-party same-origin JS + CSS transfer bytes; positive diff means master Turbopack is larger than deployed Webpack.

Here's a measurement using playwright -

Page	Turbopack	Webpack	Diff	Diff %	JS Diff	CSS Diff
Home	439.9 KB	385.2 KB	+54.7 KB	+14.2%	+47.7 KB	+6.9 KB
Accordion	764.5 KB	722.9 KB	+41.6 KB	+5.8%	+66.4 KB	-24.8 KB
Dialog	762.8 KB	717.0 KB	+45.8 KB	+6.4%	+70.4 KB	-24.6 KB
Menu	789.1 KB	750.3 KB	+38.8 KB	+5.2%	+63.5 KB	-24.7 KB
Select	783.1 KB	764.8 KB	+18.3 KB	+2.4%	+46.6 KB	-28.3 KB
Tooltip	720.9 KB	719.2 KB	+1.8 KB	+0.2%	+30.8 KB	-29.0 KB

Average across the 6 pages: master loads 710.1 KB first-party JS+CSS vs 676.6 KB on Webpack, so Turbopack is +33.5 KB / +5.0% larger on average.

Main pattern: Turbopack loads consistently more JS, but less CSS on component pages. The CSS reduction offsets much of the JS increase, especially on Tooltip and Select.

Turbopack is also affecting the page load metrices -

Measured synthetic RUM-style metrics with Playwright Chromium, cache disabled, fresh context per load, median of 3 runs per page.

Page	Turbopack FCP	Webpack FCP	Diff	Master LCP	Prod LCP	Diff	CLS	TBT	Load Diff
Home	808 ms	652 ms	+156 ms	808 ms	652 ms	+156 ms	0	0	+163 ms
Accordion	864 ms	596 ms	+268 ms	864 ms	596 ms	+268 ms	0	0	+251 ms
Dialog	860 ms	724 ms	+136 ms	860 ms	724 ms	+136 ms	0	0	+127 ms
Menu	928 ms	652 ms	+276 ms	928 ms	652 ms	+276 ms	0	0	+289 ms
Select	892 ms	712 ms	+180 ms	892 ms	712 ms	+180 ms	0	0	+136 ms
Tooltip	860 ms	608 ms	+252 ms	860 ms	608 ms	+252 ms	0	0	+254 ms

Average across the 6 pages:

Metric	Turbopack	Webpack	Diff
TTFB	63 ms	45 ms	+18 ms
FCP	869 ms	657 ms	+212 ms
LCP	869 ms	657 ms	+212 ms
Load	887 ms	684 ms	+203 ms
CLS	0	0	0
TBT	0	0	0

Result: the currently deployed Webpack site is consistently faster in this synthetic run, mainly by ~136-276 ms on FCP/LCP depending on page. Turbopack showed no layout instability or blocking-task regression, but it paints later across every measured page.

[brijeshb42]

Updated measurement on May 27, 2026.

Re-ran with both bundlers served from the same Netlify edge — Turbopack from https://master--base-ui.netlify.app/ (Next 16 default) and Webpack from a deploy preview built with next build --webpack (https://deploy-preview-4924--base-ui.netlify.app/). The earlier numbers compared Netlify preview vs base-ui.com prod CDN; that CDN delta was inflating the RUM gap.

Methodology: Playwright Chromium, fresh context per load, CDP Network.setCacheDisabled, first-party same-origin only, waitUntil: 'domcontentloaded' + load event (no networkidle settle, to avoid Next.js router prefetches polluting totals). 5 runs per page, median reported. RUM via in-page PerformanceObserver.

JS bytes (KB, median)

Page	Turbopack	Webpack	Diff	Diff %
/	142.4	130.8	-11.6	-8.1%
/react/overview/quick-start	370.2	337.0	-33.2	-9.0%
/react/handbook/customization	324.7	294.2	-30.5	-9.4%
/react/handbook/styling	324.7	294.2	-30.5	-9.4%
/react/components/accordion	372.6	336.6	-36.0	-9.7%
/react/components/dialog	375.9	346.6	-29.3	-7.8%
/react/components/select	376.9	342.8	-34.1	-9.0%
/react/components/popover	373.4	340.0	-33.4	-8.9%
/react/components/menu	375.2	346.9	-28.3	-7.5%
/react/components/tooltip	373.4	345.6	-27.8	-7.4%
sum (10 pages)	3409.4	3114.7	-294.7	-8.6%

Turbopack ships ~8–10% more JS per route consistently. Negative diff = Webpack smaller.

CSS bytes (KB, median)

Page	Turbopack	Webpack	Diff
/	24.0	39.5	+15.5
/react/overview/quick-start	45.0	37.9	-7.1
/react/handbook/customization	31.6	33.4	+1.8
/react/handbook/styling	31.6	33.6	+2.0
/react/components/accordion	34.1	35.8	+1.7
/react/components/dialog	47.0	62.3	+15.3
/react/components/select	45.7	48.6	+2.9
/react/components/popover	44.3	47.4	+3.1
/react/components/menu	45.5	48.7	+3.2
/react/components/tooltip	43.9	49.7	+5.8
sum	392.7	436.9	+44.2

CSS is closer to a wash. Turbopack chunks more aggressively (fewer files) and wins on a couple of component pages, but Webpack wins on / and /dialog by ~15 KB each.

FCP / LCP (ms, median)

Page	Turbopack FCP	Webpack FCP	Diff	Turbo LCP	Web LCP
/	764	672	-92	764	672
/react/overview/quick-start	872	824	-48	872	824
/react/handbook/customization	900	840	-60	900	872
/react/handbook/styling	844	880	+36	844	880
/react/components/accordion	868	908	+40	868	908
/react/components/dialog	884	924	+40	908	956
/react/components/select	920	972	+52	920	972
/react/components/popover	868	872	+4	868	872
/react/components/menu	876	908	+32	876	908
/react/components/tooltip	808	840	+32	808	840

With CDN held constant, FCP/LCP is within ±60 ms — bundler-level noise. Turbopack actually edges out Webpack on 6 of 10 pages. The previous ~190–270 ms gap I reported was the prod CDN being faster than the Netlify preview, not the bundler. CLS = 0 / TBT = 0 on both.

Net: when isolated from CDN, the only real regression is +~30 KB JS per route (~9%). RUM is comparable.

[icyJoseph]

Thanks for these, we are taking a look.

Noticed the apps is on 16.1, although 16.2 didn't ship any optimizations on this area (that I am aware of), I do wonder if there's something preventing you from upgrading?

[DaanRoet]

In our repository I noticed a big difference in size between webpack and turbopack due to the usage of zod. Didn't fully understand until I read this colinhacks/zod#5561 (comment) from the maintainer. Seems like Turbopack handles the tree-shaking quite different for the way their code is structured.

When I changed import { z } from "zod" to import * as z from "zod" throughout our codebase it seemed to tree-shake the locales correctly, however I wish we didn't have to do this as some bundlers (including webpack) seem to handle the old import fine out of the box.

[sentience]

See also #96040 for a clear root-cause and proposal to fix what I think is being discussed on this thread.

[terrymun]

We are also running into a similar issue here, but this time it's with the use of @sentry/nextjs and it being effectively duplicated across all routes. This leads to significant bloat—and since we are hosting our Next.js app on AWS Amplify, it causes the final build size to exceed the allowed ~230mb threshold. I believe the root cause is the same as this one: #89192

Attempts to use the suggested experimental.turbopackChunking in #96040 didn't really work, as it only affects client chunks not server ones.

Our last resort is to force Next.js to be built with webpack in production, which results in sufficient size savings compared to Turbopack that lowers the build size beyond the hard limit set by Amplify, while still allowing local dev to use Turbopack due to its speed.