Turbopack i Next.js 16: Migreringsguide från Webpack och prestandaoptimering (2026)

Uppdaterad: 30 augusti 2026

Turbopack är den Rust-drivna standardbundlern i Next.js 16 som ersätter Webpack för både next dev och next build. Migreringen handlar i praktiken om tre saker: flytta anpassade loaders till turbopack.rules, översätta resolve.alias till resolveAlias, och validera att de plugins ni haft i webpack-pipelinen har en Turbopack-motsvarighet. Jag har flyttat två produktionsappar den senaste sprinten, och den här guiden är den checklista jag önskar att jag haft från början.

• Turbopack blev standard i Next.js 16 (oktober 2025) och behöver ingen --turbo-flagga längre. Webpack körs bara med --webpack.
• Kallstart är upp till 10x snabbare och HMR svarar i millisekunder oavsett appstorlek, tack vare inkrementell kompilering i Rust.
• Webpack-loaders körs via loader-runner, men bara loaders som returnerar JavaScript stöds. CSS- och bildtransformerare måste hitta nya lösningar.
• resolveAlias ersätter config.resolve.alias, resolveExtensions ersätter resolve.extensions, och rules ersätter module.rules.
• File System Caching (stabilt i 16.1) gör att next build återanvänder tidigare arbete mellan körningar. Kritiskt för CI-tider i stora monorepon.
• Sentry, next-mdx-remote och @svgr/webpack fungerar; anpassade webpack-plugins gör det oftast inte. Planera en avvikelseanalys innan ni tar bort --webpack-fallbacken.

Vad är Turbopack och varför spelar det roll?

Turbopack är en inkrementell bundler skriven i Rust, byggd av samma Vercel-team som ursprungligen skapade Webpack. Det är inte en drop-in-ersättare, utan en helt ny arkitektur som drar nytta av att både SWC (kompilatorn Next.js redan använder istället för Babel) och nu bundlern körs i samma Rust-runtime. Effekten på ett staff-eng-team är märkbar. Varje utvecklare får tillbaka minuter per rebuild, och CI-tiderna sjunker mätbart när next build parallelliserar arbetet över alla tillgängliga kärnor istället för att sitta fast i Node.js single-threaded event loop.

Från vårt perspektiv på design-systemet är det arkitektoniska skiftet lika viktigt som prestandan. Turbopack använder en function-level graph där varje transform cachas per funktion snarare än per fil. När ni ändrar en enskild ikon i UI-paketet behöver Turbopack alltså bara omkompilera just den funktionen, inte hela modulgrafen. Det förändrar hur man tänker på moduldelning i ett monorepo, och det är en av anledningarna till att File System Caching (stabilt i Next.js 16.1) plötsligt är realistiskt istället för teoretiskt.

Ekosystemet rör sig entydigt mot Rust-driven tooling. SWC ersatte Babel, Biome utmanar ESLint och Prettier, och nu tar Turbopack över efter Webpack. Att fortsätta köra på Webpack är fullt möjligt i Next.js 16, men det är en aktiv opt-out, inte det aktiva valet det var i version 14.

Är Turbopack snabbare än Webpack? Riktiga siffror

Ja, för nästan alla arbetsflöden är Turbopack snabbare. Enligt Vercels egna benchmarks och det jag mätt själv i produktion: kallstart är upp till 10x snabbare på stora appar, HMR-uppdateringar landar i millisekunder oavsett antalet moduler, och next build går 2–5x snabbare beroende på appens karaktär. Skillnaden är störst i monorepon med tusentals moduler och minst i små appar där Webpacks JIT-optimeringar redan var effektiva.

Här är en jämförelse baserad på de siffror jag ser i vår SaaS-monorepo (ca 4 200 moduler, 12 route groups):

Mätvärde	Webpack (Next.js 14)	Turbopack (Next.js 16.2)
Kallstart (next dev)	18,4 s	1,9 s
HMR efter komponentändring	1 100–2 400 ms	40–90 ms
Produktionsbuild (next build)	4 min 32 s	1 min 41 s
Byggcache-återanvändning	Kräver Turborepo remote cache	Inbyggd File System Cache
CPU-utnyttjande i CI	1–2 kärnor	Alla tillgängliga kärnor
Minnesförbrukning (peak)	3,8 GB	2,1 GB

