We hebben Turbopack sinds de aankondiging in 2022 zien groeien, voerden het sinds Next.js 14 uit in dev mode, en keken voorzichtig naar die "turbo" flags in CI. Toen Next.js 16 begin 2025 werd uitgebracht met Turbopack als de standaard production bundler, wisten we dat de migratie niet langer kon wachten. We hadden drie klantprojecten op Next.js 15 die een upgrade nodig hadden, en ik zal je door elke significante verandering heen leiden, de problemen die we tegenkwamen, en de prestatiecijfers die we aan de andere kant zagen.

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

Inhoudsopgave

Next.js 16 Turbopack Production Builds: What Changed and How We Migrated

Waarom Next.js 16 een grote zaak is

Next.js 16 is niet zomaar een versiebumpje. Het vertegenwoordigt de meest significante verandering in de build-infrastructuur sinds het framework van pages naar de App Router is overgestapt. Het koppelingsfunctiepunt is duidelijk: Turbopack vervangt webpack als de standaard bundler voor zowel development als production builds.

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

  • React 19 als minimaal ondersteunde versie — geen React 18 compatibiliteit meer
  • Verbeterde streaming en partial prerendering volwassenheid
  • Nieuwe caching standaardwaarden die daadwerkelijk logisch zijn (ze hebben geleerd van de backlash tegen Next.js 15 caching)
  • Async request APIs volledig afgedwongen — cookies(), headers(), en params zijn nu allemaal async zonder enige legacy sync ondersteuning
  • Node.js 20 minimumvereiste — Node 18 ondersteuning is weg

Voor bureaus zoals het onze die Next.js development doen, is dit het soort release dat alles raakt. Je kunt niet zomaar een versienummer bumpen en het hierbij laten.

Wat daadwerkelijk veranderd is met Turbopack in Production

Laten we specifiek worden. Tijdens Next.js 14 en 15 was Turbopack beschikbaar voor next dev met de --turbo flag. Production builds gebruikten nog steeds webpack. Next.js 15.3 introduceerde een experimentele --turbopack flag voor next build, en tegen de tijd dat 16 werd uitgebracht, werd het de standaard.

Dit is wat fundamenteel anders is in hoe Turbopack production builds verwerkt vergeleken met webpack:

Incremental Compilation Architecture

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

Tree Shaking Verbeteringen

Turbopack's tree shaking werkt op een meer granulaire niveau dan webpack's. We merkten dat onze klantenbundles gemiddeld 8-15% kleiner waren zonder code wijzigingen. De grootste winsten kwamen van barrel file handling — Turbopack is echt beter in het elimineren van ongebruikte re-exports van index bestanden.

Module Resolution

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

Code Splitting Strategie

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

SWC Is Nu Verplicht

Als je nog ergens aan Babel configuratie vasthield, is het weg. 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 getallen van onze drie migratie projecten. Dit zijn geen synthetische benchmarks — dit zijn van echte klantapplicaties die in onze CI pipeline 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, koud) 3m 10s 1m 22s 4m 44s
Turbopack build (Next 16, warme cache) 1m 05s 28s 1m 52s
Bundle grootte verandering -12% -8% -14%
JS First Load (homepage) -18KB -7KB -22KB
Build geheugen piek 3.8GB → 2.9GB 1.6GB → 1.2GB 4.2GB → 3.1GB

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

Geheugengebruik verbeteringen waren ook betekenisvol. Project A liep soms tegen OOM fouten aan op kleinere CI runners met webpack. Dit probleem verdween met Turbopack.

Next.js 16 Turbopack Production Builds: What Changed and How We Migrated - 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 Configuratie

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

// 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. Synchrone Request APIs Verwijderd

Next.js 15 verouderde synchrone toegang tot cookies(), headers(), params, en searchParams. Next.js 16 verwijdert ze volledig. Als je die deprecation waarschuwingen negeerde, gaat het niet goed met je.

// 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 het raakte meer dan 200 componenten in onze projecten. We schreven een codemod om het meeste ervan af te handelen (meer daarover hieronder).

3. React 18 Wordt Niet Meer Ondersteund

Next.js 16 vereist React 19. Als je afhankelijkheden aan React 18 vastgepind hebt, moeten ze worden bijgewerkt. De meeste goed onderhouden bibliotheken hadden React 19 ondersteuning tegen mid-2025, maar we kwamen wel een paar hardnekkige exemplaren tegen.

4. Node.js 18 Verwijderd

Minimum is Node.js 20. Werk je Docker images, CI configs en .nvmrc bestanden bij.

