View Transitions API: flüssige Seitenwechsel im Shop

Klassische Online-Shops sind fast immer Multi-Page-Anwendungen: Jeder Klick auf ein Produkt lädt eine komplett neue HTML-Seite. Genau dieser harte Sprung - weißes Aufblitzen, springendes Layout - lässt viele Shops im direkten Vergleich mit Single-Page-Apps träge wirken. Die View Transitions API ändert das grundlegend: Seit Chrome 126 (Juni 2024) und Safari 18.2 (Dezember 2024) beherrschen die großen Engines Cross-Document-Übergänge, die rund 83 % der weltweiten Nutzer erreichen (caniuse.com). Damit bekommen selbst simple Kategorie-zu-Produkt-Wechsel weiche, app-artige Animationen - ohne JavaScript-Framework und ohne Rewrite. Dieser Praxisleitfaden zeigt, wie Sie @view-transition, view-transition-name, die Events pageswap/pagereveal und Speculation Rules sauber, performant und barrierearm im Shop-Frontend umsetzen - passend für Shopware-Shops mit Blick auf Core Web Vitals.

Warum flüssige Seitenwechsel jetzt möglich sind

Bis 2024 waren weiche Übergänge zwischen zwei echten HTML-Seiten technisch kaum machbar - man brauchte ein Single-Page-Framework, das die Navigation komplett in JavaScript nachbaute. Genau das ist der Grund, warum "App-Gefühl" lange als teures SPA-Feature galt. Cross-Document View Transitions kehren das um: Der Browser macht vor der Navigation eine Momentaufnahme der alten Seite, lädt die neue Seite normal und blendet dann automatisch zwischen beiden Snapshots über. Die alte und die neue Seite sind dabei weiterhin zwei getrennte Dokumente - der Übergang ist reine Präsentation. Voraussetzung ist nur, dass beide Seiten same-origin sind und beide das Opt-in setzen (MDN Web Docs).

Browser-Support 2026: aus Experiment wird Standard

Der entscheidende Wendepunkt kam Ende 2024: Chrome und Edge liefern Cross-Document-Transitions seit Version 126 (Juni 2024), Safari zog mit 18.2 im Dezember 2024 nach (Chrome for Developers). Damit unterstützen erstmals alle großen Rendering-Engines dieselbe Opt-in-Syntax. Laut caniuse liegt die weltweite Abdeckung für Cross-Document-Transitions bei rund 83 %, für Same-Document-Transitions sogar bei 88 % (caniuse.com). Firefox zeigt das Feature bisher nur teilweise - der @view-transition-Block wird dort aktuell ignoriert, die Navigation funktioniert aber ganz normal (caniuse.com).

Für die Praxis heißt das: View Transitions sind ein klassisches Progressive-Enhancement-Feature. Sie bauen den Übergang für die rund 83 % ein, die ihn sehen - alle anderen bekommen den gewohnten, funktional identischen Seitenwechsel (caniuse.com). Es gibt keinen Grund zu warten, bis "alle" Browser mitziehen, weil das Risiko eines Regressionsfehlers gegen null geht. Genau diese Eigenschaft macht das Feature so attraktiv für produktive Shops, die auf gute Core Web Vitals angewiesen sind. Die formale Grundlage bildet das W3C CSS View Transitions Module Level 2, in dem der Cross-Document-Teil spezifiziert ist (W3C CSS View Transitions Module Level 2).

@view-transition: der Basis-Übergang ohne JavaScript

Der Einstieg ist bewusst minimal. Sie setzen die At-Rule @view-transition mit navigation: auto in das CSS beider beteiligten Seiten. Sobald ein Nutzer zwischen zwei gleichnamigen Seiten derselben Origin navigiert, erzeugt der Browser automatisch einen weichen Cross-Fade zwischen alter und neuer Seite. navigation: auto erlaubt View Transitions für same-origin-Navigationen der Typen traverse, push und replace - ausgenommen sind Reloads und das direkte Ansteuern über die Adressleiste (MDN Web Docs).

/* Auf JEDER teilnehmenden Seite - Quell- UND Zielseite */
@view-transition {
  navigation: auto;
}

view-transition-name: das Produktbild morphen

Der eigentliche Aha-Effekt entsteht, wenn ein Element über den Seitenwechsel hinweg an seinen neuen Platz gleitet, statt einfach aus- und wieder einzublenden. Das ist der klassische Kategorie-zu-Produkt-Fall: Das kleine Produktbild in der Liste wächst beim Klick flüssig zum großen Hero-Bild auf der Detailseite. Dafür geben Sie demselben logischen Element auf beiden Seiten den gleichen view-transition-name. Der Browser erkennt: Das ist dasselbe Objekt, und animiert Position, Größe und Form automatisch zwischen den beiden Zuständen.

/* Kategorie-Seite: das aktive Produktbild benennen */
.product-card.is-active .product-card__image {
  view-transition-name: product-hero;
}