Det som inte syns i tabellen: HMR-latensen är den variabel som faktiskt förändrar hur teamet arbetar. När uppdateringen tar 90 ms istället för 2 sekunder slutar utvecklare tabba bort till Slack mellan varje ändring. Vår mätning av "flow state" (definierat som tid mellan spara och nästa spara) gick upp 34 % månaden efter migreringen. Det är den enskilt största vinsten och den syns aldrig i en teknisk changelog.

Så aktiverar du Turbopack i Next.js 16

I Next.js 16 behöver du inte göra någonting. Turbopack är redan standard. Kör bara pnpm dev eller pnpm build som vanligt. Det som är nytt är att du behöver en flagga för att inte använda Turbopack, vilket är omvänt mot 15.x-epoken. Så här ser de tre vanliga kommandona ut i praktiken:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "dev:webpack": "next dev --webpack",
    "build:webpack": "next build --webpack"
  }
}

Rekommendationen från vårt team: behåll dev:webpack och build:webpack som fallback under minst en release-cykel efter migreringen. När CI failar med en obskyr Turbopack-bugg vill ni kunna reproducera på Webpack för att isolera problemet till bundlern istället för till er egen kod.

Om ni har en pipeline som kör next build --experimental-turbo i CI för att förvarna er om regressioner: byt den till next build så snart ni är på 16, och lägg till en separat next build --webpack-körning som referens. På så sätt får ni en direkt jämförelse av bundlestorlekar och byggtider utan att behöva pinga två versioner av Next.js parallellt.

Migrera webpack-konfigurationen till Turbopack

All Turbopack-konfiguration bor under nyckeln turbopack i next.config.js eller next.config.ts. Tre delar täcker de flesta migreringar: rules för loaders, resolveAlias för modulaliases och resolveExtensions för filändelser. Jag går igenom dem i den ordning ni faktiskt kommer stöta på dem när ni migrerar.

Loaders via rules

Turbopack har inbyggt stöd för CSS, PostCSS, SCSS, TypeScript, JSX och moderna JavaScript-features. Så om er tidigare webpack-config bara innehöll css-loader, postcss-loader och babel-loader för @babel/preset-env kan ni ta bort allt. Det som blir kvar är i praktiken bara SVG-till-React-komponenter och MDX. Så här ser en typisk konfiguration ut:

// next.config.ts
import type { NextConfig } from 'next';

const config: NextConfig = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
      '*.mdx': {
        loaders: ['@mdx-js/loader'],
        as: '*.js',
      },
    },
  },
};

export default config;

as-fältet talar om för Turbopack vilken filtyp resultatet ska behandlas som, nästan alltid *.js eftersom Turbopack bara stöder loaders som returnerar JavaScript. Loaders som transformerar stylesheets eller binärdata (till exempel file-loader eller url-loader) fungerar inte. Använd Next.js inbyggda tillgångshantering via import img from './logo.png' istället.

Modulaliases via resolveAlias

Det här är den delen som brukar orsaka mest smärta i en monorepo-migrering. Om ni haft config.resolve.alias = { '@ui': path.resolve(__dirname, 'packages/ui/src') } i er webpack-config, översätt det såhär:

turbopack: {
  resolveAlias: {
    '@ui': './packages/ui/src',
    '@lib': './packages/lib/src',
    // Ersätt hela paket (motsvarar webpack alias-syntax)
    underscore: 'lodash',
    // Villkorlig resolution per miljö
    mocha: { browser: 'mocha/browser-entry.js' },
  },
},

Notera att sökvägarna är relativa strängar. Ni behöver inte path.resolve eller __dirname längre, eftersom Turbopack löser dem relativt next.config.ts. Det gör konfigurationen både kortare och portabel mellan operativsystem.

Filändelser via resolveExtensions

Om ni har anpassade filändelser (till exempel .web.tsx för React Native for Web) kan ni styra Turbopacks resolution-ordning:

turbopack: {
  resolveExtensions: [
    '.web.tsx',
    '.web.ts',
    '.tsx',
    '.ts',
    '.jsx',
    '.js',
    '.mjs',
    '.cjs',
    '.json',
  ],
},

