Astro-Entwickler in Münster

#Astro in Münster: Seitenwechsel, die schnell wirken, ohne eine App zu werden

Ich bin Mariusz Szatkowski, arbeite seit 2006 mit WordPress und baue Websites heute auch mit Astro. Ich sitze in Gdynia, arbeite vollständig remote und schriftlich, Auf Meetings und Telefonate verzichte ich. Diese Seite richtet sich an Unternehmen in Münster und dem Münsterland, die ihrer Website einen flüssigen Seitenwechsel geben wollen und wissen möchten, was das technisch kostet.

Dabei geht es um vier Fragen: Wie animiert Astro einen Seitenwechsel? Wann lädt der Browser die nächste Seite schon vor? Was bleibt zwischen zwei Seiten erhalten? Und was ändert sich für Menschen, die per Screenreader oder mit reduzierter Bewegung unterwegs sind? Die Antworten stammen aus der Astro-Dokumentation und der Dokumentation zur View Transition API, Stand November 2026: Astro 7.4.11 ist laut npm-Registry die aktuelle Version.

Foto: Dietmar Rabich, CC BY-SA 4.0, Wikimedia Commons.

#Zwei Wege zu animierten Seitenwechseln

Die Astro-Dokumentation unterscheidet zwei Wege, und der Unterschied entscheidet über den Aufwand.

Nativ im Browser. Browser können Übergänge zwischen zwei Dokumenten einer Multi-Page-Website selbst animieren. Laut der Chrome-Dokumentation schalten Sie das mit einer CSS-Regel ein, und die Seiten müssen auf derselben Origin liegen:

@view-transition {
  navigation: auto;
}

Die Dokumentation von Astro sagt dazu, dass diese Variante die Funktionsweise einer Multi-Page-Website nicht verändert, keine bestehenden Skripte beeinflusst und kein zusätzliches JavaScript lädt. Sie fügt nur Animationen hinzu. Laut Chrome-Dokumentation gilt das ab Chrome 126. Die Support-Tabelle auf derselben Seite nennt Edge 126, Safari 18.2 und Firefox als nicht unterstützt. Dort steht auch, dass ein Übergang übersprungen wird, wenn die Navigation länger als vier Sekunden dauert (bei Chrome).

Mit dem ClientRouter von Astro. Die Komponente <ClientRouter /> fängt Klicks auf Links sowie Vor und Zurück ab, lädt die nächste Seite im Hintergrund und tauscht den Inhalt aus. Das bringt gemeinsame Zustände zwischen Seiten und persistente Elemente, hat laut Dokumentation aber auch einen Preis: Skripte und Zustand müssen nach dem Seitenwechsel gegebenenfalls neu initialisiert werden. Astro weist selbst darauf hin, dass der ClientRouter mit der Weiterentwicklung der Browser-APIs für manche Zwecke überflüssig wird, und empfiehlt, den Stand der Browser im Blick zu behalten.

Meine Praxis: Ich beginne beim nativen Weg und nehme den ClientRouter erst dazu, wenn ein konkretes Merkmal ihn verlangt. Aktiviert wird er pro Seite oder im gemeinsamen Layout:

---
import { ClientRouter } from "astro:transitions";
---
<head>
  <title>Startseite</title>
  <ClientRouter />
</head>

#Was der ClientRouter im Hintergrund tut

Wer die Reihenfolge kennt, findet Fehler schneller. Laut Dokumentation läuft ein Seitenwechsel so ab:

1. Der Router lädt die nächste Seite und setzt am html-Element das Attribut data-astro-transition auf forward oder back.
2. Er ruft document.startViewTransition auf, der Browser macht einen Schnappschuss der alten Seite.
3. Im Callback tauscht er den head aus (Stylesheets und Skripte, die auf der neuen Seite vorhanden sind, bleiben stehen) und ersetzt den body vollständig. Elemente mit transition:persist werden in das neue DOM verschoben.
4. Es folgen die Ereignisse astro:after-swap und, nach dem Laden neuer Stylesheets und dem Ausführen neuer Skripte, astro:page-load.