/* Produktdetailseite: dasselbe Bild, gleicher Name */
.pdp__gallery-main {
  view-transition-name: product-hero;
}

/* Dauer und Kurve der Alt/Neu-Snapshots feinjustieren */
::view-transition-old(product-hero),
::view-transition-new(product-hero) {
  animation-duration: 0.35s;
  animation-timing-function: cubic-bezier(0.2, 0, 0, 1);
}

Wichtig ist, dass ein view-transition-namepro Seite eindeutig sein muss. Tauchen auf einer Kategorieseite acht Produktkarten auf, darf nicht jede denselben Namen tragen - sonst bricht der Browser die Transition ab. Praktisch vergibt man den geteilten Namen daher nur dem angeklickten Produkt, typischerweise per Klick-Handler oder dynamisch im pageswap-Event. Für die Bildqualität gilt derselbe Grundsatz wie bei jeder Produktdarstellung: sauber dimensionierte, moderne Formate. Wie Sie Produktbilder performant ausliefern, zeigt unser Leitfaden zu adaptivem Image-Loading mit AVIF.

• Eindeutigkeit: Jeder view-transition-name darf pro Snapshot nur einmal vorkommen - sonst wird die Transition übersprungen.
• Nur das aktive Element benennen: Auf Listen den geteilten Namen ausschließlich der angeklickten Karte geben, nicht allen.
• Feste Abmessungen:width/height bzw. aspect-ratio setzen, damit das Bild während des Morphs nicht springt.
• Snapshots gestalten: Über ::view-transition-old() und ::view-transition-new() lassen sich Dauer, Kurve und Überblendung feinjustieren.
• Gruppen nutzen: Mit ::view-transition-group() steuern Sie die Bewegung des morphenden Paars als Einheit.

pageswap und pagereveal: Übergänge dynamisch steuern

Für statische Cross-Fades reicht CSS. Sobald Sie den Übergang aber richtungsabhängig machen wollen - Vorwärts-Navigation anders animieren als den Zurück-Button - brauchen Sie zwei Events. Das Event pageswap feuert auf der Seite, die verlassen wird, kurz bevor ihr letztes Bild gerendert ist. Hier können Sie view-transition-name-Werte anpassen oder Zustand in sessionStorage sichern. Das Gegenstück pagereveal feuert auf der neuen Seite, nachdem sie initialisiert, aber bevor sie zum ersten Mal gerendert wurde (MDN Web Docs). Über navigation.activation bzw. event.activation lesen Sie aus, woher der Nutzer kam, und wählen die passende Animationsrichtung.

// Muss als parser-blockierendes Script im <head> stehen,
// damit der Listener vor der ersten Renderchance greift.
window.addEventListener('pagereveal', (event) => {
  if (!event.viewTransition) return;

  const from = navigation.activation.from?.url ?? '';
  const cameFromCategory = from.includes('/kategorie/');
  const onProductPage = location.pathname.includes('/produkt/');

  if (cameFromCategory && onProductPage) {
    event.viewTransition.types.add('zoom-in');
  }
});

// Auf der Quellseite: Zustand vor dem Verlassen sichern
window.addEventListener('pageswap', (event) => {
  if (!event.viewTransition) return;
  sessionStorage.setItem('lastProduct', activeProductId);
});

Speculation Rules: gefühlt sofortige Seitenwechsel

Ein weicher Übergang wirkt nur dann rund, wenn die Zielseite auch wirklich schnell da ist. Genau hier setzt die Speculation Rules API an: Sie sagt dem Browser per JSON-Regel, welche Seiten er im Voraus laden (Prefetch) oder sogar komplett im Hintergrund rendern (Prerender) soll. Kombiniert mit View Transitions entsteht der Eindruck eines nahezu sofortigen Wechsels - der Browser hat die Produktseite schon fertig gerendert, wenn der Nutzer klickt, und blendet nur noch weich um.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/produkt/*" },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": { "selector_matches": ".product-card a" },
      "eagerness": "conservative"
    }
  ]
}
</script>

Die Speculation Rules API läuft in Chromium-Browsern (Chrome, Edge, Opera) und erreicht rund 75 % der Nutzer; Firefox und Safari unterstützen sie bisher nicht (caniuse.com). Seit Januar 2026 richtet sich das Vorladen auf Mobilgeräten nach einfachen Viewport-Heuristiken - eine Regel greift dort etwa 50 Millisekunden, nachdem ein Link in den sichtbaren Bereich scrollt (Chrome for Developers). Weil auch Speculation Rules Progressive Enhancement sind, schadet ihr Einsatz nicht - Browser ohne Unterstützung ignorieren den Block. Für die nötige Server-Geschwindigkeit lohnt sich der Blick auf Edge-Caching und ein performantes Hosting-Setup.

Barrierearm umsetzen: prefers-reduced-motion respektieren

Bewegung ist nicht für alle Nutzer angenehm. Menschen mit vestibulären Störungen können auf große Zoom- oder Slide-Animationen mit Schwindel oder Übelkeit reagieren. Deshalb signalisieren Betriebssysteme über die Einstellung reduzierte Bewegung diesen Wunsch an die Seite - abfragbar per Media Query prefers-reduced-motion: reduce (MDN Web Docs). Ein barrierearmer Shop schaltet in diesem Fall die animierten Snapshots ab und liefert stattdessen einen ruhigen, sofortigen Wechsel. Der Inhalt bleibt identisch, nur die Bewegung entfällt.

/* Nutzer, die reduzierte Bewegung wuenschen, bekommen einen
   ruhigen, sofortigen Wechsel statt animierter Snapshots */
