Je CI-pijplijn voltooit een Next.js build en pusht naar Vercel. Vier minuten later wordt je preview gedeployd. Je hebt dit ritme geaccepteerd omdat Webpack altijd traag is geweest op schaal — totdat Turbopack in Next.js 16 de standaardbundler werd. We migreerden in maart 2025 drie client-apps van Next.js 15 af, hongerend naar die sub-minuutse buildtijden die de release notes beloofden. Twee deployments braken onmiddellijk. Eén Sentry-integratie stopte met rapporteren. Een custom Webpack-plugin waarop we twee jaar hadden vertrouwd, had geen Turbopack-equivalent. Maar de apps die het overleefden? Build times daalden van 3m 52s tot 51 seconden, en één bijzonder lastige bundle kromp met 18%. Hier is elke breaking change die we hebben gedocumenteerd, de performance deltagetallen die we hebben gemeten, en de migratiereeks die ons liet deployen zonder rollback.

Dit is geen herhaling van de release notes. Dit is wat daadwerkelijk gebeurde toen we next build met Turbopack op echte codebases met echte complexiteit draaiden.

Inhoudsopgave

Next.js 16 Turbopack Production Builds: Wat veranderde en hoe we migreerden

Waarom Next.js 16 belangrijk is

Next.js 16 is niet zomaar een versie-update. Het vertegenwoordigt de meest significante verandering in de build-infrastructuur sinds het framework van Pages naar de App Router ging. De headline feature is voor de hand liggend: Turbopack vervangt webpack als de standaardbundler voor zowel development als production builds.

Maar er gebeurt meer. Next.js 16 wordt ook geleverd met:

  • React 19 als minimum ondersteunde versie — geen React 18 compatibiliteit meer
  • Verbeterde streaming en partial prerendering volwassenheid
  • Nieuwe caching standaarden die daadwerkelijk logisch zijn (ze hebben ervan geleerd na de Next.js 15 caching tegenreactie)
  • Async request APIs volledig afgedwongen — cookies(), headers() en params zijn nu allemaal async zonder legacy sync-ondersteuning
  • Node.js 20 minimum vereiste — Node 18 ondersteuning is weg

Voor bureaus als het onze die Next.js development doen, is dit het soort release dat alles raakt. Je kunt niet zomaar een versienummer bumpen en het voor gezien houden.

Wat daadwerkelijk veranderde met Turbopack in production

Laten we concreet zijn. Tijdens Next.js 14 en 15 was Turbopack beschikbaar voor next dev met de --turbo vlag. Production builds gebruikten nog steeds webpack. Next.js 15.3 introduceerde een experimentele --turbopack vlag voor next build, en op het moment dat 16 verscheen, werd het de standaard.

Hier is wat fundamenteel anders is aan hoe Turbopack production builds afhandelt in vergelijking met webpack:

Incremental Compilation Architecture

Webpack verwerkt je volledige dependency graph op elke build. Turbopack gebruikt een function-level caching systeem gebouwd op de Turbo-engine (geschreven in Rust). In de praktijk betekent dit dat volgende builds alleen hercompileren wat daadwerkelijk is veranderd. Je eerste build is misschien niet dramatisch sneller, maar je tweede, derde en tiende builds zullen dat wel zijn.

Tree Shaking Improvements

Turbopack's tree shaking werkt op een fijner niveau dan webpack's. We merkten dat onze client bundles zonder codewijzigingen gemiddeld 8-15% kleiner waren. De grootste winsten kwamen van barrel file handling — Turbopack is daadwerkelijk beter in het elimineren van ongebruikte re-exports uit indexbestanden.

Module Resolution

Turbopack lost modules anders op. Het is sneller, maar ook strenger. Als je slorpige import paden had die webpack stilzwijgend oploste (zoals ontbrekende bestandsextensies in bepaalde edge cases, of case-insensitieve paden op macOS die breken op Linux), zal Turbopack dat opvangen. Dit veroorzaakte ongeveer 30% van onze migratieproblemen.

Code Splitting Strategy