Daraus folgt der häufigste Fehler beim Nachrüsten. Gebündelte Modulskripte, also der Standard in Astro, laufen laut Dokumentation nur ein einziges Mal. Ein Menüskript, das früher bei jedem Seitenaufruf neu startete, muss in astro:page-load eingehängt werden:

document.addEventListener("astro:page-load", () => {
  document.querySelector(".hamburger")?.addEventListener("click", () => {
    document.querySelector(".nav-links")?.classList.toggle("expanded");
  });
});

Inline-Skripte, die bei jedem Wechsel neu laufen sollen, markiert die Dokumentation mit data-astro-rerun. Links, für die ein klassischer Seitenwechsel gewollt ist, bekommen data-astro-reload. Das gilt auch für Formulare: Der Router löst Übergänge laut Dokumentation auch bei <form> aus, data-astro-reload schaltet das pro Formular ab. Skripte von Drittanbietern, etwa Analyse oder Terminbuchung, prüfe ich vor dem Einschalten einzeln, weil sie sonst nur beim ersten Aufruf laufen.

#Prefetch: vier Strategien

Astros eingebautes Prefetching lädt die Zielseite im Hintergrund, bevor Besucher klicken. Es wird in astro.config.mjs mit prefetch: true eingeschaltet, anschließend gilt es für Links mit dem Attribut data-astro-prefetch. Es funktioniert laut Dokumentation nur für Links innerhalb der eigenen Website. Die Strategie wählen Sie pro Link:

Die Dokumentation nennt zwei Schutzmechanismen: Bei aktiviertem Datensparmodus oder langsamer Verbindung fällt Prefetch auf tap zurück, und schnelles Überfahren von Links löst nichts aus. Mit prefetchAll: true gilt Prefetch für alle Links, einzelne Links lassen sich mit data-astro-prefetch="false" ausnehmen.

Zwei Punkte sind für die Praxis wichtig:

• Mit ClientRouter ist Prefetch automatisch an. Laut Dokumentation setzt der ClientRouter die Konfiguration { prefetchAll: true }. Das lässt sich in der Konfiguration überschreiben, etwa mit prefetchAll: false. Bei Seiten mit sehr vielen Links gehe ich genau hier hin und wähle tap oder hover statt viewport, damit nicht unnötig Daten fließen.
• Cache-Header entscheiden in Firefox und Safari. Laut Dokumentation nutzt Astro <link rel="prefetch"> und fällt sonst auf fetch() zurück. Safari unterstützt rel="prefetch" nicht und braucht Cache-Header (Cache-Control, Expires, ETag), sonst funktioniert der Prefetch nicht. Firefox meldet ohne explizite Cache-Header einen Fehler (NS_BINDING_ABORTED) und nutzt bei einem passenden ETag die Antwort trotzdem wieder. Für statische Seiten setzt die Hosting-Plattform den ETag laut Dokumentation oft von selbst. Ich prüfe die Header im Antwortprotokoll und halte sie im Umfang fest.

Per Skript lässt sich ebenfalls vorladen: prefetch('/kontakt') aus astro:prefetch, mit denselben Schutzmechanismen. Die Option eagerness ist laut Dokumentation an das experimentelle Flag clientPrerender gekoppelt und gehört bei mir nicht in ein Standardprojekt.

#Zustand zwischen Seiten behalten

Mit transition:persist bleiben Elemente oder Islands über Seitenwechsel hinweg erhalten, statt ersetzt zu werden. Das Beispiel der Dokumentation ist ein Video, das beim Wechsel weiterläuft, ein Island mit einem Zähler behält seinen internen Zustand:

<Counter client:load transition:persist initialCount={5} />

Zwei Feinheiten aus der Dokumentation:

• Das Island wird mit den neuen Props der Zielseite neu gerendert, der Zustand bleibt. Soll es seine alten Props behalten, kommt transition:persist-props dazu (seit Astro 4.5).
• Nicht jeder Zustand lässt sich retten. Laut Dokumentation lassen sich der Neustart von CSS-Animationen und das erneute Laden von iframes auch mit transition:persist nicht vermeiden.

Ob Sie das brauchen, hängt am Inhalt. Ein Medienplayer, ein Warenkorb-Island oder ein Filter, der beim Blättern erhalten bleiben soll, sind klare Fälle. Eine Website mit zehn Textseiten braucht es nicht.

