View Transitions API: flüssige Seitenübergänge ohne Framework

Es gibt diesen einen Effekt, der eine Website sofort teuer aussehen lässt: Man klickt auf ein Produkt, und statt eines harten Seitensprungs gleitet das Bild sanft an seine neue Position, der Rest blendet weich nach. Lange war das ein Privileg von Single-Page-Apps - man erkaufte es sich mit React, einem Router und einer Animationsbibliothek wie Framer Motion oder GSAP, und bezahlte mit Komplexität, JavaScript-Ballast und einer Architektur, die man eigentlich gar nicht wollte.

Seit die View Transitions API in den Browsern angekommen ist, stimmt diese Rechnung nicht mehr. Denselben Effekt gibt es jetzt nativ - mit ein paar Zeilen CSS, und inzwischen sogar auf ganz normalen Websites, die aus separaten HTML-Seiten bestehen. Ich baue solche Seiten für Kunden und habe die API im Einsatz, deshalb hier der Praxisstand 2026: was wirklich geht, wo die Grenzen liegen und wann sich der Aufwand lohnt.

Das Grundprinzip in einem Satz

Die View Transitions API funktioniert immer nach demselben Muster: Der Browser macht ein Standbild vom alten Zustand, tauscht im Hintergrund den Inhalt aus, macht ein Standbild vom neuen Zustand - und blendet dann per CSS-Animation vom einen ins andere. Man beschreibt also nicht die Animation Schritt für Schritt, sondern sagt dem Browser nur: Hier ist vorher, hier ist nachher, mach den Rest. Das ist der ganze Trick, und er ist der Grund, warum so wenig Code nötig ist.

Der einfache Fall: Übergänge innerhalb einer Seite

Klassisch kam die API aus der Single-Page-Welt, wo sich der Inhalt per JavaScript ändert, ohne dass die Seite neu lädt. Dort umschließt man die DOM-Änderung mit einem einzigen Aufruf:

if (document.startViewTransition) {
  document.startViewTransition(() => updateDOM());
} else {
  updateDOM(); // Browser ohne Unterstützung: einfach direkt aktualisieren
}

updateDOM() ist die Funktion, die den Inhalt tatsächlich austauscht - eine Liste filtert, ein Detail einblendet, was auch immer. Der Browser kümmert sich um den Rest: Standbild vorher, Standbild nachher, weiche Überblendung. Das if ist kein Detail, sondern Pflicht - dazu später mehr bei den Grenzen.

Das zurückgegebene Objekt gibt einem die Kontrolle, falls man sie braucht:

const transition = document.startViewTransition(() => updateDOM());

await transition.ready;    // Animation startet gleich - jetzt z.B. eigene Effekte anstoßen
await transition.finished; // Animation ist durch

Für den Anfang braucht man das selten. Der Standard-Übergang - ein weiches Cross-Fade - kommt ganz ohne diese Promises aus.

Der eigentliche Durchbruch: Übergänge zwischen zwei Seiten

Das Interessante für die meisten echten Websites ist aber nicht die Single-Page-App. Die meisten Unternehmensseiten, Shops und Portfolios bestehen aus ganz normalen, separaten HTML-Seiten - und genau hier war die weiche Überblendung bis vor kurzem technisch unmöglich, weil beim Seitenwechsel das ganze Dokument verworfen wird.

Seit Chrome 126 geht auch das, und zwar erstaunlich unspektakulär. Man schreibt in das CSS beider Seiten - der alten und der neuen - diese Regel:

@view-transition {
  navigation: auto;
}

Das war es. Keine Zeile JavaScript, kein Router, kein Framework. Solange beide Seiten zur selben Domain gehören, blendet der Browser den Wechsel jetzt weich ineinander. Eine statische Seite aus HTML-Dateien bekommt damit dasselbe geschmeidige Gefühl, für das man vorher eine Single-Page-App mitsamt ihrem ganzen Apparat gebraucht hätte.

Für mich ist das der eigentliche Wendepunkt: Der App-Look ist nicht mehr an die App-Architektur gekoppelt. Man kann eine schnelle, schlanke Multi-Page-Website bauen - die aus SEO- und Performance-Sicht ohnehin fast immer die bessere Wahl ist - und bekommt die geschmeidigen Übergänge obendrauf.

Foto: florianolv / Unsplash

Ein Element gezielt wandern lassen

Das weiche Ineinanderblenden der ganzen Seite ist der Standard. Der Effekt, der wirklich beeindruckt, ist ein anderer: Ein einzelnes Element - ein Produktbild, eine Überschrift, eine Karte - bleibt beim Seitenwechsel sichtbar und wandert an seine neue Position, während sich der Rest überblendet. Dafür gibt man dem Element auf beiden Seiten denselben Namen:

.produkt-bild {
  view-transition-name: held-bild;
}

Taucht auf der Übersichtsseite ein Element mit view-transition-name: held-bild auf und auf der Detailseite ebenfalls, versteht der Browser: Das ist dasselbe Ding. Er lässt es von der alten an die neue Stelle gleiten und passt Größe und Position dabei automatisch an. Das ist der Kern des Effekts, der eine Seite teuer aussehen lässt - und er kostet eine Zeile CSS pro Element.