De chunk splitting algoritme is nieuw. Turbopack maakt standaard meer, kleinere chunks. Dit verbetert over het algemeen de laadprestaties voor moderne browsers met HTTP/2, maar het kan het totale aantal aanvragen verhogen. We zagen chunk aantallen met ongeveer 40% toenemen terwijl de totale bundle grootte afnam.

SWC Is nu verplicht

Als je nog steeds aan enige Babel-configuratie vasthield, is dat voorbij. Turbopack gebruikt uitsluitend SWC voor transformatie. Dit was al de richting waarin dingen gingen, maar Next.js 16 verwijdert elke fallback naar Babel volledig.

Build Performance Benchmarks

Hier zijn echte nummers uit onze drie migratieprojecten. Dit zijn geen synthetische benchmarks — ze komen uit echte client applicaties die in onze CI-pijplijn op GitHub Actions (Ubuntu, 4 vCPU, 16GB RAM runners) draaien.

Metriek Project A (E-commerce) Project B (SaaS Dashboard) Project C (Content Site)
Pages/Routes 847 124 2,340
webpack build (Next 15) 4m 32s 1m 48s 6m 15s
Turbopack build (Next 16, cold) 3m 10s 1m 22s 4m 44s
Turbopack build (Next 16, warm cache) 1m 05s 28s 1m 52s
Bundle size change -12% -8% -14%
JS First Load (homepage) -18KB -7KB -22KB
Build memory peak 3.8GB → 2.9GB 1.6GB → 1.2GB 4.2GB → 3.1GB

De warm cache nummers zijn het echte verhaal. Zodra Turbopack je project eenmaal heeft gebouwd, zijn incrementele rebuilds dramatisch sneller. Voor ons content-zware Project C (dat een headless CMS met duizenden statisch gegenereerde pagina's gebruikt), was het gaan van 6+ minuten naar onder de 2 minuten bij gecachede builds significant. Dat is echt geld bespaard op CI-minuten.

Geheugengebruik verbeteringen waren ook betekenisvol. Project A raakte af en toe OOM-fouten op kleinere CI-runners met webpack. Dat probleem verdween met Turbopack.

Next.js 16 Turbopack Production Builds: Wat veranderde en hoe we migreerden - architecture

Breaking Changes die je moet kennen

Hier is een lopende lijst van alles wat daadwerkelijk brak tijdens onze migraties. De Next.js 16 upgrade guide behandelt enkele hiervan, maar een paar verraste ons.

1. Custom Webpack Configuration

Dit is de grote. Als je een webpack sleutel in je next.config.js hebt, werkt het niet meer. Turbopack heeft zijn eigen configuration API onder turbopack in de Next.js config. Niet alles heeft een 1:1 mapping.

// next.config.js — VOOR (Next.js 15 met webpack)
module.exports = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },
};

// next.config.js — NA (Next.js 16 met Turbopack)
module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

2. Synchronous Request APIs Verwijderd

Next.js 15 depreceerde synchrone toegang tot cookies(), headers(), params en searchParams. Next.js 16 verwijdert ze volledig. Als je die deprecation waarschuwingen negeerde, krijg je een moeilijk moment.

// VOOR — dit crasht in Next.js 16
export default function Page({ params }) {
  const { slug } = params;
  return <div>{slug}</div>;
}

// NA
export default async function Page({ params }) {
  const { slug } = await params;
  return <div>{slug}</div>;
}

Dit lijkt triviaal maar raakte meer dan 200 componenten in onze projecten. We schreven een codemod om het meeste ervan af te handelen (meer hierover hieronder).

3. React 18 Niet meer ondersteund

Next.js 16 vereist React 19. Als je dependencies hebt die op React 18 zijn vastgepind, moeten die worden bijgewerkt. De meeste goed onderhouden bibliotheken hadden React 19-ondersteuning tegen midden-2025, maar we troffen wel een paar achtergebleven.

4. Node.js 18 Verwijderd

Minimum is Node.js 20. Update je Docker-images, CI configs en .nvmrc bestanden.

5. next/image Changes

De onLoadingComplete prop wordt volledig verwijderd (was gedepreceerd sinds Next.js 14). Gebruik onLoad in plaats daarvan. De image optimization pipeline gebruikt ook een nieuwe onderliggende bibliotheek, wat betekent dat je gecachede geoptimaliseerde afbeeldingen zullen opnieuw gegenereerd worden op het eerste verzoek.

