Astro 7.4 neue Features erklärt

Astro 7.4 ist da und zeigt endlich, wo euer Build seine Zeit verliert. Dazu kommen getrennte Image Services für Build und Runtime, ein notFound Handler für eigene Entrypoints, Warnungen für Font Einstellungen und zwei experimentelle Features. Wir nutzen Astro täglich in der Frontend Entwicklung bei Never Code Alone. Hier erklären wir die neuen Features und was sie im Projektalltag bringen. Den Gesamtüberblick über alle Astro Versionen findet ihr auf unserer Seite Astro JS als Static Site Generator.

Astro 7.4 neue Features im Überblick

Feature	Status	Was ihr davon habt
Build Timings mit –timings	stabil	Ihr seht, wo der Build Zeit verliert
Image Service für Build und Runtime	stabil	Sharp im Build, Image CDN zur Laufzeit
notFound Handler	stabil	Eigene 404 Seite in eigenen Entrypoints
Font Warnungen	stabil	Fehler in der Font Config fallen sofort auf
Node.js 22.22.0	Pflicht	Vor dem Upgrade Node prüfen
Parallel Prerendering	experimentell	Statische Seiten auf mehreren CPU Kernen
Eigene Redirect Seite	experimentell	Weiterleitungen auf Deutsch und im eigenen Design

Astro Build langsam? Build Timings zeigen die Ursache

Wenn ein Build langsam wird, liegt die Ursache selten auf der Hand. Ist es ein Vite Plugin, das Syntax Highlighting, die Bilder oder eine einzige schwere Seite? Ab Astro 7.4 hängt ihr einfach einen Flag an:

astro build --timings

Nach dem Build druckt Astro eine Übersicht. Darin stehen die Build Phasen, Vite Plugins, Markdown und Syntax Highlighting, das Rendering der Seiten, Bilder und Integrationen. Dazu kommt eine Liste der langsamsten Seiten mit Median und p95.

Das Beispiel im Release Post zu Astro 7.4 ist lehrreich. Eine Kommentar Komponente lädt erst die Kommentare und danach für jeden Kommentar ein Profil. Zwei Netzwerk Runden hintereinander, im Editor sieht man davon nichts. Der Report zeigt sofort, dass fast die ganze Zeit im Rendering der Komponenten steckt. Mit Promise.all() sank die Zeit für die Seitengenerierung von 2,10 auf 1,13 Sekunden.

Für uns gehört der Flag in die Pipeline. Wer die Ausgabe in GitHub Actions oder GitLab CI mitschreibt, sieht früh, wenn ein Merge Request den Build bremst. Wie wir Pipelines mit Quality Gates aufsetzen, zeigt das NCA CI/CD Pipeline Setup. Warum sich der Output seit Astro 7 verändert hat, steht in Warum dein Astro Build nach dem Upgrade anders aussieht. Alle Optionen beschreibt die CLI Referenz zu –timings.

Astro Image Service getrennt für Build und Runtime

Prerenderte Seiten und On Demand Seiten haben bei Bildern andere Bedürfnisse. Im Build habt ihr Zeit und ein volles Node.js. Da passt ein lokaler Optimizer wie Sharp. On Demand Seiten laufen auf dem Server oder am Edge, wo Sharp oft nicht läuft. Dort ist ein Image CDN die bessere Wahl. Bisher musstet ihr euch für einen Service entscheiden. Jetzt nimmt image.service beide an:

import { defineConfig } from 'astro/config';

export default defineConfig({
  image: {
    service: {
      build: { entrypoint: 'astro/assets/services/sharp' },
      runtime: { entrypoint: 'my-image-cdn-service' },
    },
  },
});

Der build Service verarbeitet Bilder auf prerenderten Seiten und läuft auch in der Entwicklung. Der runtime Service übernimmt On Demand Seiten und den Image Endpoint in Production. Ein einzelner Service funktioniert weiter wie bisher.

Wer eigene Integrationen schreibt, muss aufpassen. Sind build und runtime gesetzt, bleiben entrypoint und config in config.image.service leer. Prüft dann auf die Eigenschaft runtime. Wo Bilder im Projekt hingehören, erklärt Astro Bilder richtig ablegen. Schnelle Bilder zahlen direkt auf die NCA Core Web Vitals Optimierung ein.