Datenschutz, Teil 1: was im Browser abgelegt wird. Ein persistentes Island hält den Zustand im Speicher der geöffneten Seite. Legen Sie dagegen etwas im Browser ab, etwa die Wahl des dunklen Themas in localStorage (das Beispiel der Astro-Dokumentation), greift § 25 TDDDG: Speicherung auf der Endeinrichtung und Zugriff darauf sind nur mit Einwilligung zulässig, außer sie sind unbedingt erforderlich, damit ein vom Nutzer ausdrücklich gewünschter digitaler Dienst bereitgestellt werden kann. Ob das im Einzelfall zutrifft, beurteilt Ihre Rechtsberatung. Ich liste im Umfang jede Speicherung auf.

Datenschutz, Teil 2: die Erklärung. Zuständig für Unternehmen in Münster ist die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW). Ihr Muster für Datenschutzhinweise nennt als Anlass für eine Ergänzung der Erklärung unter anderem Cookies und andere aktive Inhalte wie Videoplayer. Wer persistente Player oder Themenspeicher einführt, ergänzt die Erklärung also.

#Barrierefreiheit: Ansage, Bewegung, Fokus

MDN beschreibt, welche Probleme eigenhändig gebaute Übergänge in einer Single-Page-App erzeugen können: verlorene Leseposition, Fokus-Verwirrung und seltsames Verhalten bei Live-Regionen, wenn alter und neuer Inhalt gleichzeitig im DOM stehen. Astro hat für die wichtigsten Punkte Vorkehrungen getroffen.

Ansage des Seitenwechsels. Bei einem klassischen Seitenwechsel sagt die assistive Technik den neuen Titel an. Der ClientRouter ersetzt das laut Dokumentation durch ein eingefügtes Element mit aria-live="assertive". Der Text kommt in dieser Reihenfolge aus dem <title>, der ersten <h1> oder dem Pfad der Seite. Astro empfiehlt ausdrücklich, auf jeder Seite einen <title> zu setzen. Für Sie heißt das: Die Seitentitel entscheiden darüber, was Screenreader-Nutzer hören, und sie bleiben bei mir pro Seite eindeutig.

Reduzierte Bewegung. Der ClientRouter enthält laut Dokumentation eine CSS-Media-Query, die alle Übergangsanimationen abschaltet, auch die Rückfallanimation, wenn prefers-reduced-motion erkannt wird. Der Browser tauscht dann nur die DOM-Elemente aus. Beim nativen Weg lege ich die Regel selbst fest und binde das Einschalten an die Bewegungspräferenz:

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

Fokus. Die Dokumentation zeigt in ihrem Beispiel für eine eigene Swap-Funktion, dass die Standardlogik den Fokus sichert und nach dem Tausch des body wiederherstellt (saveFocus). Wer eine eigene Swap-Funktion baut, muss das daher mitbedenken. Ich teste die Tastaturfolge nach einem Seitenwechsel selbst: Was hat den Fokus, wo beginnt ein Tab, wird nach dem Wechsel zum Hauptinhalt gesprungen? Was ich dabei finde, steht im schriftlichen Abnahmeprotokoll.

Zum Geltungsbereich des BFSG und zur Frage, wer die Einhaltung prüft, finden Sie Details auf der Seite Barrierefreie Website bei der Migration zu Astro oder Next.js in Münster.

#Wann eine Multi-Page-Website mit diesen Bausteinen besser ist als eine Single-Page-App

Das ist meine Einschätzung, aufgebaut auf den oben beschriebenen Eigenschaften:

Der Kern: Ein klassischer Seitenwechsel mit Prefetch ist die Standardeinstellung von Astro, und alles, was darüber hinausgeht, ist eine Entscheidung mit Wartungsaufwand. Nehmen Sie diese Entscheidung bewusst.

#Checkliste vor dem Einschalten von Seitenwechseln

Sie können sie auch ohne mich verwenden:

#So läuft ein Projekt mit mir

Alles ist schriftlich.