Ein Detail, das schnell zur Falle wird: Jeder view-transition-name muss auf einer Seite eindeutig sein. Vergibt man denselben Namen zweimal - etwa versehentlich in einer Schleife über alle Produktkarten -, bricht der Übergang ab. Für Listen braucht jedes Element seinen eigenen, individuellen Namen.

Wer die Standard-Überblendung durch etwas Eigenes ersetzen will, kann die einzelnen Phasen über Pseudo-Elemente ansprechen:

::view-transition-old(held-bild) {
  animation: 300ms ease-out both raus;
}
::view-transition-new(held-bild) {
  animation: 300ms ease-in both rein;
}

::view-transition-old ist das Standbild des alten Zustands, ::view-transition-new das des neuen. Dazwischen liegen noch ::view-transition-group und ::view-transition-image-pair für feinere Kontrolle - für die allermeisten Fälle reicht aber der eingebaute Übergang, und man rührt diese Ebene gar nicht erst an.

Die Grenzen 2026, klar benannt

So elegant die API ist, sie ist noch nicht überall gleich weit. Der Stand heute:

Übergänge innerhalb einer Seite beherrschen Chrome und Edge ab Version 111, Safari ab 18 und Firefox ab 144 - das ist breit genug für den produktiven Einsatz. Übergänge zwischen zwei Seiten können Chrome und Edge ab 126 sowie Safari ab 18.2, aber Firefox unterstützt diese Variante noch nicht. Wer also auf die Multi-Page-Übergänge setzt, muss wissen, dass ein Teil der Firefox-Nutzer sie vorerst nicht sieht.

Das ist weniger dramatisch, als es klingt, weil die API von Natur aus als Progressive Enhancement gedacht ist: In einem Browser, der sie nicht kann, passiert der Seitenwechsel einfach ohne Animation - hart, aber völlig funktional. Nichts bricht, es fehlt nur der Feinschliff. Genau deshalb ist das if (document.startViewTransition) aus dem ersten Beispiel Pflicht und keine Kür: Es sorgt dafür, dass die Seite auch dort sauber läuft, wo die API fehlt.

Zwei weitere Stolpersteine gehören dazugesagt. Erstens greifen die Seitenübergänge nur bei Navigation innerhalb derselben Domain - ein Wechsel auf eine fremde Seite wird nicht animiert. Zweitens werden während der Standbild-Phase kurz alle Layout-Updates zurückgehalten; wer in diesem Moment aufwendige Berechnungen anstößt, kann unerwartete Ruckler produzieren. In der Praxis fällt das selten auf, aber man sollte es wissen.

Foto: nordwood / Unsplash

Barrierefreiheit ist hier keine Kür

Ein Punkt, den erstaunlich viele Tutorials überspringen, entscheidet darüber, ob der Effekt ein Fortschritt oder ein Ausschluss ist: Bewegung. Weiche, gleitende Übergänge sehen für die meisten schön aus - aber bei Menschen mit vestibulären Störungen können sie Schwindel oder Übelkeit auslösen. Das Betriebssystem kennt dafür eine Einstellung, und der Browser gibt sie über prefers-reduced-motion weiter.

Wer die View Transitions API einsetzt, muss diese Einstellung respektieren - und zwar immer:

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;
  }
}

Damit bekommen Nutzer, die reduzierte Bewegung angefordert haben, den harten, sofortigen Wechsel - ohne gleitende Animation, aber mit demselben Ziel. Das sind wenige Zeilen, und sie sind der Unterschied zwischen einer Website, die alle bedient, und einer, die einen Teil ihrer Besucher unwohl fühlen lässt. Für mich gehört dieser Block untrennbar zu jedem View-Transition-Einsatz dazu.

Wann sich der Einsatz lohnt

Unterm Strich ist die View Transitions API eine der wenigen neuen Web-Techniken, bei denen der Aufwand fast lächerlich niedrig zum Effekt steht. Trotzdem lohnt sich die Frage, ob und wo man sie einsetzt.

Klar lohnend ist sie überall, wo ein Übergang eine echte Beziehung zeigt: von der Produktübersicht ins Detail, von der Blog-Liste in den Artikel, von der Galerie ins Einzelbild. Dort führt das wandernde Element den Blick und macht die Navigation nachvollziehbarer - das ist kein Selbstzweck, sondern Orientierung. Und weil sie als Progressive Enhancement funktioniert, kostet sie nichts außer den paar Zeilen: Wer sie sieht, freut sich, wer sie nicht sieht, vermisst nichts.

Zurückhaltung ist dort angebracht, wo Bewegung vom Inhalt ablenkt oder wo jede Millisekunde zählt und man sich die Standbild-Phase nicht leisten will. Und wer heute schon flächendeckend auf die Multi-Page-Variante setzt, sollte die Firefox-Lücke im Hinterkopf behalten und den Effekt bewusst als Bonus behandeln, nicht als tragende Funktion.

Wenn du überlegst, ob sich solche Übergänge für deine Seite lohnen - oder ob deine Website den App-Look überhaupt braucht, um zu überzeugen: Ich bin Eric Menge von EMIT Solution, erreichbar unter info@emit-solution.com und über emit-solution.com. Ich baue schnelle Websites, die moderne Browser-Techniken wie diese nutzen, wo sie etwas bringen, und weglassen, wo sie nur Ballast wären.