@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;
  }
}

Bewegung ist ein Feature, kein Selbstzweck. Wer prefers-reduced-motion respektiert, liefert allen Nutzern den passenden Übergang - vom weichen Morph bis zum ruhigen, sofortigen Wechsel.

XICTRON Entwicklungsteam

Typische Stolperfallen im Shop

In der Umsetzung tauchen immer wieder dieselben Fehler auf. Wer sie kennt, spart sich viel Debugging - denn eine gescheiterte Transition äußert sich meist als hartes Umspringen ohne jede Fehlermeldung.

• Doppelte Namen: Derselbe view-transition-name mehrfach auf einer Seite lässt die Transition kommentarlos ausfallen - nur das aktive Element benennen.
• Flackerndes Hero-Bild: Wird das Produktbild auf der Zielseite neu geladen, statt aus dem Cache zu kommen, blitzt es während des Morphs. Preload und moderne Formate helfen (siehe Bild-Loading-Guide).
• pagereveal zu spät registriert: Nicht parser-blockierend im <head> platziert, verpasst der Listener die erste Renderchance (Chrome for Developers).
• Cross-Origin-Navigation: Zwischen verschiedenen Origins gibt es keine Cross-Document-Transition - der Effekt greift nur same-origin.
• Vier-Sekunden-Timeout: Langsame Seiten überspringen die Transition automatisch - schnelles Rendering und Prerendering sind Pflicht.
• Layout-Shift zwischen Snapshots: Ohne feste width/height springt das morphende Element und verschlechtert nebenbei die Core Web Vitals.
• prefers-reduced-motion ignoriert: Wer die Einstellung nicht auswertet, schließt Nutzer aus und riskiert einen Barriere-Verstoß.

Conversion-Wirkung: warum sich flüssige Wechsel lohnen

Übergänge sind nicht nur Kosmetik. Sie senken die wahrgenommene Wartezeit und halten den visuellen Kontext über den Seitenwechsel hinweg - der Nutzer verliert das Produkt nicht aus den Augen. Und die reine Ladegeschwindigkeit, an der View Transitions in Kombination mit Prerendering direkt mitarbeiten, ist ein belegter Umsatzhebel: Laut der von Google beauftragten Deloitte-Studie Milliseconds Make Millions steigert schon eine um 0,1 Sekunden schnellere Ladezeit die Conversion im Handel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 %; bei Reise-Anbietern lag das Conversion-Plus bei 10 % (Google/Deloitte). Umgekehrt gilt: Steigt die Ladezeit von einer auf drei Sekunden, erhöht sich die Absprungwahrscheinlichkeit um 32 % (Google/SOASTA).

View Transitions im Shop einführen

1. Phase 1 - Kandidaten finden (Woche 1): Die wichtigsten Navigationspfade identifizieren - typischerweise Kategorie zu Produkt und Produkt zurück zur Liste. Diese Wechsel haben die größte Wirkung.
2. Phase 2 - Basis-Übergang (Woche 1-2):@view-transition { navigation: auto; } auf allen relevanten Seiten setzen und den Standard-Cross-Fade testen. Ohne JavaScript, als reines Progressive Enhancement.
3. Phase 3 - Morphing (Woche 2-3):view-transition-name für das geteilte Produktbild vergeben, eindeutig pro Seite. Dauer und Kurve über die Pseudo-Elemente feinjustieren. Feste Bildabmessungen sicherstellen.
4. Phase 4 - Richtung und Feinschliff (Woche 3): Mit pageswap/pagereveal richtungsabhängige Animationen bauen. prefers-reduced-motion auswerten. Timeout- und Cross-Origin-Fälle absichern.
5. Phase 5 - Speculation Rules (Woche 4): Prefetch/Prerender für wahrscheinliche nächste Seiten einrichten, damit der Wechsel gefühlt sofort passiert. Serverseitig auf schnelle Antwortzeiten achten (siehe Brotli-Komprimierung).
6. Phase 6 - Messen und iterieren (laufend): Core Web Vitals im Blick behalten, echte Nutzerdaten auswerten und die Übergänge nur dort einsetzen, wo sie die Orientierung verbessern. Bei Fragen zur Umsetzung hilft unser Entwicklungsteam weiter.