1. Briefing. Sie nennen mir die Adresse Ihrer Website, Ihr Ziel, den Termin und den aktuellen Stack. Fehlende Angaben erfrage ich per E-Mail.
2. Umfang und Annahmen. Ich halte fest, ob es klassische Navigation, nativen Übergang oder ClientRouter gibt, was erhalten bleiben soll, welche Skripte betroffen sind und was ich von Ihnen voraussetze. Gestaltung, Grafik und Wireframes liefern Sie, die technische Umsetzung übernehme ich. Ich beginne erst, nachdem Sie den Umfang schriftlich bestätigt haben.
3. Aufbau auf einer Testumgebung. Sie sehen den Stand auf einer Vorschau-Adresse und können Navigation, Tastatur und die Einstellung für reduzierte Bewegung selbst ausprobieren.
4. Abnahme. Maßstab der Abnahme ist der schriftlich bestätigte Umfang. Wünsche über diesen Umfang hinaus kalkuliere ich als neues Angebot.
5. Start und Wartung (optional). Nach dem Start übernehme ich auf Wunsch Updates und Abhängigkeiten. Wie das abläuft, steht auf der Seite Wartung und Support in Münster. Stunden aus einem Wartungsmonat werden nicht in den nächsten übertragen.

#Häufige Fragen

#Brauche ich den ClientRouter, damit meine Astro-Website schnell wirkt?

Nein. Laut Dokumentation ist jeder Seitenwechsel standardmäßig ein normaler Browser-Seitenwechsel. Prefetch lässt sich auch ohne ClientRouter einschalten, und der Browser kann Übergänge zwischen Dokumenten mit @view-transition selbst animieren. Den ClientRouter setze ich nur ein, wenn Sie persistente Elemente oder Client-Routing brauchen.

#Was geht bei Safari und Firefox verloren?

Laut Chrome-Dokumentation sind dokumentübergreifende View Transitions in Chrome und Edge ab 126 und in Safari ab 18.2 verfügbar, Firefox ist dort als nicht unterstützt geführt. Ohne Unterstützung wechselt der Browser die Seite ohne Animation. Der ClientRouter hat zusätzlich eine eigene Rückfalloption (fallback), die Animationen nachahmt.

#Warum funktioniert mein Menüskript nach dem ersten Seitenwechsel nicht mehr?

Gebündelte Modulskripte laufen laut Dokumentation nur einmal. Mit dem ClientRouter hänge ich Initialisierungscode an das Ereignis astro:page-load, das nach jedem Seitenwechsel auslöst.

#Wird ein Seitenwechsel für Screenreader angesagt?

Ja. Der ClientRouter fügt laut Dokumentation ein Element mit aria-live="assertive" ein und nennt zuerst den title, dann die erste h1, sonst den Pfad. Deshalb braucht jede Seite einen aussagekräftigen title.

#Brauche ich ein Einwilligungsbanner, wenn ich Zustand zwischen Seiten behalte?

Ein Island mit transition:persist hält den Zustand im Speicher der geöffneten Seite und legt nichts im Browser ab. Speichern Sie dagegen etwas in localStorage, greift § 25 TDDDG, und die LDI NRW verlangt eine ergänzte Datenschutzerklärung. Die rechtliche Bewertung gehört zu Ihrer Rechtsberatung, ich liste jede Speicherung im Umfang auf.

#Kommen Sie für das Projekt nach Münster?

Nein. Mein Arbeitsplatz ist Gdynia, und alles läuft über E-Mail und Kontaktformular: Briefing, Rückfragen, Umfang, Abnahme auf einer Testumgebung. Auf Meetings und Telefonate verzichte ich. Meine erste schriftliche Einschätzung zu Ihrem Vorhaben kostet Sie nichts.

#Schreiben Sie mir

Schicken Sie mir über das Kontaktformular die Adresse Ihrer Website, Ihr Ziel, Ihren Termin und den aktuellen Stack, am besten mit dem Hinweis, ob heute Skripte von Drittanbietern oder ein Player laufen, der beim Blättern erhalten bleiben soll. Ich lese alles, melde mich mit Rückfragen und schicke Ihnen eine erste Einschätzung zu Umfang und Annahmen. Dafür berechne ich nichts. Wenn Astro für Ihr Vorhaben die falsche Wahl ist, steht das in meiner Antwort, samt Alternative.