notFound Handler für eigene Astro Entrypoints

Mit astro/fetch und astro/hono baut ihr eigene Server Entrypoints aus Astros Bausteinen. Es gab einen Haken. Wer pages() ohne den Komplett Handler astro() nutzte, bekam bei unbekannten Routen eine leere 404. Die eigene Seite 404.astro blieb außen vor, auch wenn sie prerendert war.

Astro 7.4 bringt dafür notFound(). Ihr setzt den Handler vor pages(). Das Beispiel ist vereinfacht, im Release Post steht zusätzlich die Cloudflare Middleware:

import { Hono } from 'hono';
import { notFound, pages } from 'astro/hono';

const app = new Hono();
app.use(notFound());
app.use(pages());

export default app;

Den gleichen Handler gibt es in astro/fetch. Wer astro() nutzt, muss nichts tun. Eine eigene Pipeline lohnt sich vor allem, wenn Astro vor einem Symfony Backend sitzt. Wie wir PHP Backends absichern, zeigt unser PHP Consulting. Grundlagen zu sicheren Endpoints stehen in Astro API Routes absichern.

Font Warnungen in der Astro Fonts API

Schnell ist eine Schriftstärke oder ein Subset angefragt, das die Schrift gar nicht hat. Bisher merkte man das erst, wenn der Text falsch aussah. Font Provider können jetzt den Callback getFontProperties() anbieten. Er meldet, welche Stärken, Stile, Subsets und Formate es wirklich gibt. Astro warnt dann bei jedem Wert in der Config, den der Provider nicht liefern kann.

• Eingebaute Provider: können das schon, ihr müsst nichts tun.
• Eigene Provider: In Astro 7 ist der Callback optional, ab Astro 8 wird er Pflicht. Baut ihn jetzt ein.
• Stabilere Downloads: Der init Kontext bekommt ein fetch(), das kurze Ausfälle wiederholt.

Saubere Schriften sind auch ein Thema für Barrierefreiheit. Tipps dazu gibt es in line-height und Textabstände nach WCAG.

Astro 7.4 braucht Node 22.22

Die Mindestversion für Astro und alle offiziellen Integrationen ist jetzt Node.js 22.22.0. Wer eine ältere Node 22 Version nutzt, aktualisiert zuerst Node und dann Astro. Denkt an alle Stellen: lokale Setups, Docker Images und CI Runner. Renovate hebt bei uns die Pakete an, die Node Version in Images und Pipelines prüfen wir trotzdem bewusst mit.

Wichtig für Adapter: @astrojs/cloudflare und @astrojs/markdoc brauchen in der neuen Version astro@^7.4.0. Zieht sie im selben Schritt mit.

Parallel Prerendering in Astro ausprobieren

Astro rendert statische Seiten schon gleichzeitig, bisher aber auf einem einzigen Thread. Große Sites mit rechenintensiven Seiten nutzen so nur einen CPU Kern. Der experimentelle Flag parallelPrerender verteilt das Rendering auf Worker Threads:

import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    parallelPrerender: {
      workers: 4,
    },
  },
});

Ohne Angabe nutzt Astro alle Kerne außer einem. Jeder Worker braucht aber Speicher. Läuft der Build in einen Speicherfehler oder wird er nicht schneller, setzt ihr workers herunter. Mit dem Cloudflare Adapter hat der Flag keine Wirkung, Astro warnt dann im Build. Details stehen in den Docs zu Parallel Prerendering.

Richtig stark wird es zusammen mit den Incremental Static Builds aus Astro 7.2. Die überspringen unveränderte Seiten, Parallel Prerendering verteilt den Rest auf die Kerne. Unsere Reihenfolge: erst mit --timings messen, dann den Flag setzen. Alle Features seit Astro 6 fasst Astro Framework 2026 zusammen.

Eigene Redirect Seite im statischen Astro Build

Eine statische Site hat keinen Server, der einen Location Header schickt. Astro baut deshalb für jeden Redirect eine kleine HTML Seite mit Meta Refresh. Das gilt für die redirects Config, Astro.redirect() auf prerenderten Seiten und i18n Redirects. Text, Markup und Wartezeit waren bisher fest.

