View Transitions killen den letzten Grund für SPAs

Cross-Document View Transitions laufen 2026 stabil. Statische Seiten fühlen sich an wie native Apps, ohne SPA-Router.

Jahrelang gab es genau ein Argument, das den SPA-Zwang verteidigt hat: "Aber die Seitenübergänge!". Wenn ein Klick auf einen Artikel die ganze Seite weißblitzt, fühlt sich das billig an. Native Apps machen das nicht. Also haben wir React Router oder Next.js dazwischengeschoben und für jeden Mini-Blog 200 KB JavaScript ausgeliefert, damit nichts blitzt.

Das Argument ist tot.

Was sich konkret geändert hat

Same-Document View Transitions (innerhalb einer SPA) gibt es seit Chrome 111, Firefox 133 und Safari 18. Das war nett, aber löste nur das halbe Problem. Spannend wird es erst, wenn der Browser zwischen zwei echten HTML-Dokumenten morphen kann. Das läuft seit Chrome 126 stabil. Safari und Firefox sind dran. Für die Mehrheit der User funktioniert es heute schon, der Rest sieht den klassischen harten Wechsel. Progressive Enhancement at its best.

Du opt-inst pro Origin mit einer einzigen Zeile CSS:

@view-transition {
  navigation: auto;
}

Mehr braucht es nicht. Jeder reguläre Klick auf einen internen Link löst jetzt einen Cross-Fade statt eines harten Weißblitzes aus.

Wo es wirklich klickt: Shared Element Morphs

Der Cross-Fade ist Pflicht, nicht Kür. Der eigentliche Spaß beginnt bei view-transition-name. Wenn ein Element auf zwei Seiten denselben Namen trägt, animiert der Browser zwischen den beiden Positionen. Position, Größe, Border-Radius. Das ist die "magic move" Bewegung aus iOS und Android.

Konkretes Beispiel. Auf der Übersicht ein Projektgrid:

.project-card img {
  view-transition-name: var(--project-slug);
}

Auf der Detailseite das große Hero-Bild:

.project-hero img {
  view-transition-name: var(--project-slug);
}

Das --project-slug setzt du pro Karte individuell, etwa als Inline-Style. Klick auf eine Karte: das Thumbnail wandert an die Stelle des Heros und skaliert sich hoch. Back-Button: wieder rein in seine Grid-Zelle. Eine HTML-Seite zu einer anderen. Ohne JavaScript.

Was die meisten Tutorials verschweigen

Drei Stolpersteine, an denen ich hängengeblieben bin.

Erstens: view-transition-name muss innerhalb einer Seite eindeutig sein. Zwei Elemente mit demselben Namen brechen die Transition komplett ab. Wenn du das Grid und einen versteckten Detail-Container gleichzeitig im DOM hast, funktioniert nichts. Lösung: den Namen nur auf dem aktuell sichtbaren Element setzen.

Zweitens: Bilder müssen identische object-fit-Werte haben, sonst springt der Aspect Ratio mitten in der Animation. Klingt offensichtlich, kostet aber gerne eine Stunde Debugging.

Drittens: Browser-initiierte Zurück-Navigation hat keinen Navigation Type. Gerichtete Slides (links rein, rechts raus) klappen nur, wenn du JavaScript für die Richtung dranhängst. Shared Element Morphs funktionieren glücklicherweise auch ohne diese Info.

Was das für meine Projekte heißt

Ich baue gerade einen Portfolio-Relaunch und einen Kundenshop. Beides klassisches Multi-Page, ausgeliefert als statisches HTML. Vorher hätte ich überlegt, ob ein SPA-Router den Mehraufwand wert ist, nur damit zwischen Seiten kein Weißblitz passiert. Heute schreibe ich vier Zeilen CSS und kriege Übergänge, die besser aussehen als die meisten React-Router-Hacks aus 2024.

Astro hat das Ganze bereits in eine transition:name-Direktive abstrahiert. Next.js liefert eigene <ViewTransition>-Komponenten. Für eine statische Seite brauchst du keines davon. Sauberes CSS auf sauberer HTML-Struktur reicht.

Der eigentliche Gewinn

Das ist kein einzelnes Feature. Das ist ein Pattern, das sich durch alle CSS-Updates der letzten zwei Jahre zieht. Container Queries, :has(), Anchor Positioning, jetzt View Transitions. Lauter Sachen, für die wir früher JavaScript-Bibliotheken installiert haben. Heute schreibst du CSS.

Konkret heißt das: weniger Build-Schritte, kleinere Bundles, weniger Dependencies, die irgendwann veralten. Eine Seite lädt in 200 ms statt in 1.5 Sekunden. Der User spürt das, auch wenn er es nicht benennen kann.

Für mich als Solo-Freelancer ist das Gold wert. Ich liefere statische Seiten aus, die sich wie Apps anfühlen, und brauche keinen React-Stack mehr, der nur existiert, um Seitenwechsel zu animieren. Die nächste Generation von Websites kommt mit weniger Framework und mehr Plattform aus.

Sources: