Next.js 15.5: Webpack vs Turbopack - Performance Improvements, Serious Regressions

Important note:

Since we published this article, Vercel have contacted us and pointed out the JS size may be inaccurate due to next build issues reporting inaccurate JS file sizes, and they are proposing to remove these statistics soon. We'd recommend care with measuring next resource sizes and instead try to use production CDN data more. We are working on a followup article with new best practice for this.

Results at a glance

Dimension	Webpack	Turbopack	Change
Cold build (median)	187.22 s	152.00 s	−18.8%
First-load JS shared-by-all (kB)	180	391	+211
App routes (151) - First‑load JS (median, kB)	387	666	+279 (+72%)
Routes smaller with Turbopack	–	–	0 / 153 UI routes

Why we ran this test

Vercel’s Next.js 15.5 release touts tangible build‑time improvements with Turbopack. We wanted to see how those claims translate to a real project with real routes and shared code. We picked Cal.com (open source, popular, actively maintained, many UI routes) and ran a controlled comparison: Webpack vs Turbopack.

Bottom line: In our Cal.com runs on Next 15.5.2, Turbopack reduced cold build time by ~19% (187.22 => 152.00 s). However, the App Router’s shared client chunk increased by ~211 kB (180 => 391 kB), and 151/151 App routes saw higher First‑load JS (median +279 kB, +72%). Measure your own app before switching.

Test bench & methodology

Repo: github.com/calcom/cal.com

Machine: M2 MacBook Air

Next.js: upgraded to 15.5.2

Build checks disabled: TypeScript and ESLint during build (to isolate bundler differences)

Build scripts:

build-webpack: next build
build-turbopack: next build --turbopack

Cold‑build benchmarking: 5 runs each with .next deleted before every run.

hyperfine \
  --prepare 'rm -rf .next' \
  --warmup 1 --runs 5 \
  'NEXT_TELEMETRY_DISABLED=1 yarn build-webpack' \
  'NEXT_TELEMETRY_DISABLED=1 yarn build-turbopack' \
  --export-json build-times.json

Build‑time results (cold builds)

TL;DR: Turbopack’s cold builds were ~18.8% faster at the median (187.22 => 152.00 s). Webpack’s runs clustered more tightly in the middle, but each tool showed a single opposite‑side outlier (one unusually slow Webpack run; one unusually fast Turbopack run).

Metric	Webpack	Turbopack	Notes
Median (s)	187.22	152.00	Typical run; basis for the −18.8% speedup.
IQR band (s)	184.81–187.84	147.44–154.16	Middle 50% of runs.
IQR width (s)	3.03	6.72	Smaller = steadier in the middle.
Mean (s)	191.83	149.04	Average including tails/outliers.
sd (s)	13.06	12.57	Standard deviation: overall spread around the mean.
Coeff. of variation	6.81%	8.43%	sd/mean; variability normalized.
Min / Max (s)	184.25 / 215.04	128.86 / 162.71	Observed extremes in 5 runs.
Delta (median)	-	−18.8%	(187.22 − 152.00) / 187.22.

What this means

• −18.8% median: Turbopack typically finishes first on cold builds.
• IQR: Webpack is tighter in the middle (3.03 s vs 6.72 s). Turbopack’s middle is a bit wider but still compact relative to its faster median.
• Outliers: One slow Webpack run (215.04 s), one fast Turbopack run (128.86 s). This is why we headline median + IQRover mean.

Notes: IQR = interquartile range (25th–75th percentile). sd = standard deviation (spread around the mean).

Bundle size deep‑dive (UI routes only)

Definition: What is "First‑load JS" here?

We parse Next’s build output tables and, for each route, take the "First Load JS" column reported by Next. This value includes the route’s own client chunks plus any "First Load JS shared by all" for the same router (App vs Pages). All units are kB. We exclude API endpoints and server‑only routes from the UI analysis.

We compared 153 UI routes (App Router: 151, Pages Router: 2). For each route we looked at First‑load JS.

