Die siebte Runde von Astro legt das Gewicht nicht auf eine Funktionsliste, sondern auf die Strecke des Builds selbst: die zwei langsamsten Stufen nach Rust verschieben und alles, was danach unerklaert bleibt, einem Bericht darueber uebergeben, wohin die Zeit ging.

Die Version steht bei 7.4.1

Der aktuelle stabile Stand ist 7.4.1, veroeffentlicht am 19. Oktober 2026. Die Linie ruht auf zwei Wegmarken: Die siebte Linie begann am 22. Juni 2026, und diese Ausgabe kam am 15. Oktober. Das Projekt ist unter der MIT-Lizenz offen, und das Verzeichnis ist ueberwiegend in TypeScript geschrieben.

Rust hat die zwei langsamsten Stufen uebernommen

Was die erste Ausgabe der siebten Linie tat, passt in einen Satz: den gesamten Compiler fuer Komponenten ersetzen, neu geschrieben von einem Go-Bau auf einen Rust-Bau; die Behandlung von Markdown und MDX auf eine Rust-Strecke verschieben; und die Zeichenmaschine auf eine Strategie mit Warteschlange umstellen, die wartende Fragmente wirksamer einreiht.

Der offizielle Grund: Ein Build hat drei Stufen, und die erste frisst die Zeit. Seiten, Inhalte und Komponenten fuer den Browser werden zu einem JavaScript-Paket geschnuert, danach wird jede vorgerenderte Seite der Reihe nach angefragt und zu HTML gemacht. Der langsame Teil ist genau das Uebersetzen und die Markdown-Behandlung, also wanderten beide in nativen Code. Der voreingestellte Markdown-Verarbeiter wechselte mit, von einer Gruppe von Erweiterungen zu einer eigenen Strecke. Seiten mit schlichtem Markdown merken kaum etwas; ein Vorhaben mit einer Kette von Erweiterungen, die den Syntaxbaum umschreiben, muss sie einzeln pruefen.

Vite 8 und der Packer, den sie mitbringt

Die andere Haelfte des Tempos kommt von Vite 8. Die groesste Aenderung jener Ausgabe ist ein eingebauter Packer, in Rust geschrieben, der zwei Werkzeuge zusammenlegt, die sich die Aufgabe frueher teilten, und dabei die Schnittstelle fuer Erweiterungen unangetastet laesst. Nach dem Zusammenlegen nennt die offizielle Angabe einen Bereich: die Gesamtzeit des Builds faellt um 15 bis 61 Prozent, und einzelne Seiten werden mehr als doppelt so schnell.

Die Messtabelle zeigt die Verteilung besser. Eine Dokumentationsseite mit sechstausend Seiten ging von rund 115 Sekunden auf rund 74, eine mit dreizehntausend von rund 386 auf rund 326. Je mehr Seiten eine Seite hat, desto kleiner der Gewinn in Prozent, weil das Rendern der Seiten selbst nicht nach Rust wanderte und deshalb einen groesseren Anteil am Rest bekommt.

Wie viel herauskommt, haengt davon ab, wie viel Zeit in das Uebersetzen und in Markdown geht, und eine Inhaltsseite aus einigen tausend Markdown-Dateien ist genau die Sorte, bei der das Uebersetzen dominiert.

Diese Ausgabe macht aus dem Build einen Bericht

Die erste Ausgabe beantwortete, wie man schneller wird; diese beantwortet, wohin das Tempo ging und wohin nicht. Der Buildbefehl nimmt einen weiteren Schalter, und am Ende druckt er eine Aufschluesselung: jede Stufe, jede Klasse von Erweiterung, Markdown-Behandlung und Hervorhebung der Syntax, Rendern der Seiten, Bilder und Einbindungen, mit Zeiten und Anteilen, dazu Mittelwert und oberen Wert fuer die langsamsten Seiten.

Die offizielle Vorfuehrung nutzt eine Vorlage fuer ein Blog. Die Vorlage hat neun Seiten, der ganze Lauf dauert etwa zweieinhalb Sekunden, und die Erzeugung der Seiten nimmt davon gut zwei ein, rund 80 Prozent. Die langsamsten Seiten sind fast alle die, welche die Vorlage fuer Artikel anwenden, waehrend Startseite und Feed im Millisekundenbereich liegen. Das Problem wird genau benannt: In der Vorlage holt der Bereich fuer Kommentare zuerst die Kommentare und danach das Profil jedes Verfassers, zwei Runden von Anfragen hintereinander, und jede Seite wartet.

Nach der Umstellung auf ein einmaliges gleichzeitiges Holen, dessen Ergebnisse weitergereicht werden, fiel die Erzeugung von gut zwei Sekunden auf etwa eine, und die Zeit je Artikel halbierte sich. Der Wert des Beispiels liegt nicht in dieser Sekunde, sondern in dem, was es sichtbar macht und was ohne Bericht schwer zu finden ist: Im Editor sieht der Code vollkommen in Ordnung aus.

Der Bilderdienst teilt sich in Build und Laufzeit