Ordningen spelar roll: Turbopack testar från vänster till höger och tar första träffen. Detaljerad referens finns i next.config.js turbopack-dokumentationen.

Vanliga migreringsfällor och hur du löser dem

Att migrera på pappret är enkelt. Att migrera i verkligheten, med tio års organiskt växt webpack-config och en tredjeparts-Sentry-integration, är det inte. Här är de fällor jag och andra staff-engs har snubblat på det senaste halvåret, i den ordning ni troligen möter dem.

1. Webpack-plugins utan Turbopack-motsvarighet. Turbopack stöder loaders men inte fullständiga webpack-plugins. Det här är faktiskt det största hindret för produktionsmigrering. Om ni har en anpassad BundleAnalyzerPlugin, DefinePlugin för injicering av variabler, eller ett internt bygg-verktyg som hookar in i compilation.hooks, behöver ni en alternativ strategi. För bundle-analys, använd Next.js inbyggda ANALYZE=true next build. För variabelinjicering, använd env-nyckeln i next.config.js istället.

2. Loaders som returnerar icke-JS. Ett vanligt scenario: ni har raw-loader för att importera SQL-schemafiler som strängar. Turbopack stöder det bara om loadern returnerar giltig JavaScript. Byt till att importera filen som en asset (import schema from './schema.sql' ger en URL) och läs innehållet vid runtime, eller flytta konverteringen till ett build-steg utanför Next.js.

3. Options som inte är serialiserbara. Alternativ till webpack-loaders måste vara vanliga JavaScript-primitiver, objekt och arrayer. Ni kan inte skicka in require()-anrop eller funktionsreferenser. Om er loader-konfig gjorde det, extrahera funktionen till en fristående fil och referera den via sträng.

4. CSS-in-JS-bibliotek utan RSC-stöd. Det här är egentligen inte en Turbopack-fråga utan en App Router-fråga, men den yttrar sig först när ni migrerar. styled-components och Emotion behöver serverkomponent-kompatibla versioner (styled-components 6.1+ eller Emotion 11.13+ med explicit "use client"-wrapper). Om ni fortfarande kör äldre versioner får ni hydreringsfel som är svåra att koppla till bundlern.

5. Absoluta importer via jsconfig. Om ni har compilerOptions.paths i tsconfig.json respekterar Turbopack dem redan. Dubbeldeklarera dem inte i resolveAlias, det leder till konflikter där olika delar av bygget löser samma alias till olika sökvägar.

Turbopack i produktion: vad du bör veta

I Next.js 16 är produktionsbygget stabilt och rekommenderat för de flesta appar, men det finns ett par saker att verifiera innan ni tar bort er Webpack-fallback. Först: bundlestorlek. Turbopacks tree-shaking och chunk-splitting är bra men skiljer sig från Webpacks. Jag har sett vissa route-chunks bli 5–10 % större efter migrering och andra bli 10–20 % mindre. Kör ANALYZE=true next build både före och efter, jämför per-route-storlekarna, och validera att era LCP-tunga sidor inte fick sämre bundle.

Sedan: File System Caching. Stabilt sedan 16.1, aktiverat som standard, sparar bygg-artefakter i .next/cache/turbopack. I CI innebär det att ni behöver cacha den katalogen mellan runs. Vår GitHub Actions-config såg ut såhär:

- name: Cache Turbopack
  uses: actions/cache@v4
  with:
    path: |
      .next/cache/turbopack
      .next/cache/webpack
    key: turbopack-${{ hashFiles('pnpm-lock.yaml', 'next.config.ts') }}-${{ github.sha }}
    restore-keys: |
      turbopack-${{ hashFiles('pnpm-lock.yaml', 'next.config.ts') }}-

Cachen invalideras korrekt när dependencies eller next.config.ts ändras, men återanvänds mellan feature-brancher, vilket är exakt det ni vill. På vår sida gick average CI-tid från 6 min 12 s till 2 min 4 s, och det är innan vi ens parallelliserade tester.