TL;DR

Outcome	Count
Routes where Turbopack smaller	0
Routes where Turbopack larger	153 / 153

Medians (UI routes only)

Router	Median First‑load JS - Webpack (kB)	Median First‑load JS - Turbopack (kB)	Δ (kB)	Δ (%)
App (151 routes)	387	666	+279	+72.1%
Pages (2 routes)	286	324	+38	+13.3%

Shared client bundle (“First Load JS shared by all”) - before/after

Router	Webpack (kB)	Turbopack (kB)	Δ (kB)	Δ (%)
App	180	391	+211	+117.2%
Pages	239	219	−20	−8.4%

The +211 kB app‑wide increase in the shared client baseline largely explains why App‑Router routes ballooned: when the shared base grows, every route inherits that cost.

What the charts show

Chart A - Top 25 First‑load JS % increases (UI routes; min Webpack 200 kB)

Observation: Administrative and settings screens top the list, with multiple routes jumping 100–170%.

Figure A. UI routes with the largest percent increases when building with Turbopack vs Webpack.

Chart B - Distribution of First‑load JS deltas (Turbopack – Webpack, kB)

Observation: The bulk of routes fall into +100…+250 kB and +250…+500 kB buckets; there are no negative buckets.

Figure B. Bucketed distribution of First‑load JS deltas (Turbopack − Webpack) across UI routes.

Recommendations

• Run a two‑bundler A/B on your repo. Build with both Webpack and Turbopack, diff First‑load JS per route, and chart the deltas just like above.
• Watch the “shared by all” line. If it spikes, hunt the drivers. You can read more about this in our Reducing Next.js Bundle Size with Source Map Explorer guide here.
• Set budgets and fail CI. Add JS budgets (e.g., size-limit) to catch surges early. You can read more about this in our Optimizing Next.js Performance: Bundles, Lazy Loading, and Images guide, in the Automate Bundle Budgets in CI/CD section here.
• Defer the switch if UI payloads inflate. If your p75 LCP/INP are sensitive to JS weight (mobile, mid‑range devices), consider sticking with Webpack until the shared‑chunk issue is understood or mitigated.

Reproduce this study

{
  "scripts": {
    "build-webpack": "next build",
    "build-turbopack": "next build --turbopack"
  }
}

• Upgrade to Next 15.5.x, add the two scripts from above
• Optionally disable TypeScript/ESLint during builds to reduce noise.
• Benchmark cold builds with hyperfine (command above).
• Generate per‑route First‑load JS for both builds and diff.
• Plot:
• Top % increases (filter to routes with ≥200 kB in the Webpack baseline)
• Delta distribution buckets (Turbopack – Webpack in kB)

Takeaways

Turbopack demonstrated a notable developer experience improvement on Cal.com, achieving approximately 19% faster cold build times. However, this performance gain came with a significant tradeoff: all 153 UI routes in the application became heavier, with the App Router's shared bundle increasing by 211 kB.

The key recommendation is to carefully measure your application before adopting Turbopack in production. If you observe a similar increase in your shared baseline bundle size, you should expect degraded first-load performance unless you implement compensating optimizations.

These findings come with several important limitations. The testing was conducted on a single codebase (Cal.com) using a single machine, focusing exclusively on cold builds. The first-load JavaScript metric serves as a proxy for payload size but doesn't directly measure Core Web Vitals like LCP or INP. Additionally, the evaluation didn't cover development hot module replacement latency, incremental rebuilds, or server-side rendering performance, leaving these aspects as areas for future investigation.

This bundle size increase is particularly disappointing given that excessive bundle sizes remain one of the most persistent challenges in the Next.js ecosystem. While faster build times improve developer velocity, the resulting heavier client-side payloads directly impact end-user experience, especially on slower networks and devices.

We’re really interested in hearing from you with your results for Turbopack vs Webpack. Please email Martin ([email protected]) if you have any success or problems and we will publish a roundup of readers’ comments and views!