Ein statischer Import entscheidet, ob ein Modul im ersten JavaScript-Paket landet, das der Browser laden muss — egal, ob der Nutzer die Komponente je sieht. In Next.js 16.4 macht Vercel diese Entscheidung einem KI-Agenten zugänglich: Er fragt den Modulgraph von Turbopack ab und trennt Importketten gezielt auf. Wie der Analyzer arbeitet, was der Agent in den Apps von Vercel gefunden hat und wo du in deinem Projekt ansetzen kannst — darum geht es hier.
Jede statische Import-Beziehung ist wie ein Rohr, das dauerhaft unter Druck steht. Auch in den Raum, den niemand betritt, fließt Wasser, sobald der Haupthahn offen ist. Bundle-Analyse setzt Ventile an den richtigen Stellen.
Vom Turbopack Bundle Analyzer zum Agent-Skill in Next.js 16.4
Die erste Version des Turbopack Bundle Analyzer erschien in Next.js 16.1 und zeigte die Zusammensetzung der clientseitigen Bundles. Mit 16.4 kommt ein Skill namens next-bundle-optimizer hinzu, der dem Agenten Zugriff auf den detaillierten Modulgraph gibt. Voraussetzung ist Turbopack, seit Next.js 16 der Standard-Bundler — ohne dessen Graph bleibt die Analyse an der Oberfläche.
Die Einrichtung ist simpel: Upgrade auf 16.4, Skill hinzufügen, im Agenten mit /next-bundle-optimizer starten. Der Agent bekommt damit keine vagen Heuristiken, sondern die tatsächlichen Import- und Chunk-Beziehungen deiner App. Klassische Größenberichte sagen nur, dass ein Paket groß ist — nicht, warum es geladen wird.
Wie der Agent Importketten im Modulgraph verfolgt
Das Muster ist so einfach wie ärgerlich. Angenommen, du kapselst eine schwere Komponente in einen Lazy-Loader, damit sie erst bei Bedarf nachgeladen wird. Ist dieser Loader der einzige Importeur, greift die Verzögerung. Importiert aber irgendein anderes Modul im selben Bundle die Komponente statisch, landet der Code trotzdem im initialen Payload. Das Ventil ist eingebaut, nur führt parallel ein zweites Rohr daran vorbei.
Um solche Fälle zu finden, exportiert der Skill die gespeicherten next analyze-Snapshots als JSON und rekonstruiert daraus den Modul- und Chunk-Graph von Turbopack, sodass der Agent ihn abfragen kann. Für eigene Werkzeuge gibt es next analyze export. Der Agent sucht anschließend große Gruppen zusammenhängender Module, bewertet ihren Anteil am Bundle und verfolgt ihre Importketten zurück.
Für die eigentliche Entscheidung nutzt er einen Schnitt durch den Graphen — Vercel nennt es Minimum Cut. Gesucht wird eine möglichst kleine Menge von Importgrenzen, hinter denen sich viele Module gleichzeitig abtrennen lassen. Ein einzelnes Ventil, das einen ganzen Flügel absperrt, statt zwanzig kleine Hähne an einzelnen Leitungen. Bevor der Agent etwas vorschlägt, prüft er die Änderung gegen den Quellcode und gegen die Frage, wie die Komponente interaktiv verwendet wird — eine Verzögerung, die eine Funktion kaputt macht, wäre kein Gewinn.
Was der Agent bei v0 und vercel.com gefunden hat
Vercel hat das Skill auf die Frontend-Codebasis von v0 und vercel.com angesetzt und die Ergebnisse veröffentlicht. In v0 fand der Agent einen experimentellen Code-Editor, der auf nahezu jeder Seite eager geladen wurde — auch für Nutzer, die nicht Teil des Experiments waren. Das kostete rund 150 KB pro Seite. Eine zentrale Dialog-Registry lud mehrere schwere Dialog-Komponenten vorab und verursachte je nach Route zwischen 40 und 650 KB. Ein ungenutzter Trace-Viewer war über die meisten Routenmodule erreichbar und schlug mit 7 bis 61 KB zu Buche.
Auf vercel.com trafen die Analysen ähnliche Muster: Markdown-Rendering, Syntax-Highlighting und Chart-Zeichnung für den Vercel Agent wurden ausgeliefert, obwohl das Agent-Panel gar nicht geöffnet war — 255 KB auf dem Dashboard. Eine schwere Bibliothek zur natürlichsprachlichen Datumsverarbeitung lud im Schnitt 55 KB, bevor der Nutzer mit dem Assistenten interagiert hatte. Und URL-Parsing-Code kam über eine geteilte Utility-Datei herein, die nebenbei die komplette Observability-Query-Engine mitzog: 125 KB auf der Deployments-Seite.
Insgesamt beziffert Vercel die Einsparung auf knapp zwei Megabyte komprimiertes JavaScript über beide Apps — teils durch Entfernen, teils durch Verschieben in einen späteren Ladezeitpunkt. Der Ablauf war jedes Mal derselbe: Der Agent öffnete einen Pull Request pro Änderung, das Team prüfte den Fix auf einem Preview-Deployment und lieferte ihn aus. Die letzte Entscheidung blieb beim Team.
Bundle-Analyse für Menschen: Routen-Ranking, Tabelle und Snapshot-Diff
Parallel zum Agenten hat Vercel die interaktive Oberfläche ausgebaut, die du mit next analyze im Projektverzeichnis startest. Neu ist eine Startseite, die deine größten Client-Routen nach Größe sortiert. Von dort öffnest du eine Route und sortierst die Tabelle nach Größe, um die größten Beiträger zu finden.
Im Beispiel einer Blog-Route listet die Tabelle Einträge wie components/code-block.tsx mit 22 kB im Initial Load, components/search.tsx mit 18 kB auf initialen und asynchronen Pfaden und den Markdown-Parser mit 14 kB hinter einer async boundary. Pakete lassen sich aufklappen, um einzelne Module zu prüfen. Die Summe von 123 kB komprimiert ist illustrativ. Sie zeigt aber, worauf es ankommt: ein Dutzend Posten, von denen jeder eine eigene Entscheidung über den Ladezeitpunkt erlaubt.
Dazu kommen automatisch gespeicherte Snapshots. Du kannst zwei Analysen vergleichen und siehst in der Diff-Ansicht, welche Quellen zu- oder abgenommen haben. Im Beispiel sinkt die Route von 123 auf 81 kB, wobei der Layout-Zuwachs von 4 kB gegen Einsparungen bei Code-Block, Suche und Parser aufgerechnet wird. Solche Diffs sind auch nützlich, wenn niemand optimiert: Sie zeigen, welcher Pull Request das Bundle unbemerkt hat wachsen lassen.
React Server Components und der kritische Renderpfad
Der Agent sucht nach überflüssigen Importen und nach Logik, die auf dem Server besser aufgehoben wäre. Vercel nennt das Verschieben von Logik in React Server Components als eines der Muster, die das Skill erkennt — zusammen mit doppelten Versionen großer Abhängigkeiten und Fällen, in denen Tree Shaking nicht greifen konnte und ungenutzter Code mitkam. Das sind typische Folgen einer Codebasis, die über Monate gewachsen ist.
Für die manuelle Arbeit ist im Treemap ein Filter hinzugekommen, der nur den Initial Load zeigt und Module auf dem kritischen Renderpfad hervorhebt. Alles, was hinter einer async boundary liegt, verschwindet aus der Ansicht; Module mit einem initialen Pfad bleiben sichtbar. Damit beantwortest du die eigentliche Frage: Welches JavaScript muss laufen, bevor der erste Bildschirm steht — und welches kann warten, bis jemand klickt.
Der Analyzer zeigt das Rohrnetz, der Agent schlägt vor, wo Ventile hingehören, und der Diff sagt dir, ob der Druck tatsächlich gesunken ist. Was er nicht kann: entscheiden, welcher Raum trockengelegt werden darf. Das bleibt eine Produktentscheidung, abhängig von den Erwartungen deiner Nutzer, nicht von der Größe eines Chunks.
Was das konkret für deine App bedeutet
Der Ansatz verschiebt den Aufwand vom Suchen zum Bewerten. Bisher hast du Bundle-Größen betrachtet und dann im Code geraten, woher ein Modul kommt; jetzt liefert der Modulgraph die Importkette und der Agent einen Kandidaten für den Schnitt. Der eigentliche Aufwand liegt danach im Prüfen: ob das Preview-Deployment hält, was es verspricht, und ob die Verzögerung im Nutzungsfluss unsichtbar bleibt.
Für die Reihenfolge: Starte mit der Routenübersicht und nimm dir die schwersten Seiten vor, nicht die skurrilsten Einzelfälle. Prüfe dann pro Kandidat, ob es einen statischen Import gibt, der die Verzögerung aushebelt — das ist der häufigste Grund, warum Lazy Loading in der Praxis nichts bringt. Und miss nach jeder Änderung, statt dich auf das Gefühl zu verlassen, dass es schneller wirkt.
Zwei Einschränkungen: Die Analyse setzt Turbopack voraus, ältere Setups mit Webpack bleiben außen vor. Und der Agent arbeitet auf dem Modulgraph, nicht auf deiner Absicht. Er findet, was tatsächlich geladen wird — nicht, was du geplant hattest.
Quelle: nextjs.org