Ons migratieproces stap voor stap

Hier is het daadwerkelijke proces dat we hebben gevolgd. We deden Project B (kleinste) eerst als een test run, en pakten vervolgens A en C aan.

Stap 1: Audit Dependencies

Voor we iets met Next.js aanraakten, auditten we elke dependency op React 19 en Node.js 20 compatibiliteit. We gebruikten een simpel script:

npx npm-check-updates --target latest --filter '/react|next/'

We controleerden ook handmatig onze meest kritieke packages: onze headless CMS SDK, authentication library en UI component library.

Stap 2: Update Node.js

We hebben onze .nvmrc naar 20.18.0 bijgewerkt (laatste LTS op dat moment), hebben Dockerfiles bijgewerkt en hebben CI runners geverifieerd. Simpel maar gemakkelijk te vergeten.

Stap 3: Upgrade React First

npm install react@19 react-dom@19 @types/react@19 @types/react-dom@19

We voerden hier de volledige testsuite uit voordat we verdergingen. React 19 heeft zijn eigen breaking changes (verwijderde forwardRef als noodzakelijkheid, ref is nu een reguliere prop, use() hook is stabiel). We hebben die problemen in isolatie opgelost zodat we geen React en Next.js problemen tegelijk debuggen.

Stap 4: Voer de Next.js Codemod uit

Next.js biedt een upgrade codemod die veel van de mechanische veranderingen afhandelt:

npx @next/codemod@latest upgrade

Dit handelde ongeveer 70% van de async API migraties automatisch af. Het is niet perfect — het had moeite met enkele van onze complexere server component patronen — maar het bespaarde ons uren.

Stap 5: Upgrade Next.js

npm install next@16

Stap 6: Migreer next.config.js

Dit was de meest tijdrovende stap voor Project A, die aanzienlijke webpack aanpassingen had. Ik behandel de specifieke vertalingen in het volgende gedeelte.

Stap 7: Fix Build Errors Iteratief

We draaiden next build en werkten fouten één voor één door. De foutmeldingen van Turbopack zijn eigenlijk beter dan webpack's in de meeste gevallen — specifieker, met duidelijkere bestandspaden en suggesties.

Stap 8: Visual Regression Testing

We gebruiken Playwright voor E2E tests en draaiden onze visual regression suite om rendering verschillen op te vangen. We vonden twee problemen: een CSS ordeningverschil (Turbopack verwerkt CSS imports in een iets andere volgorde dan webpack) en een dynamic import die niet correct code-splitting deed.

Stap 9: Performance Validation

We hebben Lighthouse scores en Core Web Vitals voor en na vergeleken. Elk project verbeterde of bleef neutraal. Geen regressions.

Webpack Config Vertalingen

Deze sectie is voor teams met custom webpack configs. Hier is hoe veel voorkomende patronen naar Turbopack vertalen.

Custom Loaders

// Turbopack equivalent voor custom loaders
module.exports = {
  turbopack: {
    rules: {
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js',
      },
      '*.graphql': {
        loaders: ['graphql-tag/loader'],
        as: '*.js',
      },
    },
  },
};

Module Aliases

// Resolve aliases werken op dezelfde manier
module.exports = {
  turbopack: {
    resolveAlias: {
      'old-package': 'new-package',
      // Je kunt ook naar lokale bestanden wijzen
      '@legacy/utils': './src/utils/legacy.ts',
    },
  },
};

Wat vertaalt niet

Some webpack plugins hebben eenvoudig geen Turbopack equivalenten nog:

  • webpack.DefinePlugin — Gebruik env in next.config.js of omgevingsvariabelen direct
  • BundleAnalyzerPlugin — Het @next/bundle-analyzer package werkt met Turbopack vanaf v16, maar het output format is veranderd
  • Custom chunk splitting via splitChunks — Turbopack handelt dit automatisch af en biedt niet hetzelfde controle niveau. Eerlijk gezegd zijn de standaarden goed genoeg voor de meeste projecten.
  • webpack.IgnorePlugin — Gebruik resolveAlias om imports naar lege modules te wijzen

