Lohnt sich das Upgrade auf Astro 7 sofort?

Wenn das Projekt keine remark-/rehype-Plugins und kein astro:db nutzt, ist das Upgrade risikoarm und schnell erledigt - dann spricht wenig fürs Warten. Der Build-Speedup skaliert mit der Projektgröße: Bei einer 22-Sekunden-Baseline sind es angenehme 11 Sekunden weniger, bei Minuten-Builds in der CI summiert sich das auf echte Kosten- und Deploy-Zeit-Ersparnis.

Was ist der größte Breaking Change in Astro 7?

Für die meisten Projekte der Wechsel des Markdown-Prozessors: Sätteri (Rust) ersetzt die unified-Pipeline als Standard. Wer remark- oder rehype-Plugins einsetzt, muss @astrojs/markdown-remark explizit installieren und konfigurieren. Ohne eigene Markdown-Plugins rendert Sätteri GitHub-Flavored Markdown inklusive Tabellen und Inline-HTML unverändert.

Muss ich meinen Code für den neuen Rust-Compiler anpassen?

Nur wenn er invalides HTML enthält. Der in Rust neu geschriebene Compiler korrigiert fehlerhaftes Markup nicht mehr stillschweigend: Nicht geschlossene Elemente wie ein offenes p-Tag führen jetzt zu einem Build-Fehler statt zu einer Auto-Korrektur. Sauberes HTML läuft ohne Anpassung durch.

Was hat es mit der Whitespace-Änderung in Astro 7 auf sich?

Der Standardwert von compressHTML wechselt von true auf 'jsx'. Dabei wird Whitespace zwischen Elementen aggressiver entfernt - im schlechtesten Fall kleben zwei Inline-Elemente im sichtbaren Text zusammen. Ob ein Projekt betroffen ist, zeigt ein Vergleich des gerenderten Texts (innerText) zwischen alter und neuer Version. Wer das alte Verhalten braucht, setzt compressHTML: true in der Config.

Astro 7 Upgrade in der Praxis: Build-Zeit halbiert, null Code-Änderungen

Major-Versionen von Frameworks haben einen Ruf: erst das Changelog lesen, dann das Wochenende einplanen. Astro 7 ist das Gegenteil. Ich habe diese Website - Astro 6.3, SSR mit Node-Adapter, Svelte 5, Tailwind 4, zweisprachiges Routing, rund 35 Blog-Artikel in Content Collections - auf Astro 7.0 migriert. Aufwand: ein npm-Befehl. Code-Änderungen: null. Ergebnis: Build-Zeit halbiert.

Der offizielle Upgrade-Guide existiert bisher nur auf Englisch, und deutsche Erfahrungsberichte zu Astro 7 sind noch rar. Deshalb hier der komplette Praxisbericht: was Astro 7 technisch ändert, welche Zahlen ein reales Projekt liefert, welche Breaking Changes wen treffen - und wie du die eine unterschätzte Falle sauber prüfst.

Was Astro 7 mitbringt

Astro 7 ist am 22. Juni 2026 erschienen und ist im Kern ein Performance-Release. Drei große Umbauten, alle in Rust:

Rolldown statt Rollup: Astro 7 setzt auf Vite 8, und damit auf Rolldown - den in Rust geschriebenen Bundler, der Rollup ersetzt und laut Vite-Team 10- bis 30-mal schneller bundelt.
Rust-Compiler für .astro-Dateien: Der bisherige Go-basierte Compiler wurde komplett in Rust neu geschrieben und ist jetzt die einzige Option.
Sätteri als Markdown-Prozessor: Die unified-Pipeline (remark/rehype) ist nicht mehr Standard. Sätteri verarbeitet Markdown in Rust, GitHub-Flavored Markdown inklusive.

Dazu kommt Queued Rendering, das in Astro 6 noch experimentell war und jetzt Standard ist - laut Astro-Team bis zu 2,4-mal schnelleres Rendering vieler Seiten. Astro verspricht in Summe 15 bis 61 Prozent schnellere Builds, manche Projekte sollen sich mehr als verdoppeln.