Slutligen: middleware och edge runtime. Turbopack kompilerar Edge Middleware och Route Handlers separat från din huvudapplikation, och kompileringen är märkbart snabbare. Vissa Node.js-specifika API:er som fungerade i Webpacks Edge-emulering ger dock nu tydligare felmeddelanden i Turbopack. Det är egentligen en förbättring, men om ni fångar upp nya fel efter migrering är det första stället att titta. Se vår kompletta guide till Next.js Middleware och Edge Runtime för hur ni felsöker sådana problem.

Monorepon och byggcachning i praktiken

Om ni kör Turborepo, pnpm workspaces eller Nx: Turbopack fungerar redan i monorepon utan extra konfiguration, men det finns nyanser som förändrar hur ni bör tänka på cachning. Standardbeteendet är att Turbopack skannar upp trädet efter package.json och sätter workspace-roten där. Om ni har en icke-standard-struktur (till exempel apps/* och services/* parallellt) kan ni pinna roten explicit via turbopack.root:

turbopack: {
  root: __dirname,
  resolveAlias: {
    '@repo/ui': '../../packages/ui/src',
    '@repo/config': '../../packages/config/src',
  },
},

Det viktiga för en monorepo-migrering är att förstå hur Turbopacks File System Cache samspelar med Turborepos remote cache. De löser olika problem. File System Cache accelererar en enskild next build-körning genom att återanvända kompileringsarbete från förra körningen på samma maskin, medan Turborepo remote cache accelererar hela pipelinen genom att hoppa över tasks som redan körts av någon annan. Kombinera båda: låt Turborepo hoppa över build helt när inputsen är oförändrade, och låt Turbopack återanvända partiellt arbete när något faktiskt behöver byggas.

En sista sak vi lärde oss den hårda vägen: när ni har flera Next.js-appar i samma monorepo som delar UI-paket, se till att UI-paketet inte har egna byggsteg (som tsup eller tsc). Låt Turbopack konsumera TypeScript-källan direkt via resolveAlias. Det är snabbare, undviker cache-invalideringsproblem, och gör att ändringar i design-systemet dyker upp i alla appar utan mellansteg. För djupare läsning om cachning i Next.js-appar, se vår guide till Next.js 15 cachning med fetch och revalidateTag. Om ni funderar på hur Turbopack samspelar med streaming och Suspense, kolla också vår guide till Partial Prerendering och Cache Components.

Frågor och svar

Kan Turbopack använda mina befintliga webpack-plugins?

Nej. Turbopack stöder webpack-loaders som returnerar JavaScript via loader-runner, men fullständiga webpack-plugins (som hookar in i compilation.hooks) stöds inte. Vercel har en plugin-API planerad för Q2 2026, men i skrivande stund måste ni ersätta plugin-funktionalitet med Next.js inbyggda motsvarigheter eller köra Webpack som fallback.

Varför är min Turbopack-build långsammare än väntat?

Vanligaste orsaken är att File System Cache inte återanvänds. Kontrollera att .next/cache/turbopack cachas i CI och att ni inte har en rm -rf .next-instruktion i pipelinen. Näst vanligast är att en anpassad loader tvingar Turbopack att spilla över till en långsammare kodväg; kör med NEXT_TURBOPACK_TRACING=1 för att se var tiden går.

Fungerar Turbopack med Storybook och Vitest?

Storybook 8.4+ har en experimentell Turbopack-builder; för produktion rekommenderar de fortfarande Vite. Vitest använder Vite internt och påverkas inte alls av att ni bytt bundler i Next.js. Testerna kör mot källkoden via SWC och struntar i Turbopacks bygg-pipeline.

Behöver jag ändra min TypeScript-konfiguration?

Nej. Turbopack respekterar tsconfig.json-inställningarna inklusive paths, baseUrl, och strict. Undvik att dubbeldeklarera path-mappings i både tsconfig.json och turbopack.resolveAlias. Behåll dem i tsconfig.json så ärver Turbopack automatiskt.

Hur rullar jag tillbaka till Webpack om något går sönder?

Kör next dev --webpack eller next build --webpack. Flaggan finns kvar i Next.js 16 som opt-out och är rekommenderad fallback under en migreringsperiod. Behåll separata dev:webpack- och build:webpack-scripts i package.json minst en release-cykel efter att ni tagit bort Turbopack-flaggan från er huvud-pipeline.