Der Klick auf ein Produkt sollte sich anfühlen wie das Umblättern einer Seite -- doch in vielen Shops blitzt zwischen Kategorie und Produkt für den Bruchteil einer Sekunde eine weiße Fläche auf. Der Browser verwirft die alte Seite, baut die neue von Grund auf neu auf, und genau dieser harte Schnitt lässt selbst schnelle Seiten träge wirken. Lange war die einzige Antwort darauf ein JavaScript-Framework, das aus dem Shop eine Single-Page-Anwendung macht und die Navigation komplett selbst übernimmt -- mit allen Kosten an Komplexität, Wartung und Hauptthread-Last. Seit 2024 gibt es einen einfacheren Weg: Die Cross-Document View Transitions API bringt native, vom Browser gerenderte Seitenwechsel in klassische Multi-Page-Shops, aktiviert durch eine einzige CSS-Regel und ganz ohne JavaScript-Framework (web.dev). Dieser Beitrag zeigt, wie die View Transitions API funktioniert, worin sich Same-Document und Cross-Document unterscheiden, wie geteilte Elemente wie das Produktbild von einer Seite zur nächsten morphen und was das Ganze für Core Web Vitals und Conversion bedeutet. In unserer Core-Web-Vitals-Optimierung prüfen wir solche Techniken grundsätzlich daraufhin, ob sie die wahrgenommene Geschwindigkeit messbar verbessern, statt nur gut auszusehen.
Das Wichtigste in Kürze
- Cross-Document View Transitions animieren den Wechsel zwischen zwei echten HTML-Dokumenten und bringen weiche Seitenwechsel in klassische Multi-Page-Shops -- aktiviert per CSS und ohne JavaScript-Framework (web.dev).
- Aktiviert wird das über die At-Regel @view-transition mit navigation: auto im Stylesheet von Ausgangs- und Zielseite, die beide zur selben Herkunft gehören müssen (MDN). Die früher übliche Meta-Tag-Variante gilt als überholt (Chrome for Developers).
- Geteilte Elemente behalten über view-transition-name ihre Identität: Das Produktbild der Kategorieübersicht wächst beim Klick sichtbar zum großen Bild der Produktseite heran, ohne dass ein Skript die Zwischenschritte berechnet.
- Chrome liefert die Cross-Document-Übergänge seit Version 126 im Juni 2024 aus (Chrome for Developers), Safari seit Version 18.2 im Dezember 2024 (MDN). Fehlt die Unterstützung, navigiert der Browser wie gewohnt -- ohne Polyfill und ohne Weiche.
- Die Animation läuft auf dem Compositor, belastet den Hauptthread kaum und zählt nicht als unerwarteter Layout-Sprung. Der Gewinn liegt in der Wahrnehmung: 0,1 Sekunden (Deloitte) schnellere Ladezeit hoben die Konversionsrate im Einzelhandel um 8,4 Prozent (Deloitte).
Warum Seitenwechsel im Shop bisher ruckeln
Ein klassischer Multi-Page-Shop lädt bei jedem Klick ein komplett neues HTML-Dokument. Der Browser reißt die bestehende Darstellung ab, zeigt kurz den leeren Hintergrund und zeichnet die Zielseite dann Stück für Stück neu -- ein sichtbarer Bruch, der als Ruckeln oder Flackern wahrgenommen wird. Auf schnellen Verbindungen fällt das kaum auf, auf einem durchschnittlichen Mobilgerät im Mobilfunknetz dagegen deutlich. Und Geschwindigkeit entscheidet über Umsatz: 53 Prozent (Google) der mobilen Nutzer verlassen eine Seite, die länger als drei Sekunden zum Laden braucht, und die Wahrscheinlichkeit eines Absprungs steigt um 32 Prozent (Google), wenn sich die Ladezeit von einer auf drei Sekunden erhöht. Schon 47 Prozent (Akamai) der Nutzer erwarten, dass eine Seite in unter zwei Sekunden erscheint. Wie eng Ladezeit und Kaufabschluss zusammenhängen, vertiefen wir im Beitrag zu Ladezeit, Conversion-Rate und Umsatz.
Um das harte Umschalten zu vermeiden, sind viele Shops in den vergangenen Jahren auf Single-Page-Architekturen umgestiegen: Ein JavaScript-Framework fängt jeden Klick ab, lädt nur die Daten der Zielseite nach und tauscht den sichtbaren Bereich weich aus. Das Ergebnis wirkt flüssig, hat aber einen Preis. Der Browser muss ein umfangreiches Skript-Bündel laden, ausführen und die Oberfläche im laufenden Betrieb selbst verwalten -- Arbeit, die auf dem Hauptthread landet und die Reaktionsschnelligkeit gefährden kann. Zudem verschiebt sich die Verantwortung für Verlauf, Scroll-Position und Server-Rendering vom Browser in den eigenen Code. Warum serverseitiges Rendern und die anschließende Hydration ihrerseits zur Ladebremse werden können, behandeln wir im Beitrag zu Server-Side-Rendering und Hydration. Die View Transitions API kehrt dieses Verhältnis um: Sie gibt die weichen Übergänge zurück an den Browser, ohne die Multi-Page-Architektur aufzugeben.
Was die View Transitions API macht
Same-Document und Cross-Document: der Unterschied
Die View Transitions API gibt es in zwei Ausprägungen. Die ältere, Same-Document-Variante läuft innerhalb eines einzigen Dokuments und richtet sich an Single-Page-Anwendungen: JavaScript ändert den DOM, und die API animiert den Übergang zwischen altem und neuem Zustand. Chrome hat diese Variante bereits im März 2023 mit Chrome 111 ausgeliefert (Chrome for Developers). Sie ist wirkungsvoll, setzt aber weiterhin voraus, dass die Anwendung die Navigation selbst steuert. Wie sich solche skriptgetriebenen Wechsel überhaupt sauber messen lassen, zeigt der Beitrag zu Soft Navigations und Core Web Vitals.
Die neuere, für Shops entscheidende Variante ist Cross-Document: Sie animiert den Übergang zwischen zwei echten, getrennten HTML-Dokumenten -- also genau bei der klassischen Navigation von einer URL zur nächsten. Damit erhält ein Multi-Page-Shop dieselben weichen Wechsel wie eine Single-Page-Anwendung, ohne dass eine einzige Zeile JavaScript nötig wäre (web.dev). Der Browser erkennt die Navigation, hält kurz die alte Ansicht fest, lädt das neue Dokument und blendet weich über. Voraussetzung ist lediglich, dass beide Seiten zur selben Herkunft (Origin) gehören und beide der Transition per CSS zustimmen. Genau diese Variante hebt den alten Zielkonflikt auf, bei dem man sich zwischen einfacher Multi-Page-Architektur und flüssigem App-Gefühl entscheiden musste.
| Merkmal | Same-Document (SPA) | Cross-Document (MPA) |
|---|---|---|
| Auslöser | JavaScript ändert den DOM | Navigation zwischen zwei URLs |
| JavaScript-Framework | in der Regel erforderlich | nicht nötig |
| Aktivierung | startViewTransition() im Code | @view-transition per CSS |
| Typischer Einsatz | App-artige Oberflächen | klassische Shops und Websites |
| Hauptthread-Last | durch das Framework erhöht | gering, der Browser übernimmt |
So aktivieren Sie native Übergänge ohne JavaScript
Für einen klassischen Shop ist der Einstieg denkbar knapp. Beide beteiligten Seiten -- die Ausgangs- und die Zielseite -- müssen in ihrem Stylesheet der Cross-Document-Transition zustimmen. Das geschieht über die CSS-At-Regel @view-transition mit dem Deskriptor navigation: auto. Sobald diese Regel auf beiden Seiten steht und beide zur selben Herkunft gehören, blendet der Browser bei jeder Navigation automatisch weich über -- standardmäßig als sanftes Überblenden der gesamten Seite (MDN). Die früher übliche Meta-Tag-Variante gilt als überholt; die CSS-At-Regel ist der aktuelle Weg (Chrome for Developers).
/* Auf Ausgangs- und Zielseite, gleiche Herkunft vorausgesetzt */
@view-transition {
navigation: auto;
}
/* Dauer des Standard-Übergangs anpassen */
::view-transition-old(root),
::view-transition-new(root) {
animation-duration: 0.25s;
}
/* Geteiltes Element: das Produktbild behält seine Identität */
.produkt-bild {
view-transition-name: hero-produktbild;
}Mehr braucht es für den ersten weichen Übergang nicht. Wer die Bewegung feiner steuern will, greift auf die Pseudo-Elemente ::view-transition-old und ::view-transition-new zu und beschreibt darüber Dauer, Zeitkurve oder Richtung der Animation. Weil alles über CSS läuft, bleibt der Hauptthread frei für das, was wirklich zählt: die Interaktivität. Diese saubere Trennung zwischen Darstellung und Logik ist einer der Gründe, warum native Übergänge gut in eine schlanke Frontend-Optimierung passen.
Geteilte Elemente: das Produktbild morpht mit
Der eindrucksvollste Effekt entsteht mit geteilten Elementen. Bekommt ein Element auf beiden Seiten denselben Namen über die CSS-Eigenschaft view-transition-name, erkennt der Browser es als dasselbe Objekt und bewegt es weich von seiner alten an seine neue Position -- statt es auszublenden und woanders neu einzublenden. Im Shop heißt das: Das kleine Produktbild in der Kategorieübersicht wächst beim Klick sichtbar zum großen Bild auf der Produktseite heran. Der Nutzer behält den Bezug, weil das Objekt visuell bestehen bleibt. Genau dieser Zusammenhang senkt die kognitive Last und lässt den Wechsel schnell und selbstverständlich wirken -- ein Effekt, den man aus nativen Apps kennt und der im Web bislang teuer erkauft werden musste.
Element benennen
Über view-transition-name erhält ein Element auf beiden Seiten dieselbe Identität. Der Browser weiß dadurch, dass Miniatur und großes Bild dasselbe Objekt sind, und animiert den Weg dazwischen selbst.
Position morphen
Der Browser interpoliert Größe und Ort automatisch. Das Produktbild wandert und wächst in einer Bewegung von der Übersicht zur Detailseite, ohne dass ein Skript die Zwischenschritte berechnet.
Mit CSS gestalten
Dauer, Kurve und Richtung liegen vollständig im Stylesheet. So passt der Übergang zum Charakter der Marke und lässt sich für zurückhaltende Nutzer per prefers-reduced-motion aussetzen.
Browser-Unterstützung 2026 und Progressive Enhancement
Cross-Document View Transitions sind 2026 in den meisten Browsern angekommen. Chrome liefert sie seit Version 126 im Juni 2024 aus (Chrome for Developers), Safari zog mit Version 18.2 im Dezember 2024 nach (MDN). Firefox unterstützt die Same-Document-Variante seit Version 144 im Oktober 2025 und arbeitet an der Cross-Document-Unterstützung (MDN). Damit liefern zwei der drei großen Browser-Engines die nahtlosen Seitenwechsel bereits aus, die dritte folgt. Für die Praxis heißt das: In modernen Chromium- und WebKit-Browsern sehen Nutzer den weichen Übergang, in älteren Browsern die gewohnte, sofortige Navigation.
Kein Risiko dank Progressive Enhancement
Wirkung auf Core Web Vitals: CLS und wahrgenommene Geschwindigkeit
Ein häufiges Missverständnis ist, ein weicher Übergang koste Performance. Das Gegenteil kann der Fall sein. Weil der Browser die Animation auf dem Compositor abwickelt, belastet sie den Hauptthread kaum und läuft auch auf schwächeren Geräten gleichmäßig, statt zu ruckeln -- ähnlich wie bei jeder gut umgesetzten, flüssigen Animation ohne Ruckeln. Für den Cumulative Layout Shift, den Messwert für visuelle Stabilität, ist wichtig zu wissen: Die während einer View Transition ablaufende Bewegung zählt nicht als unerwarteter Layout-Sprung, solange sie durch die Navigation ausgelöst wurde. Wie sich unerwünschte Sprünge dagegen gezielt vermeiden lassen, behandelt der Beitrag zu Cumulative Layout Shift im Shop.
Der größte Gewinn liegt in der wahrgenommenen Geschwindigkeit. Untersuchungen zeigen, dass schon minimale Beschleunigungen den Umsatz bewegen: Eine um 0,1 Sekunden (Deloitte) schnellere Ladezeit steigerte in einer breit angelegten Studie die Konversionsrate im Einzelhandel um 8,4 Prozent (Deloitte). Ein flüssiger Übergang verkürzt zwar nicht die tatsächliche Ladezeit, überbrückt aber die kurze Wartezeit visuell und lässt die Seite dadurch schneller und hochwertiger erscheinen. Gerade weil nur 62 Prozent (Web Almanac 2025) der mobilen Websites einen guten Largest Contentful Paint unter 2,5 Sekunden erreichen, ist jede Wahrnehmungsverbesserung ohne technische Verteuerung wertvoll. Auf die Reaktionsschnelligkeit, gemessen als Interaction to Next Paint, wirken native Übergänge neutral bis positiv, weil sie den Hauptthread nicht zusätzlich blockieren.
Der Kern in einem Satz
Umsetzung im Shop: worauf es praktisch ankommt
In der Praxis sind einige Bedingungen zu beachten, damit die Übergänge sauber greifen. Beide Seiten müssen zur selben Herkunft gehören -- ein Wechsel auf eine fremde Domain löst keine Transition aus. Beide Dokumente müssen der Transition per CSS zustimmen, sonst bleibt es beim harten Schnitt. Geteilte Elemente brauchen auf beiden Seiten denselben, eindeutigen view-transition-name; kommt derselbe Name zweimal gleichzeitig vor, bricht die Zuordnung. Und schnelle Klickfolgen sollten nicht auf eine lange Animation warten müssen: Eine kurze Dauer von etwa einer Viertelsekunde hält den Übergang spürbar, aber nicht hinderlich. Wer die Navigation zusätzlich beschleunigen möchte, kombiniert die Übergänge mit vorausschauendem Laden über Speculation Rules für sofortige Navigation.
- @view-transition mit navigation: auto auf Ausgangs- und Zielseite ins Stylesheet aufnehmen
- Beide Seiten unter derselben Herkunft ausliefern -- sonst bleibt die Transition aus
- Das Produktbild als geteiltes Element mit eindeutigem view-transition-name auszeichnen
- Dauer und Kurve knapp halten und für prefers-reduced-motion zurücknehmen
- In Chrome und Safari sowie in einem Browser ohne Unterstützung gegenprüfen
- Vorher und nachher messen: Reaktionsschnelligkeit und Layout-Stabilität dürfen sich nicht verschlechtern
Wie bei jeder Frontend-Technik gilt: messen statt vermuten. Ein weicher Übergang darf die Reaktionsschnelligkeit nicht verschlechtern und keine Layout-Sprünge einführen. Auf sehr langsamen Verbindungen oder im Sparmodus kann es zudem sinnvoll sein, die Animation zurückzunehmen -- wie sich Seiten generell an schwache Netze anpassen lassen, zeigt der Beitrag zum adaptiven Laden für langsame Netze. Und weil aufwendige Übergänge, die den Hauptthread beschäftigen, die Interaktivität gefährden können, lohnt der Blick darauf, wie sich rechenintensive Aufgaben über Web Worker vom Main-Thread auslagern lassen.
Native Seitenübergänge sind der seltene Fall, in dem ein Shop spürbar hochwertiger wirkt, ohne dass eine einzige Ressource zusätzlich geladen wird. Wir führen sie als Progressive Enhancement ein und prüfen anschließend in den Felddaten, ob Stabilität und Reaktionsschnelligkeit unberührt bleiben.
So gehen wir auch im Projekt vor: Wir aktivieren die Übergänge, benennen die geteilten Elemente, halten die Animation dezent und messen den Effekt anschließend im Feld. Native View Transitions sind dabei ein Baustein unter vielen -- sie ersetzen keine schnelle Serverantwort und kein schlankes Frontend, sondern setzen obendrauf. Welche Maßnahmen in welcher Reihenfolge den größten Effekt bringen, ordnen wir in unserer Übersicht der Performance-Leistungen ein, speziell für Shops in der Shopware-Performance. Wer die drei Core Web Vitals im Zusammenhang verstehen möchte, findet die Einordnung im Beitrag zu den Core Web Vitals 2026.