Diese Ausgabe erlaubt, den Bilderdienst zweimal einzurichten: einmal fuer vorgerenderte Seiten, einmal fuer Seiten, die auf Anfrage entstehen. Ein Build hat die ganze Maschine und eine vollstaendige Umgebung, also passt der oertliche Verbesserer am besten; das Rendern auf Anfrage laeuft auf einem Server oder einem Randknoten, wo der oertliche Verbesserer womoeglich gar nicht arbeitet, was ein Bildernetz zur vernuenftigen Wahl macht. Vorher waehlte man eines oder ueberliess die Wahl dem Adapter. Damit das traegt, werden Bilder aus der Buildphase jetzt von der eigenen Strecke des Geruests verfolgt, und Adapter bauen keine eigene Kopie mehr nach.

Was ein strengerer Compiler bedeutet

Ein Compilertausch ist nicht reines Tempo. Der neue Rust-Compiler ist strenger bei ungueltigem HTML: Nicht geschlossene Marken melden Fehler, und Elemente mit Inhalt brauchen eine passende schliessende Marke; unsinnige Verschachtelung wird nicht mehr automatisch geradegebogen, sondern so an den Browser gereicht, wie sie dasteht.

Der alte Compiler half still, schloss Marken, ordnete und schob falsch platzierte Knoten hinaus. Diese Hilfe verursachte in manchen Faellen kaum zu findende Fehler, also unterlaesst der neue sie. Der Preis: Nach der Aufwertung tauchen Fehler auf, die vorher nie zu sehen waren, und die Ausgabe kann sich aendern. Das praktische Vorgehen ist schlicht: nach der Aufwertung einmal bauen, offene Marken schliessen und ueberall dort, wo die Ausgabe sich verschoben hat, die Verschachtelung der Vorlage pruefen. Ein Vorhaben mit ordentlichen Vorlagen merkt fast nichts; eines mit Geschichte bekommt eine Aufraeumarbeit.

Zwei Versuchsschalter und ein paar neue Regeln

Zwei versuchsweise Faehigkeiten laufen mit. Die eine ist das gleichzeitige Vorrendern, das die statischen Seiten auf mehrere Arbeitsthreads verteilt und standardmaessig alle Kerne bis auf einen nutzt; jeder Thread erhoeht den Speicherbedarf des Builds, also sollte die Zahl sinken, wenn der Speicher knapp ist oder nichts schneller wird. Die andere ist eine eigene Weiterleitungsseite: Eine statische Seite hat keinen Server, der Weiterleitungskopfzeilen senden koennte, also erzeugt jede Weiterleitung eine kleine Seite mit einem Auffrischungsbefehl, deren Text, Stil und Verzoegerung bisher feststanden, waehrend der neue Schalter sie aus einer eigenen Vorlage rendert und Quelle, Ziel, Standcode und Verzoegerung als Parameter durchreicht.

Ein paar neue Regeln gehoeren notiert. Die kleinste Node-Fassung steigt auf 22; src/fetch.ts wird ein reservierter Dateiname, den die fortgeschrittene Wegewahl als Einstellung einbindet, also muss ein Vorhaben mit einer Datei dieses Namens die Einstellung aendern oder umbenennen; und Anbieter von Schriften bekommen einen wahlfreien Rueckruf, der Gewichte, Zeichen, Teilmengen und Formate nennt, die eine Familie wirklich hat, wobei ein Wert, den der Anbieter nicht liefern kann, frueh eine Warnung ausloest. Dieser Rueckruf ist jetzt wahlfrei und wird in der naechsten grossen Ausgabe Pflicht.

Fuer wen es taugt

Die Seite nennt sich ein Geruest fuer inhaltsgetriebene Webseiten und zaehlt Werbeseiten, Blogs und Laeden zu dem, was sie bedient. Der Kern ist der Server zuerst: Komponenten werden dort gerendert und nur HTML geht an den Browser, ohne ueberfluessige Kosten fuer JavaScript, waehrend interaktive Teile als Inseln getrennt geladen werden. Bei der Erweiterbarkeit nimmt es Komponenten der gaengigen Oberflaechengerueste auf, sodass vorhandene Komponenten unveraendert einziehen, und auf der Inhaltsseite gibt es Sammlungen, in denen Markdown und Datendateien in einem Ordner Typsicherheit und Vervollstaendigung bekommen.

Der Grund, es in den Werkzeugkasten zu legen, ist selten eine einzelne Funktion, sondern dass Bauzeit und Groesse der Ausgabe zugleich beherrschbar bleiben. Die erste Ausgabe drueckte die erstere, diese macht sie erklaerbar.

Die Geschichte von Astro 7 ist schlicht: die langsamen Teile durch eine schnellere Sprache ersetzen und aus dem Rest, der unerklaert bleibt, einen lesbaren Bericht machen. Das erste brauchte eine Neufassung, das zweite braucht einen Schalter. Erinnernswert sind nicht die Prozente, sondern die Reihenfolge: Wenn ein Build langsamer wird, zuerst den Bericht lesen und dann entscheiden, was zu aendern ist.