5. next/image Wijzigingen

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

Ons migratieproces stap voor stap

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

Stap 1: Audit Afhankelijkheden

Voor we Next.js aanraakten, controleerden we elke afhankelijkheid op React 19 en Node.js 20 compatibiliteit. We gebruikten een eenvoudig script:

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

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

Stap 2: Update Node.js

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

Stap 3: Upgrade React Eerst

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

We hebben de volledige test suite hier uitgevoerd voordat we verder gingen. React 19 heeft zijn eigen breaking changes (verwijderde forwardRef als noodzaak, ref is nu een normale prop, use() hook is stabiel). We hebben deze problemen geïsoleerd opgelost zodat we niet tegelijkertijd React en Next.js problemen debuggen.

Stap 4: Voer de Next.js Codemod uit

Next.js biedt een upgrade codemod die veel van de mechanische wijzigingen verwerkt:

npx @next/codemod@latest upgrade

Dit verwerkte ongeveer 70% van de async API migraties automatisch. Het is niet perfect — het worstelde met enkele van onze meer complexe server component patronen — maar het bespaard ons uren.

Stap 5: Upgrade Next.js

npm install next@16

Stap 6: Migreer next.config.js

Dit was de meest tijd kostende stap voor Project A, die aanzienlijke webpack aanpassingen had. Ik behandel de specifieke vertalingen in de volgende sectie.

Stap 7: Repareer Build Fouten Iteratief

We voerden next build uit 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 voerden onze visual regression suite uit om rendering verschillen op te vangen. We vonden twee problemen: een CSS volgorde verschil (Turbopack verwerkt CSS imports in een iets andere volgorde dan webpack) en een dynamic import die niet correct code-splitting.

Stap 9: Performance Validatie

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

Webpack Config Vertalingen

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

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 verwijzen
      '@legacy/utils': './src/utils/legacy.ts',
    },
  },
};

Wat Niet Vertaalt

Sommige webpack plugins hebben gewoon geen Turbopack equivalenten (nog):

  • webpack.DefinePlugin — Gebruik env in next.config.js of omgevingsvariabelen direct
  • BundleAnalyzerPlugin — Het @next/bundle-analyzer pakket werkt met Turbopack vanaf v16, maar de output format veranderde
  • Custom chunk splitting via splitChunks — Turbopack verwerkt dit automatisch en stelt niet hetzelfde niveau van controle bloot. Eerlijk gezegd zijn de defaults goed genoeg voor de meeste projecten.
  • webpack.IgnorePlugin — Gebruik resolveAlias om imports naar lege modules te verwijzen

Third-Party Packages Hanteren

Een paar pakketten veroorzaakten problemen tijdens migratie:

@sentry/nextjs — Had v9+ nodig voor Turbopack compatibiliteit. Eerdere versies haakten zich in webpack internals in. De upgrade was eenvoudig maar vereiste config wijzigingen.

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 pakket dat honderden componenten van één index bestand exporteert (kijkend naar jou, icon bibliotheken) krijgt nu veel agressiever tree-shaken. Dit is een goed ding, maar we zagen één geval waar een dynamisch gerefereerde icon niet werd opgenomen. We stapten over 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), is de migratie meestal pijnloos. Tailwind v4 werkt geweldig met Turbopack. Maar er zijn een paar dingen om op te letten:

CSS Import Volgorde

Turbopack verwerkt CSS imports in een deterministische maar andere volgorde dan webpack. Als je vertrouwt op import volgorde voor specificiteit (en je zou dat niet moeten doen, maar laten we eerlijk zijn — we eindigden daar allemaal soms), zie je misschien visuele verschillen. We hadden één project waar een globale reset door een component CSS module werd overschreven omdat de import volgorde fliptde.

De fix was expliciet @layer gebruik in onze CSS, wat we allemaal al moeten doen.

CSS Modules

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

PostCSS

PostCSS config bestanden worden nog steeds gerespecteerd. Je postcss.config.js blijft werken. Geen wijzigingen nodig hier.

Implementatie en CI Pipeline Updates

Onze deployment doelen zijn primair 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 tijden op Vercel lieten nog dramatischer verbeteringen zien 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, die Turbopack output ondersteuning toevoegde. De output format veranderde iets — de .next directory structuur is gereorganiseerd — dus elk post-build script dat specifieke bestandspaden refereerde moest worden bijgewerkt.

Docker builds: Als je Next.js in Docker bouwt, update je base image naar Node 20+ en zorg dat Turbopack's cache directory (.next/cache/turbopack) in je Docker layer caching strategie is opgenomen. 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 zou moeten migreren