Third-Party Packages beheren

Een paar packages veroorzaakten problemen tijdens migratie:

@sentry/nextjs — Vereiste v9+ voor Turbopack compatibiliteit. Eerdere versies haakten in webpack internals. De upgrade was rechtdoorzee maar vereiste config veranderingen.

next-intl — Werkte prima na update naar de nieuwste versie. De plugin API paste schoon aan.

@vanilla-extract/next-plugin — Dit was onze grootste kopzorg op Project B. Vanilla Extract's webpack plugin had geen Turbopack equivalent tot hun 2.0 release. We moesten daarop wachten of alternatieven overwegen. We hebben gewacht.

Barrel file packages — Elk package dat honderden componenten uit een enkel index bestand exporteert (ik kijk naar jou, icon libraries) wordt nu veel aggressiever tree-shaken. Dit is een goed iets, maar we zagen één geval waar een dynamisch-gerefereerde icon niet werd opgenomen. We schakelden van string-gebaseerde icon lookups naar directe imports, wat toch beter practice is.

CSS en Tailwind Overwegingen

Als je Tailwind CSS gebruikt (en de meeste van onze projecten doen dat), is de migratie grotendeels pijnloos. Tailwind v4 werkt prima met Turbopack. Maar er zijn een paar dingen om op te letten:

CSS Import Ordering

Turbopack verwerkt CSS imports op een deterministische maar andere manier dan webpack. Als je op importvolgorde voor specificiteit vertrouwde (en je zou dat niet moeten doen, maar laten we eerlijk zijn — we eindigen daar allemaal soms), kun je visuele verschillen zien. We hadden één project waar een global reset werd overschreven door een component CSS module omdat de importvolgorde omsloeg.

De fix was expliciete @layer gebruik in onze CSS, wat we toch al hadden moeten doen.

CSS Modules

CSS Modules werken identiek. Geen wijzigingen nodig. De gegenereerde klassenamen zien er anders uit (korter, eigenlijk), maar dat is cosmetisch tenzij je iets geks doet zoals gegenereerde klassenamen in tests targeteren.

PostCSS

PostCSS config bestanden worden nog steeds gerespecteerd. Je postcss.config.js werkt verder. Geen wijzigingen nodig hier.

Deployment en CI Pipeline Updates

Onze deployment targets zijn vooral Vercel en AWS (via SST/OpenNext). Dit is wat veranderde:

Vercel: Detecteerde automatisch Next.js 16 en gebruikte Turbopack. Build cache integratie werkt out of the box. Onze build times op Vercel daalden nog dramatischer dan lokale CI omdat Vercel diepe integratie met Turbopack's caching laag heeft. Project C ging van ~8 minuten naar ~2.5 minuten op Vercel.

AWS/OpenNext: Vereiste update naar OpenNext 4.x, wat Turbopack output ondersteuning toevoegde. Het output format veranderde iets — de .next directory structuur is gereorganiseerd — dus enige post-build scripts die naar specifieke bestandspaden verwezen, hadden bijwerking nodig.

Docker builds: Als je Next.js in Docker bouwt, update je base image naar Node 20+ en wees je ervan bewust dat Turbopack's cache directory (.next/cache/turbopack) moet worden opgenomen in je Docker layer caching strategie. We voegden een specifieke COPY laag hiervoor toe.

# Optimaliseer Docker layer caching voor Turbopack
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# Cache mount voor Turbopack
RUN --mount=type=cache,target=/app/.next/cache \
    npm run build

Wanneer je nog NIET moet migreren

Ik wil dit niet als allemaal rozen schilderen. Er zijn legitieme redenen om nu op Next.js 15 te blijven:

  • Heavy webpack plugin afhankelijkheid: Als je build op 3+ custom webpack plugins vertrouwt die geen Turbopack equivalenten hebben, is de migratiekost het misschien niet waard.
  • Monorepo met gedeelde webpack config: Als je webpack config deelt over Next.js en non-Next.js projecten in een monorepo, splitsen van die config is extra werk.
  • Stabiliteit vereisten: Next.js 16.0 is stabiel, maar 16.1 en 16.2 fixten echte bugs. Ik zou wachten op minstens 16.2+ voordat ik iets migreer waar je downtime niet kunt tolereren.
  • Legacy dependencies vast op React 18: Als een kritieke dependency React 19 ondersteuning niet heeft toegevoegd, ben je sowieso geblokkeerd.