Mit dem Flag redirectPage legt ihr eine eigene Seite src/pages/3xx.astro an. Astro rendert sie für jeden Redirect und übergibt from, to, status und delay als Props. Die Seite muss selbst den Meta Refresh auf to setzen. Fehlt er, warnt Astro im Build und nutzt die eingebaute Seite.

Für deutsche Sites ist das ein echter Gewinn. Die Weiterleitung spricht endlich Deutsch und bekommt einen klaren Link, den auch Screenreader und Tastatur gut erreichen. Ein noindex gehört mit hinein. Mehr zu barrierefreien Oberflächen steht im Bereich Accessibility Webdesign. Feedback zum Feature sammelt das Core Team im RFC auf GitHub.

Astro 7.4 Upgrade sicher durchführen

npx @astrojs/upgrade

• Node prüfen: überall 22.22.0 oder neuer, lokal, im Image und in der CI.
• Adapter mitziehen: Cloudflare und Markdoc Integration im selben Schritt aktualisieren.
• Eigene Prerenderer: Ein einfaches Array aus getStaticPaths() ist jetzt deprecated. Bilder auf diesen Seiten werden dann nicht erzeugt.
• Eigene Font Provider: getFontProperties() einbauen, bevor Astro 8 kommt.
• Testen: Ein E2E Durchlauf über die wichtigsten Seiten zeigt Brüche, bevor Nutzer sie sehen.

Damit nach dem Update nichts unbemerkt bricht, richten wir mit euch ein Cypress E2E Testing Setup ein. Wenn Coding Agents das Upgrade vorbereiten, brauchen sie feste Regeln. Die liefern die NCA Agentic AI Coding Guardrails. Wenn es schon brennt, hilft die NCA Soforthilfe für Webprojekte.

Fazit

Astro 7.4 ist ein Release für alle, die große Sites bauen. Build Timings machen aus einem Bauchgefühl eine klare Zahl. Getrennte Image Services lösen einen alten Kompromiss. Parallel Prerendering und die eigene Redirect Seite sind noch experimentell, aber schon jetzt einen Test wert. Für uns bleibt Astro zusammen mit Tailwind CSS und Cypress der Kern im Frontend Stack.

Häufige Fragen zu Astro 7.4

Was ist 2026 neu in Astro 7.4?

Astro 7.4 bringt den Flag –timings für astro build, getrennte Image Services für Build und Runtime, einen notFound Handler für eigene Entrypoints und Warnungen für Font Einstellungen. Experimentell kommen Parallel Prerendering und eine eigene Redirect Seite dazu. Die Mindestversion für Node.js steigt auf 22.22.0.

Wie finde ich 2026 heraus, warum mein Astro Build langsam ist?

Startet den Build mit astro build –timings. Astro zeigt danach, wie viel Zeit Build Phasen, Vite Plugins, Markdown, Rendering, Bilder und Integrationen brauchen. Eine Liste der langsamsten Seiten führt euch direkt zur Ursache, zum Beispiel zu Netzwerk Requests, die nacheinander statt parallel laufen.

Welche Node Version braucht Astro 2026?

Ab Astro 7.4 ist Node.js 22.22.0 die Mindestversion, für Astro und alle offiziellen Integrationen. Wer eine ältere Node 22 Version nutzt, aktualisiert zuerst Node in lokalen Setups, Docker Images und CI Runnern und erst danach Astro.

Ist Parallel Prerendering 2026 schon reif für Production?

Das Feature ist noch experimentell. Testet es in einem Branch und vergleicht die Zeiten mit –timings. Achtet auf den Speicher, denn jeder Worker braucht eigenen RAM. Mit dem Cloudflare Adapter hat der Flag keine Wirkung.

Lohnt sich 2026 das Update auf Astro 7.4?

Ja, vor allem für große Content Sites und Projekte mit langen Builds. Allein die Build Timings sparen Zeit bei der Fehlersuche. Prüft vorher die Node Version, zieht Adapter mit und sichert das Update mit E2E Tests ab.