Ik wil dit niet als alleen rooskleurig neerzetten. Er zijn legitieme redenen om voorlopig op Next.js 15 te blijven:

  • Zware webpack plugin afhankelijkheid: Als je build op 3+ custom webpack plugins vertrouwt die geen Turbopack equivalenten hebben, is de migratiekost misschien niet waard.
  • Monorepo met gedeelde webpack config: Als je webpack config deelt tussen Next.js en niet-Next.js projecten in een monorepo, is het splitsen van die config extra werk.
  • Stabiliteitsvereisten: Next.js 16.0 is stabiel, maar 16.1 en 16.2 hebben echte bugs gefixed. Ik zou wachten op minstens 16.2+ voordat ik iets migreer waarop je downtime niet kunt tolereren.
  • Erfenisafhankelijkheden vastgelopen op React 18: Als een kritieke afhankelijkheid geen React 19 ondersteuning heeft toegevoegd, ben je geblokkeerd ongeacht.

Voor teams die headless CMS development doen, is de migratie in het algemeen soepeler omdat CMS-gestuurd sites neigen naar eenvoudiger build configuraties.

Veelgestelde vragen

Is Turbopack stabiel genoeg voor production in Next.js 16? Ja. Turbopack is meer dan drie jaar in ontwikkeling geweest, werd grondig getest in dev mode op miljoenen Next.js projecten, en ging door een uitgebreide beta in production builds tijdens Next.js 15.3-15.5. We draaien het sinds de 16.0 release in production op meerdere klant sites zonder bundler gerelateerde problemen. Dat gezegd hebbende, als je op 16.0 bent, upgrade naar 16.2+ waar enkele edge-case bugs zijn opgelost.

Kan ik webpack nog steeds gebruiken met Next.js 16? Niet als primary bundler, nee. Turbopack is de enige ondersteunde bundler in Next.js 16. Als je webpack absoluut nodig hebt, moet je op Next.js 15 blijven, die security patches krijgt tot begin 2026. Vercel is duidelijk geweest dat webpack ondersteuning in Next.js voorbij is.

Hoeveel sneller is Turbopack vergeleken met webpack voor production builds? Op koude builds (geen cache) zagen we 20-30% verbeteringen. Op warme/gecachde builds springt de verbetering naar 50-70%. De exacte getallen hangen sterk af van project grootte, aantal routes, en de hoeveelheid statische generatie die gebeurt. Geheugengebruik daalde ook consistent 20-30% over onze projecten.

Moet ik mijn next.config.js herschrijven voor Turbopack? Als je custom webpack configuratie in je next.config.js hebt, ja — deze blokken moeten naar het turbopack configuratie format worden vertaald. Als je alleen standaard Next.js config opties gebruikt (images, redirects, rewrites, env variabelen), werken die allemaal precies hetzelfde. De migratie inspanning is evenredig met hoeveel custom webpack config je hebt.

Zal mijn bestaande CI/CD pipeline werken met Next.js 16? Grotendeels ja. De belangrijkste dingen om bij te werken zijn: Node.js versie (minimum 20), scripts die webpack-specifieke output bestanden refereren, en caching strategieën die .next/cache/webpack als doel hebben. Je wilt .next/cache/turbopack in plaats daarvan cachen. Als je naar Vercel deployt, is alles automatisch afgehandeld.

Ondersteunt Turbopack alle dezelfde functies als webpack in Next.js? Voor Next.js-specifieke functies, ja — App Router, Pages Router, API routes, middleware, ISR, SSG, SSR allemaal werken. Voor custom webpack configuratie, er is ongeveer 90% feature pariteit. De resterende gaten gaan grotendeels om 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 zoals Astro overwegen? Het hangt af van je use case. Als je zeer interactieve applicaties met complexe state management bouwt, is Next.js 16 een sterke keuze en de Turbopack verbeteringen maken 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 onzeker bent, neem contact met ons op en we kunnen je helpen evalueren.

Hoeveel minimumtijd is nodig om een middelgrote Next.js 15 app naar 16 te migreren? Voor een typische middelgrote applicatie (50-200 routes, standaard afhankelijkheden, minimale custom webpack config), budget 2-4 dagen entwickelaar tijd. Dit omvat dependency updates, async API migraties, testing en deployment verificatie. Als je uitgebreide custom webpack configuratie of erfenis afhankelijkheden hebt, kan het een week of meer duren. Ons team bei Social Animal biedt migratieservices als je liever niet je team's sprint op infrastructuur werk wilt branden.