Astro 6 auf 7: Die echten Zahlen vom Upgrade einer 129-Seiten-Site

Ich hatte einen Samstagnachmittag eingeplant, um die Website von QuietClip von Astro 6 auf Astro 7 zu heben. Ich rechnete mit der üblichen Pflichtübung: Migration-Guide überfliegen, drei Deprecations fixen, eine Config-Option verfluchen, neu deployen, bis zum Abendessen vergessen.

Womit ich nicht gerechnet hatte: Der Production-Build fiel von 4,95 Sekunden auf 2,95 Sekunden. Gleicher Code. Gleiche Maschine. Gleiche 129 Seiten. Vierzig Prozent schneller, zum Preis einer geänderten Versionsnummer.

Also tat ich das, was ich immer tun sollte und meistens überspringe: Ich ließ den Benchmark laufen, bevor ich irgendetwas anfasste, und danach noch einmal mit denselben Skripten. Hier sind die echten Zahlen aus diesem Astro 7 Upgrade, inklusive der Zahlen, die sich geweigert haben, sich zu bewegen.

40% schnellere Builds, und ich habe nur die Version geändert

Cold Build: 4,95s auf 2,95s. Warm Build: 4,85s auf 2,96s. Beides der Median aus fünf Durchläufen auf derselben Apple-Silicon-Maschine, gleichem Node 22, gleicher Content-Collection. Die einzige echte Änderung war Astro 6.4.8 auf 7.0.2, was Vite 7 auf Vite 8 hochzog und den neuen Rust-basierten Template-Compiler aktivierte.

Ich habe genau eine Zeile zur Config hinzugefügt: compressHTML: true. Astro 7 hat die Default-Strategie für die HTML-Komprimierung geändert, und ich wollte einen sauberen Vorher-Nachher-Vergleich, nicht einen, der durch unterschiedliches Whitespace-Handling verfälscht ist. Das war die komplette Migration. Keine Deprecations zum Hinterherjagen, keine Breaking API in meinen 69 .astro-Komponenten. Das, worauf ich mich gefasst gemacht hatte, kam nie.

Wenn du jemals einem Next.js-Build zugesehen hast, wie er langsam deinen Server auffrisst, weißt du, warum mir das wichtig ist. Ich habe einen ganzen Post darüber geschrieben, wie mein Next.js-Build meinen Server umgebracht hat und wie ich es kostenlos gefixt habe. Build-Zeit ist keine Eitelkeitsmetrik. Sie ist die Steuer, die du bei jedem einzelnen Deploy zahlst, bei jeder Preview, bei jedem winzigen Tippfehler-Fix. Sie zu halbieren ändert, wie oft du bereit bist zu shippen.

Wohin die zwei Sekunden tatsächlich gingen

Die Schlagzeile versteckt den interessanten Teil. Die Einsparung war nicht gleichmäßig verteilt. Sie kam aus zwei konkreten Phasen.

Das Vite-Client-Bundle fiel von 2,66s auf 0,92s. Das sind 65% weniger, und das ist fast komplett die Arbeit von Vite 8, nicht von Astro. Das Rendern aller 129 Seiten ging von 4,39s auf 2,32s, ein Minus von 47%, und das ist der neue Rust-Compiler plus Astros queued Rendering. Das sind genau die zwei Phasen, die Version 7 angreifen wollte, also ist es befriedigend zu sehen, wie der Benchmark dem Changelog zustimmt statt dem Marketing-Text. Auch der Peak-Speicher beim Build sank um 11%, von 704 MB auf 625 MB, was zählt, wenn deine CI-Maschine klein ist.

Hier die ehrliche Fußnote, die ich nicht vergraben werde: Die Bildoptimierung ist aus all diesen Zahlen ausgeschlossen. QuietClips Site hat über tausend optimierte webP-Dateien, und ein allererster Cold Build verbringt rund 8,6 Sekunden in sharp, um sie zu generieren. Aber sharp ist in Astro 6 und 7 Byte für Byte identisch, es würde also nur dieselbe Konstante auf beide Seiten draufpacken und die echte Story verwässern. Der wiederholbare Build, der, den du den ganzen Tag tatsächlich läufst, ist der von 5 auf 3 Sekunden. Das ist die Zahl, hinter der ich stehe.

Der Teil, der mir wirklich Angst gemacht hat

Schnellere Builds sind wertlos, wenn die Site dabei leise kaputtgeht. Ein Major-Versionssprung, der den Template-Compiler und die Markdown-Engine austauscht, ist genau die Art von Änderung, die einen subtilen Rendering-Bug einführt, den du erst bemerkst, wenn dir ein Kunde eine Mail schreibt. Ich habe zugesehen, wie KI-Tools selbstbewusst Dinge "upgraden" und ein Chaos hinterlassen, was der ganze Grund ist, warum ich darüber geschrieben habe, dass Claude großartig darin ist, Software zu bauen, und genauso großartig darin, sie kaputtzumachen.