Marketing-Zahlen. Interessanter ist, was ein echtes Projekt misst.

Das Upgrade: ein Befehl, kein Drama

Ausgangspunkt war Astro 6.3.3. Statt npx @astrojs/upgrade (das interaktiv nachfragt) habe ich die Pakete direkt gezogen:

npm install astro@latest @astrojs/node@latest @astrojs/svelte@latest @astrojs/sitemap@latest

Das Ergebnis im Paketbaum: astro 7.0.6, @astrojs/node 11, @astrojs/svelte 9 - und npm meldet 77 entfernte Pakete bei nur 17 neuen. Der Dependency-Baum wird spürbar schlanker, weil die Rust-Toolchain ganze JavaScript-Teilbäume ersetzt.

Danach: npm run build. Kein Config-Umbau, kein Codemod, kein einziger Fix. Der Build lief beim ersten Versuch durch - inklusive Svelte-5-Inseln, Tailwind-4-Vite-Plugin, i18n-Routing mit Fallbacks, Middleware mit Redirect-Logik und dynamischer Sitemap. Dass ein Major-Upgrade eines kompletten Frameworks so unspektakulär ausfällt, ist selten genug, um es festzuhalten.

Woran man erkennt, dass wirklich Rolldown arbeitet: Die bekannte Chunk-Size-Warnung verweist nicht mehr auf build.rollupOptions, sondern auf build.rolldownOptions.

Die Zahlen: Build-Zeit halbiert

Gemessen auf derselben Maschine (Windows, Node 22), jeweils zwei Läufe mit warmem Cache, gleicher Projektstand:

Messung	Astro 6.3.3	Astro 7.0.6	Delta
Gesamt-Build (`npm run build`)	21,5 s / 22,7 s	10,9 s / 11,2 s	ca. -50 %
davon “Server built”	19,9 s	8,1 s	-59 %

Das Projekt landet damit am oberen Ende der von Astro versprochenen 15 bis 61 Prozent. Zur Einordnung: Es ist ein SSR-Projekt mittlerer Größe - etwa 60 Routen (DE + EN), zwei Content Collections, Three.js- und Svelte-Inseln. Reine Static-Site-Projekte mit vielen Markdown-Seiten dürften durch Sätteri und Queued Rendering noch stärker profitieren.

Ob 11 gesparte Sekunden relevant sind, hängt vom Kontext ab. Lokal ist es Komfort. In der CI und beim Deployment ist es Geld: Jeder Push auf main baut dieses Projekt in einem Container neu - halbierte Build-Zeit heißt halbierte Wartezeit bis zum Rollout und weniger gebundene Server-Ressourcen. Bei Projekten, deren Builds im Minutenbereich liegen, wird aus dem Komfort ein Argument.

Breaking Changes im Realitätscheck

Die offizielle Liste ist überschaubar. Entscheidend ist, wen die Punkte treffen:

Sätteri statt remark/rehype. Wer eigene remark- oder rehype-Plugins nutzt (Fußnoten, eigene Direktiven, Syntax-Highlighting-Sonderwege), bekommt die alte Pipeline nur zurück, indem er @astrojs/markdown-remark explizit installiert und konfiguriert. Dieses Projekt nutzt keine Markdown-Plugins - und Sätteri hat alle Inhalte identisch gerendert, GFM-Tabellen und Inline-HTML in den Artikeln eingeschlossen. Genau das habe ich geprüft statt geglaubt (dazu unten mehr).

Strengerer Compiler. Der Rust-Compiler korrigiert invalides HTML nicht mehr stillschweigend. Ein nicht geschlossenes  war bisher eine Auto-Korrektur, jetzt ist es ein Build-Fehler. Das ist eine Verbesserung - stiller Auto-Fix ist eine Fehlerquelle, kein Feature - aber Projekte mit gewachsenen Templates sollten den ersten Build als Diagnose-Lauf begreifen.

@astrojs/db ist raus. Wer Astro DB nutzt, braucht einen Migrationsplan (Node-SQLite, Drizzle oder eine externe Datenbank). Für alle anderen: irrelevant.