Voor teams die headless CMS development doen, is de migratie over het algemeen soepeler omdat CMS-aangestuurde sites meestal eenvoudiger build configuraties hebben.

FAQ

Is Turbopack stabiel genoeg voor production in Next.js 16?

Ja. Turbopack is meer dan drie jaar in ontwikkeling, werd uitgebreid getest in dev mode over miljoen Next.js projecten, en doorliep een verlengde beta in production builds tijdens Next.js 15.3-15.5. We draaien het sinds de 16.0 release in production over meerdere client sites zonder bundler-gerelateerde problemen. Dat gezegd, als je op 16.0 specifiek bent, upgrade naar 16.2+ waar verscheidene edge-case bugs zijn opgelost.

Kan ik nog steeds webpack met Next.js 16 gebruiken?

Niet als primaire bundler, nee. Turbopack is de enige ondersteunde bundler in Next.js 16. Als je absoluut webpack nodig hebt, moet je op Next.js 15 blijven, wat beveiligingspatches ontvangt tot begin 2026. Vercel is duidelijk geweest dat webpack ondersteuning in Next.js voorbij is.

Hoe veel sneller is Turbopack vergeleken met webpack voor production builds?

Bij cold builds (geen cache) zagen we 20-30% verbeteringen. Bij warm/gecachede builds springt de verbetering naar 50-70%. De exacte nummers hangen sterk af van projectgrootte, aantal routes en de hoeveelheid static generation. Geheugengebruik daalde ook consistent 20-30% over onze projecten.

Moet ik mijn next.config.js voor Turbopack herschrijven?

Als je custom webpack configuratie in je next.config.js hebt, ja — die blokken moeten naar het turbopack configuratieformat vertaald worden. Als je alleen standaard Next.js config opties gebruikt (images, redirects, rewrites, env variables), werken die allemaal precies hetzelfde. De migratiepoging is evenredig aan hoeveel custom webpack config je hebt.

Werkt mijn bestaande CI/CD pijplijn met Next.js 16?

Grotendeels ja. De voornaamste dingen om bij te werken zijn: Node.js versie (minimum 20), enige scripts die naar webpack-specifieke output bestanden verwijzen, en enige caching strategieën die .next/cache/webpack targeteren. Je zult .next/cache/turbopack in plaats daarvan willen cachen. Als je naar Vercel deployt, wordt alles automatisch afgehandeld.

Ondersteunt Turbopack alle dezelfde features als webpack in Next.js?

Voor Next.js-specifieke features, ja — App Router, Pages Router, API routes, middleware, ISR, SSG, SSR werken allemaal. Voor custom webpack configuratie is er ongeveer 90% feature pariteit. De resterende hiaten zijn meestal rond niche webpack plugins en zeer custom chunk splitting strategieën. Controleer de Turbopack compatibility docs voor je specifieke use case.

Moet ik naar Next.js 16 migreren of alternatieven als Astro overwegen?

Het hangt af van je use case. Als je highly interactive applications met complex state management bouwt, is Next.js 16 een sterke keuze en maken de Turbopack verbeteringen de DX aanzienlijk beter. Als je content-zware sites met minimale interactiviteit bouwt, blijft Astro een uitstekend alternatief met zijn partial hydration model. We bouwen met beide en kiezen op basis van projectvereisten. Als je niet zeker bent, neem contact met ons op en we kunnen je helpen evalueren.

Wat is de minimum tijd nodig om een medium-sized Next.js 15 app naar 16 te migreren?

Voor een typische medium-sized applicatie (50-200 routes, standaard dependencies, minimale custom webpack config), budget 2-4 dagen developer tijd. Dat bevat dependency updates, async API migraties, testen en deployment verificatie. Als je extensive custom webpack configuratie of legacy dependencies hebt, kan het een week of meer duren. Ons team bij Social Animal biedt migration services aan als je liever je team's sprint niet op infrastructuur werk verbrandt.