Die Versuchung
Als ich mein Portfolio auf Astro umgestellt habe, war eine Sache sofort klar: Ich brauche View Transitions. Die flüssigen Seitenübergänge sahen in den Demos einfach zu gut aus. Der Fade-Effekt zwischen den Seiten, das sanfte Gleiten der Inhalte – das war genau das “Polished”-Gefühl, das ich wollte.
Also habe ich <ViewTransitions /> in mein BaseLayout geworfen, transition:persist auf Header und Footer gesetzt, und transition:animate="slide" auf das Main-Element gepackt.
Lokal sah alles perfekt aus.
Die Realität
Nach dem Deploy fingen die Probleme an:
1. Das Changelog-Phantom
Meine Changelog-Seite war plötzlich… leer. Naja, nicht wirklich leer – im DOM war alles da, aber es war unsichtbar. Die Seite lud, der Content war da, aber er war ausgefadet und kam nie zurück.
Die Ursache? Der fade-in Animation-Trigger vom Scroll-Observer kollidierte mit den View Transitions. Beim Wegnavigieren wurde die Seite ausgefadet (opacity: 0), aber beim Zurückkommen hat der IntersectionObserver nicht mehr gefeuert – die Sektion war bereits im Viewport, also wurde .visible nie hinzugefügt.
2. Der tote Blog
Die Kategorie-Filter und Sortierung auf meiner Blog-Seite funktionierten nicht mehr. Klick auf “Homelab”? Nichts passiert. Sortierung umkehren? Ignoriert.
Schuld war das Event-System. Das Script lauschte auf astro:page-load – ein Event, das Astro bei View Transitions feuert. Aber wenn man von einer Seite ohne View Transitions kam (oder wenn was schiefging), feuerte es nicht. Die Initialisierung lief nie.
3. Snake kam nicht wieder
Mein Snake-Game-Widget auf der Startseite war nach Navigation komplett tot. Das Canvas existierte, aber keine Bewegung. Die Event Listener waren auf dem alten DOM-Element, das Astro bei der Transition ersetzt hatte.
Die Analyse
Ich habe Stunden damit verbracht, die Scripts umzuschreiben:
- Frische DOM-Queries bei jedem Frame? Check.
astro:page-load+DOMContentLoaded? Check.- Rigoroses Cleanup alter Timer und Listener? Check.
Es funktionierte. Meistens. Aber bei schnellem Hin-und-Her-Navigieren oder wenn der Browser den Back-Button verwendete, gab es immer wieder Edge Cases.
Und dann die Erkenntnis: Ich habe mehr Zeit damit verbracht, View Transitions zum Laufen zu bringen, als jemals ein Besucher Zeit damit verbringen würde, sie zu bewundern.
Die Entscheidung
Ich habe View Transitions komplett entfernt. Alle transition:persist, alle transition:animate, das <ViewTransitions /> Component aus dem Layout.
Und was passierte?
Nichts.
Naja, fast nichts. Die Seiten laden jetzt ~50ms schneller (kein Client-Side JavaScript für die Transitions mehr). Die Scripts sind halb so lang. Es gibt keine Edge Cases mehr.
Die Seite fühlt sich… normal an. Ein Klick, die Seite lädt. Wie 99% des Internets. Und das ist okay.
Lessons Learned
View Transitions sind toll für:
- Seiten mit wenig Interaktivität
- Content-Heavy Sites ohne viel JavaScript
- Showcase-Sites, wo jede Millisekunde Animation zählt
View Transitions sind Ärger für:
- Seiten mit vielen DOM-Events
- Games oder interaktive Widgets
- Komplexe Filter/Sortierungen im Client
- Sites, wo Zuverlässigkeit wichtiger ist als “Wow-Effekt”
Der pragmatische Ansatz
Wenn ich View Transitions heute neu einbauen würde:
- Ohne starten. Einfache Seiten-übergänge sind okay.
- Dann hinzufügen wenn alles stabil läuft und ich Langeweile habe.
- Nur auf bestimmten Seiten aktivieren, nicht global.
Astro macht es super einfach, View Transitions zu nutzen – aber genau deshalb sollte man sich fragen: Brauche ich das wirklich?
In meinem Fall war die Antwort: Nein.
Falls du View Transitions bei Astro nutzt: Respekt. Es sieht cool aus. Aber vielleicht teste mal, wie deine Seite ohne läuft. Du könntest überrascht sein, wie wenig du die Animation vermisst – und wie viel stabiler alles wird.