src/fetch.ts ist reserviert. Die Datei gehört jetzt dem neuen Advanced Routing. Wer zufällig eine eigene Datei dieses Namens hat, benennt sie um.

Vite 8. Eigene Vite-Plugins sollten gegen Vite 8 laufen. Das Tailwind-4-Plugin tat es hier anstandslos.

Die Whitespace-Falle - und wie du sie prüfst

Der unauffälligste Punkt im Changelog ist der mit dem größten Überraschungspotenzial: Der Standardwert von compressHTML wechselt von true auf 'jsx'. Astro entfernt damit Whitespace zwischen Elementen deutlich aggressiver. Im Roh-HTML dieser Website fehlen nach dem Upgrade tatsächlich hunderte Leerzeichen zwischen Tags - die Startseite wurde dadurch rund 1 KB kleiner.

Das Problem: Zwischen Block-Elementen ist entfernter Whitespace egal, zwischen Inline-Elementen nicht. Aus Hallo Welt kann im sichtbaren Text “HalloWelt” werden. Ob es ein Projekt trifft, entscheidet nicht das Changelog, sondern das eigene Markup.

Deshalb habe ich es gemessen statt gehofft: alte Version (live) und neue Version (lokal) im Browser geöffnet, jeweils document.body.innerText extrahiert, Whitespace normalisiert, Wortlisten verglichen. Ergebnis hier: Wort für Wort identisch, auf der Startseite wie in Blog-Artikeln. Die Kompression trifft in diesem Projekt nur Whitespace zwischen Block-Elementen.

Wenn dein Diff nicht leer ist: compressHTML: true in der astro.config stellt das alte Verhalten wieder her, gezieltes {" "} an den betroffenen Stellen ist die sauberere Lösung.

Meine Upgrade-Checkliste

So sah der komplette Ablauf aus - übertragbar auf jedes Astro-Projekt:

Im Git-Worktree upgraden, nicht im Haupt-Checkout. git worktree add ../projekt-astro7 main gibt dir eine isolierte Kopie; die laufende Arbeit bleibt unberührt.
Baseline messen. Zweimal npm run build mit der alten Version stoppen. Ohne Vorher-Wert ist jede Speedup-Aussage geraten.
Pakete ziehen: astro@latest plus alle @astrojs/*-Integrationen in einem Rutsch.
Build als Diagnose-Lauf. Fehler des strengeren Compilers tauchen hier auf, nicht erst in Produktion.
Smoke-Test der Kern-Routen. Produktions-Build starten, wichtigste URLs auf Status 200 prüfen - bei SSR-Projekten inklusive Middleware-Redirects und i18n-Routen.
innerText-Diff gegen die Live-Version für die Whitespace-Falle (siehe oben).
Markdown-Stichprobe: ein Artikel mit Tabellen und Inline-HTML, einmal alt, einmal neu gerendert.

Punkte 1 bis 7 haben hier zusammen keine Stunde gedauert. Das meiste davon war Messen, nicht Fixen.

Fazit

Astro 7 ist das seltene Major-Release, bei dem der Nutzen sofort messbar und der Migrationsaufwand nahe null ist - sofern das Projekt keine remark-Plugins und kein Astro DB nutzt. Build-Zeit halbiert, 77 Pakete weniger im Baum, identisches Rendering. Wer auf Astro 6 unterwegs ist, verliert durch Warten nichts Dramatisches, gewinnt durch Upgraden aber jeden Tag Build-Zeit.

Und wer gerade überlegt, worauf eine neue Website technisch aufsetzen sollte: Genau diese Sorte Release ist der Grund, warum ich Astro für Firmen-Websites einsetze - das Framework wird jedes Jahr schneller, ohne dass Bestandsprojekte dafür umgebaut werden müssen.

Transparenz: Die Messwerte stammen vom Upgrade genau dieser Website am 5. Juli 2026. Andere Projekte, andere Zahlen - deshalb steht die Methodik dabei.