Also habe ich nachgesehen. Der Build lief sauber durch über 261 Dateien, 69 .astro-Komponenten und 132 Markdown- und MDX-Seiten, mit null Rust-Compiler-Fehlern und null Deprecation-Warnungen. Ich habe den kompletten dist/-Ordner nach den üblichen Fehlersignaturen durchsucht: nicht gerenderte MDX-Komponenten-Tags, durchgesickerte import-Statements, als Text ausgegebene rohe Expressions. Nichts. Meine Editorial-Komponenten rendern weiterhin. Die SmartyPants-Typografie ist über alle 114 Posts intakt, die geschwungene Anführungszeichen nutzen. Die neue Default-Markdown-Engine, Saetteri, stellte sich als transparenter Tausch heraus, weil ich keine eigenen remark- oder rehype-Plugins laufen hatte, die portiert werden mussten.

Auch das Output-Payload bewegte sich kaum. Gezipptes HTML ging von 1090,3 KB auf 1088,1 KB über 129 Dateien. JavaScript schrumpfte leicht, von 48,6 KB auf 47,4 KB. CSS unverändert. Dieses "kaum bewegt" ist der Punkt: Ich habe den Build-Speedup bekommen, ohne irgendjemandem eine andere Site auszuliefern.

Die Zahlen, mit denen ich bewusst nicht angebe

Würde ich dir nur die Gewinne zeigen, hättest du recht, dem Rest zu misstrauen. Hier ist also, was sich nicht verbessert hat, denn so zu tun als ob, ist genau der Weg, auf dem Case Studies zu Werbung werden.

Die Runtime Core Web Vitals auf der Live-Site sind unverändert. Das statische HTML, CSS und JavaScript, das ein Besucher herunterlädt, ist im Wesentlichen gleich geblieben, es gab also keinen Grund zu erwarten, dass Lighthouse springt, und das tat es nicht. Desktop war ohnehin schon auf 100 festgenagelt, mit einem Largest Contentful Paint um die 0,5s und praktisch null Layout-Shift. Nach dem Astro 7 Upgrade und dem Redeploy auf Cloudflare hielt es bei 100 ohne Runtime-Regression. Die ehrliche Live-Story ist "nichts wurde schlechter", nicht "alles wurde schneller". Build-Speed ist ein Developer-Experience-Gewinn. Er macht deine Seiten nicht auf magische Weise schneller für die Nutzer, und wer dir erzählt, ein Framework-Sprung habe seine Field-Performance gefixt, verwechselt meistens das eine mit dem anderen.

Meine lokalen Core-Web-Vitals-Messungen bewegten sich um ein paar Millisekunden in beide Richtungen, aber die wurden auf ungedrosseltem localhost erfasst, was viel zu schnell ist, um es als reale Zahlen zu veröffentlichen. Sie sind ein gültiger relativer Check, nutzlos als absolute Aussage. Die veröffentlichbaren Runtime-Werte sind Transfergrößen und Request-Anzahl, und die blieben stehen: rund 180 KB pro Seite, 9 bis 12 Requests. Auch da keine Regression.

Solltest du das Astro 7 Upgrade also machen?

Wenn du schon auf Astro 6 bist, mit einer content-lastigen statischen Site und ohne exotischen Plugin-Stack, waren das die einfachsten 40%, die ich je gekauft habe. Eine Config-Zeile, ein Nachmittag Verifizierung, den ich größtenteils aus Paranoia gemacht habe, und für immer schnellere Builds. Das Risiko-Ertrags-Verhältnis war hier so schief, wie es bei Major-Versionssprüngen fast nie ist.

Wenn du auf einem stark angepassten Setup sitzt, mit einem Haufen remark-Plugins oder einem Server-Rendering-Adapter, der clevere Dinge tut, dann geh langsamer vor und benchmarke erst deine eigenen Phasen. Mein Ergebnis ist ein Datenpunkt von einer 129-Seiten-Marketing-Site, kein Versprechen. Führ den Vorher-Nachher-Vergleich selbst durch. Das ist der einzige ehrliche Weg, es zu wissen.

Und falls du überhaupt noch entscheidest, auf welchem Framework du bauen sollst, habe ich darüber geschrieben, wie ich tatsächlich zwischen WordPress, Next.js und Astro für Kundenprojekte entscheide, und über die Zeit, als ich drei Kunden-Sites von WordPress auf Astro migriert habe und nichts kaputtging. Astro verdient sich seinen Platz auf dieser Shortlist immer wieder, und dieses Upgrade ist ein Teil des Warum.

Das ist die Art unglamouröser, gemessener Arbeit, die ich für Kunden bei Wunderlandmedia mache: benchmarken, bevor du es anfasst, danach verifizieren, und die Zahlen berichten, die sich nicht bewegt haben, neben denen, die es taten. Wenn du jemanden willst, der deine Build-Pipeline so behandelt, als würde sie zählen, ist das der ganze Job.