Vor drei Jahren saß ich in einem Call mit einem Kunden in Toronto und schaute zu, wie ein Next.js Build 94 Sekunden lang dahinschleppte, während wir beide so taten, als wäre alles in Ordnung. Webpack. Achttausend Module. Ein Monorepo mit freigegebenen UI-Komponenten, die seit 2021 niemand überprüft hatte. Der Kunde fragte, ob wir es „schneller machen" könnten. Ich kalkulierte zwei Tage Arbeit. Es brauchte vier. Und selbst dann bekamen wir es auf 61 Sekunden runter, was sich anfühlte wie ein Sieg in einem Rennen, das niemand fahren wollte.
Turbopack hat diese Geschichte geändert. Größtenteils. Aber hier 2026 sehe ich immer wieder Entwickler davon ausgehen, dass der Wechsel zu Turbopack eine Zielline ist statt ein Startpunkt. Sie schalten das Flag um, sparen 40% beim Dev-Server Startup und nennen es erledigt. Die echten Engpässe haben sich nur an einen stilleren Ort verschoben.
Also lass mich dich durchgehen, wo die Build-Zeit wirklich hingeht, wenn du Turbopack in einer echten Production Codebase ausführst. Nicht eine Todo-App. Nicht die Next.js-Beispielvorlage. Eine echte Site mit 200+ Routes, einer CMS-Integration und einem Kunden, der jede Sekunde bemerkt.
Die Lücke zwischen Dev-Modus und Production Builds
Hier ist, was die meisten Menschen übersehen: Turbopack's größte Erfolge sind im Dev-Server. Inkrementelle Kompilierung, Caching auf Modulebene, das ganze Rust-gestützte Diagramm. Im Dev-Modus ist es wirklich transformativ. Ich habe einen Cold Start bei einem Seahawk-Kundenprojekt gemessen, der von 28 Sekunden unter Webpack auf unter 4 mit Turbopack ging. Das ist kein Rundungsfehler.
Aber next build ist ein anderes Kaliber. Ab Anfang 2026 ist Turbopack's Production-Build-Unterstützung stabil, schreibt aber nicht die gesamte Pipeline neu. Statische Analyse, Page-Optimierung und der SWC Compiler leisten alle noch schwere Arbeit neben Turbopack's Bundler. Du bekommst keine einheitliche 10x bei Production Output.
Das ist wichtig, weil Entwickler die falschen Dinge vergleichen. Sie sehen next dev starten und schließen daraus, dass der Build schnell ist. Dann braucht CI 3 Minuten und sie zucken mit den Schultern.
Was die Turbopack-Architektur wirklich tut
Turbopack arbeitet nach einem nachfragegesteuerten Berechnungsmodell. Es erstellt nur das, was angefordert wird, zwischenspeichert auf Modulebene und invalidiert präzise statt breit. Deshalb spricht das Vercel-Team in seinem Architektur-Writeup von „Function-Level-Memoisation". Es ist kein Marketing-Text. Es ist der echte Mechanismus dahinter, warum das Ändern einer Komponente keine vollständige Re-Bundling erzwingt.
Die Implikation: Deine schnellsten Gewinne entstehen dort, wo die Invalidierung vorher zu breit war. Freigegebene Utility-Dateien, große Barrel-Exporte, tief verschachtelte Re-Exporte. Das sind die Stellen, an denen Webpack dich stillschweigend bestraft hat.
Wo die Zeit 2026 wirklich verschwindet
Ich habe letztes Quartal vier Codebasen mit NEXT_TURBOPACK_TRACING=1 überprüft. Ja, diese Umgebungsvariable existiert und ja, sie spuckt eine Trace-Datei aus, die du in Chromes Performance Panel laden kannst. Ich empfehle dir das dringend, bevor du davon ausgehst, dass etwas Bestimmtes der Schuldige ist.
Hier ist, was ich gefunden habe, grob nach Häufigkeit sortiert:
- Barrel-Datei-Explosionen. Eine einzelne
index.ts, die 60 Komponenten aus einem Design System re-exportiert, zieht jede dieser Module in den Graph, selbst wenn du zwei verwendest. Turbopack handhabt das besser als Webpack, aber das Problem verschwindet nicht. Die Lösung sind granulare Imports. Immer. - Type-Checking nicht von Bundling getrennt. Das Ausführen von
tsc --noEmitin der gleichen Build Pipeline, die Turbopack verarbeitet, verdoppelt deine Wall Time. Trenne sie. TypeScript Type-Checking und Turbopack Bundling sollten parallel Aufträge in CI sein, nicht sequentielle Schritte. - Instabile Modul-IDs in Drittanbieter-Paketen. Einige npm-Pakete liefern immer noch CommonJS mit dynamischen Requires aus. Turbopack muss auf langsamere Analysepfade zurückgreifen. Das ist mir letzten Monat mit einer älteren Version einer PDF-Generierungsbibliothek passiert. Nach dem Update habe ich 8 Sekunden eingespart.
- Bildoptimierung zur Build-Zeit. Wenn Sie Tausende von Bild-Varianten mit
next/imageund statischem Export vorab generieren, ist das synchron und CPU-gebunden. Es liegt nicht an Turbopack. Aber es taucht in der Build-Trace auf und die Leute geben dem Bundler die Schuld. - Große `getStaticProps`-Daten-Payloads. Das Abrufen von 4MB CMS-Daten pro Seite während des Builds über 300 Seiten hinweg ist ein Netzwerk- und Parsing-Problem. Wieder nicht Turbopack. Aber es sitzt in demselben 180-Sekunden-Build und wird kollektiv beschuldigt.
Die unbequeme Wahrheit ist, dass Turbopack die Bundling-Phase so sehr beschleunigt hat, dass alles andere jetzt im Vergleich dazu langsam aussieht. Es ist wie das Upgrade Ihres Küchenmülleimers auf automatisches Öffnen und dann die Feststellung, dass der Weg zur Mülltonne draußen das eigentliche Problem ist.
Das Barrel-File-Problem verdient einen eigenen Abschnitt
Ich kann das nicht genug betonen. Barrel Files sind die häufigste selbst verursachte Build-Wunde, die ich bei Agenturen sehe.
Ein Kunde kam Ende 2025 mit einer Component Library zu uns, die diese Struktur hatte:
`` components/ index.ts (exports 140 named components) ``
Jede Seite, die auch nur einen Button importiert, hat den gesamten Graph aus 140 Komponenten gezogen. Mit Webpack half Tree-Shaking teilweise zur Ausgabezeit. Mit Turbopack musste der Modul-Graph trotzdem durchlaufen und verstanden werden, bevor etwas entfernt werden konnte. Der Dev-Server war nicht per se langsam, aber Cold Starts waren schmerzhaft.
Wir haben es zu pfadspezifischen Imports umstrukturiert:
`` import { Button } from '@company/ui/button' import { Modal } from '@company/ui/modal' ``
Cold Dev Start fiel von 11 Sekunden auf unter 3. Production Build um 22 Sekunden gekürzt. Niemand hat Turbopack-Config angefasst. Der Fix war einfach... nicht faul bei Imports zu sein.
Es gibt tatsächlich eine gute eslint-plugin-import Regel dafür: import/no-barrel-files. Fügen Sie sie Ihrer Lint-Config hinzu und behandeln Sie Verstöße als Build-Schulden.
Caching in CI: Sie lassen wahrscheinlich 40 Sekunden liegen
Turbopack's lokales Caching ist ausgezeichnet. CI-Caching ist ein separates Problem und die meisten Teams richten es einmal ein und überprüfen es nie wieder.
Der Turbopack-Cache befindet sich standardmäßig in .next/cache/turbopack. Wenn Ihre CI-Pipeline (GitHub Actions, CircleCI, was auch immer) dieses Verzeichnis nicht zwischen Läufen speichert, führen Sie jedes Mal einen vollständigen Cold Build durch. Bei einer Codebasis in angemessener Größe sind das 30 bis 60 Sekunden reine Verschwendung pro Lauf.
So sieht ein ordentlicher Cache-Schlüssel für ein Next.js + Turbopack Setup in GitHub Actions aus:
- Cache-Schlüssel: Hash von
package-lock.json+ Hash vonnext.config.js+ Hash vontsconfig.json - Cache-Pfad:
.next/cache - Restore-Schlüssel: Fallback zum vorherigen Cache auf demselben Branch, dann main
Das ist alles. Die meisten Teams hashen nur package-lock.json. Aber wenn Ihre next.config.js die Turbopack-Konfiguration ändert (experimentelle Funktionen, Modul-Aliase, Custom Loader), möchten Sie das invalidieren. Ich habe Bugs gesehen, bei denen ein veralteter Cache nach einer Konfigurationsänderung falsche Modul-Resolutionen lieferte. Unangenehm zu debuggen um 23 Uhr.
Seahawk hatte ein Fintech-Projekt, bei dem nur die Reparatur der Cache-Schlüssel-Struktur den durchschnittlichen CI-Build von 4 Minuten 20 Sekunden auf 2 Minuten 50 Sekunden reduzierte. Gleicher Code. Gleiche Hardware. Nur intelligentere Cache-Invalidierung.
Custom Loader und warum sie Ihre Gewinne zerstören
Turbopack unterstützt Custom Loader, aber es gibt einen Preis. Jeder Custom Loader wirft Sie aus Turbopacksschnellem nativem Pfad hinaus und in eine Kompatibilitätsschicht. Das Vercel-Team ist dazu ziemlich ehrlich in der Next.js Turbopack-Konfigurationsdokumentation.
Ich sehe das am häufigsten bei:
- SVG-Loader (Tools zum Konvertieren von SVGs in React-Komponenten zur Build-Zeit)
- MDX mit umfangreichen remark/rehype-Plugin-Ketten
- CSS Modules mit benutzerdefinierten PostCSS-Konfigurationen, die selten genutzte Plugins enthalten
Bei SVGs sollte der Standard 2026 darin bestehen, deine Icon-Library als separaten Build-Schritt zu React-Komponenten vorzukompilieren, nicht zur Next.js Build-Zeit. SVGR ist dafür als eigenständiges Script hervorragend geeignet. Führe es aus, wenn sich deine Design Tokens ändern, committe das Ergebnis und lass Turbopack sie als normale .tsx-Dateien behandeln.
MDX ist kniffliger. Wenn du 40 remark-Plugins laufen lässt, wirst du das merken. Überprüfe, welche du wirklich brauchst. Ich habe Codebases gesehen, die remark-gfm, remark-smartypants, ein benutzerdefiniertes Footnotes-Plugin und zwei weitere laufen lassen, wobei nur zwei davon sichtbare Unterschiede im Output produzierten. Streiche die ungenutzten.
Die Module Resolution Tax, über die niemand spricht
Path Aliases. Jeder nutzt sie. @/components, @/lib, ~/utils. Sie sind praktisch. Sie sind aber auch eine kleine Tax, die sich ansammelt.
Turbopack löst Aliases bei jedem Import auf. In einer großen Codebase mit 4.000 Imports und 12 konfigurierten Aliases sind das 48.000 Resolution-Operationen pro Build. Nicht katastrophal. Aber auch nicht kostenlos.
Die Lösung ist nicht, Aliases zu entfernen. Sie müssen präzise sein. Vermeide Wildcard-Alias-Muster, wenn ein spezifischer Pfad ausreicht. Und halte deine tsconfig.json paths mit deiner next.config.js turbopack resolveAlias config synchron. Abweichungen zwischen diesen beiden führen dazu, dass Turbopack redundante Resolution-Arbeiten durchführt. Ich habe allein durch das Aufräumen hier 4–5 Sekunden Ersparnis gesehen.
Was Turbopack 2026 immer noch nicht tut
Mir gefällt Turbopack. Wir nutzen es bei den meisten neuen Seahawk-Projekten. Aber Ehrlichkeit ist wichtig.
- Bundle-Analyse ist nicht so ausgereift wie das Webpack-Ökosystem.
@next/bundle-analyzerfunktioniert, aber die Visualisierung ist weniger detailliert als das, was du vonwebpack-bundle-analyzerbekommen würdest. Das verbessert sich, aber wir sind noch nicht da. - Das Plugin-Ökosystem ist kleiner. Wenn dein Stack auf stark angepassten Webpack-Plugins angewiesen ist (einige Legacy-Enterprise-Setups tun das), ist die Migration immer noch ein echtes Projekt, nicht eine Angelegenheit eines Nachmittags.
- Die Windows-Performance lag historisch hinter macOS und Linux zurück. Das verbessert sich mit jedem Next.js Release, aber wenn dein Team Windows-lastig ist, benchmark, bevor du dich festlegst.
Keine dieser Punkte sind Dealbreaker. Aber sie sind echte Überlegungen, wenn du evaluierst, ob du ein bestehendes Projekt migrieren oder von vorne anfangen solltest.
Wie du deinen Build wirklich nachverfolgst
Höre auf zu raten. Führe das aus:
- Setze
NEXT_TURBOPACK_TRACING=1in deiner Umgebung - Führe
next buildaus (odernext dev, wenn du den Dev-Startup profilest) - Öffne
.next/tracein der Perfetto UI oder Chromeschrome://tracing - Filtere nach Dauer. Alles über 2 Sekunden in einem einzelnen Modul ist eine Untersuchung wert.
Das ist der gleiche Ansatz, den ich vor jedem Build-Optimierungs-Engagement nutze. Der Trace zeigt dir, wo die Zeit hingeht. Alles andere ist Raterei, die sich als Expertise ausgibt.
---
FAQ
Ist Turbopack 2026 stabil genug für Production Builds?
Ja, die Production-Build-Unterstützung landete Ende 2024 als stabil und hat sich durch 2025 erheblich weiterentwickelt. Für die meisten neu gestarteten Next.js-Projekte würde ich standardmäßig Turbopack ohne Zögern nutzen. Für Legacy-Projekte mit umfangreicher Webpack-Anpassung mache erst einen Spike und messe.
Ersetzt Turbopack SWC?
Nein. SWC ist der TypeScript- und JSX-Transpiler. Turbopack ist der Bundler. Sie arbeiten zusammen. Turbopack nutzt SWC unter der Haube für die Transformation. Du wählst nicht zwischen ihnen.
Warum ist mein Turbopack-Dev-Server schnell, aber der CI-Build immer noch langsam?
Fast sicher einer dieser Gründe: Type-Checking läuft seriell mit dem Bundling, kein CI-Cache für .next/cache konfiguriert, oder Image-Optimierung dominiert die Static-Generation-Phase. Führe den Trace aus. Er zeigt dir, welcher es ist.
Sollte ich ein bestehendes Webpack-Projekt jetzt zu Turbopack migrieren?
Wenn es ein Greenfield- oder Low-Customisation-Projekt ist, ja. Wenn du 15 benutzerdefinierte Webpack-Plugins und eine komplexe Loader-Chain hast, plane einen richtigen Migrations-Sprint ein. Mach es nicht als Afterthought an einem Freitagmittag. (Das sage ich aus persönlicher Erfahrung. Frag nicht nach dem Freitag.)
Funktioniert Turbopack mit Nx oder Turborepo Monorepos?
Ja, und eigentlich ganz gut. Turborepo-Caching lagert sich schön auf Turbopack's internem Caching auf, und die beiden Tools teilen ihre Herkunft vom gleichen Team. Die Kombination ist wirklich gut für große Monorepos, wo sich nur eine Teilmenge der Pakete pro PR ändert.
---
Build-Tooling ist langweilig, bis deine CI-Rechnung 800 Dollar pro Monat beträgt und dein Dev-Team sich bei standup über kalte Starts beschwert. Turbopack hat den Engpass verschoben, was Fortschritt ist. Aber es hat nicht die Notwendigkeit eliminiert, klar zu durchdenken, wo die Zeit vergeht. Trace zuerst. Optimiere zweite. Und um alles in der Welt, fix deine Barrel Files.