Astro 7.4 bringt Build-Timings, paralleles Prerendering und getrennte Bild-Services
Victoria Shinder3 Min. LesezeitDas Astro-Team hat am 15. Oktober 2026 astro 7.4.0 veröffentlicht. Das Minor-Release bringt zehn neue Funktionen, zwei davon experimentell, sowie eine Reihe von Korrekturen. Eine Änderung betrifft jedes Projekt: Die Mindestversion von Node.js ist jetzt 22.22.0 (#18277). Laut Release Notes ist das die neueste Node.js-22-Version, die StackBlitz unterstützt, und entspricht Astros Richtlinie für Node.js-Versionen.
Langsame Builds finden. Das neue Flag --timings für astro build gibt nach dem Build eine Zusammenfassung aus (#17894). Damit soll sich erkennen lassen, ob die Zeit in einer Integration, einem Markdown-Plugin, der Bildverarbeitung oder dem Syntax-Highlighting steckt, und man kann Build-Zeiten vor und nach einer Änderung vergleichen.
Paralleles Prerendering (experimentell). Mit experimental.parallelPrerender: true rendert astro build statische Seiten auf mehreren CPU-Kernen statt auf einem (#17932). Standardmäßig nutzt Astro alle verfügbaren Kerne außer einem. Jeder Worker braucht zusätzlichen Speicher; läuft der Build in Speichermangel oder wird nicht schneller, empfehlen die Notes, workers niedriger zu setzen. Jeder Worker rendert so viele Seiten gleichzeitig, wie build.concurrency zulässt.
Zwei Bild-Services. image.service akzeptiert jetzt getrennte Services für build und runtime (#18177). Der Build-Service optimiert Bilder auf vorgerenderten Seiten und kommt auch in der Entwicklung zum Einsatz; der Runtime-Service bedient Bilder auf bedarfsweise gerenderten Seiten und den Bild-Endpunkt der ausgelieferten Site. Das Beispiel im Release kombiniert Sharp beim Build mit einem Bild-CDN zur Laufzeit. Für Autoren von Integrationen behält config.image.service die Form, in der der Nutzer es konfiguriert hat; sind beide Services gesetzt, sind entrypoint und config undefined, und die Integration muss die Eigenschaft runtime lesen. Eigene Prerenderer können nun melden, welche Bilder eine vorgerenderte Seite verwendet. Ein schlichtes Array aus getStaticPaths() oder eine schlichte Response aus render() funktioniert weiter, ist aber abgekündigt – Bilder auf solchen Seiten werden dann nicht erzeugt.
Weiterleitungs- und 404-Seiten. Statische Sites können keinen Location-Header senden, deshalb schreibt Astro für jede Weiterleitung eine kleine HTML-Seite mit meta http-equiv="refresh". Markup, Text und Verzögerung waren bisher fest. Mit experimental.redirectPage kann ein Projekt eine eigene src/pages/3xx.astro liefern, die Astro für jede Weiterleitung mit from, to, status und delay als Props rendert (#18015). Ein neuer Handler notFound() für astro/fetch und astro/hono rendert die eigene 404-Seite, auch eine vorgerenderte 404.astro, in selbst geschriebenen Einstiegspunkten wie einer Hono-App, die direkt als Cloudflare Worker läuft (#18265); ohne ihn liefern nicht passende Routen eine leere 404.
Fehler, die nicht mehr verschwinden. Zwei Korrekturen ändern das Ergebnis von Builds. Mit eigener src/fetch.ts und einem Adapter, der in seiner eigenen Laufzeit vorrendert, etwa @astrojs/cloudflare, wurde eine Seite, die beim Prerendering einen Fehler warf, bisher als leere HTML-Datei geschrieben, und der Build galt als erfolgreich; jetzt bricht er mit dem eigentlichen Fehler ab (#18355). Außerdem verschluckt der glob()-Loader beim Content-Sync keine Renderfehler mehr, durch die astro build mit Code 0 endete, obwohl ein remark- oder rehype-Plugin einen Fehler geworfen hatte (#18353).
Außerdem. Font-Provider erhalten den optionalen Callback getFontProperties(), mit dem Astro vor Schnitten oder Stilen warnt, die eine Schriftfamilie nicht hat; in Astro 8 wird er Pflicht (#17830). Integrationen können festlegen, wohin Client-, Server- und Prerender-Ausgaben geschrieben werden (#18313).
Quelle: withastro/astro, Release „astro@7.4.0“ — https://github.com/withastro/astro/releases/tag/astro%407.4.0