View Transitions API: Seamless Page Changes for Shops

Classic online shops are almost always multi-page applications: every click on a product loads a brand-new HTML page. That hard jump - a white flash, a jumping layout - makes many shops feel sluggish next to single-page apps. The View Transitions API changes that fundamentally: since Chrome 126 (June 2024) and Safari 18.2 (December 2024) the major engines support cross-document transitions that reach around 83 % of users worldwide (caniuse.com). Even simple category-to-product changes now get smooth, app-like animations - without a JavaScript framework and without a rewrite. This practical guide shows how to implement @view-transition, view-transition-name, the pageswap/pagereveal events and speculation rules cleanly, performantly and accessibly in your shop front-end - suited to Shopware shops with an eye on Core Web Vitals.

Why smooth page changes are possible now

Until 2024, smooth transitions between two real HTML pages were barely feasible - you needed a single-page framework that rebuilt navigation entirely in JavaScript. That is exactly why "app feel" was long seen as an expensive SPA feature. Cross-document view transitions flip that: the browser takes a snapshot of the old page before navigation, loads the new page normally and then automatically cross-fades between the two snapshots. Old and new page remain two separate documents - the transition is pure presentation. The only requirement is that both pages are same-origin and both opt in (MDN Web Docs).

Browser support 2026: from experiment to standard

The tipping point came in late 2024: Chrome and Edge ship cross-document transitions since version 126 (June 2024), and Safari followed with 18.2 in December 2024 (Chrome for Developers). For the first time all major rendering engines support the same opt-in syntax. According to caniuse, global coverage for cross-document transitions is around 83 %, and for same-document transitions even 88 % (caniuse.com). Firefox only shows the feature partially so far - it currently ignores the @view-transition block, while navigation still works perfectly normally (caniuse.com).

In practice this means view transitions are a classic progressive-enhancement feature. You build the transition for the roughly 83 % who will see it - everyone else gets the familiar, functionally identical page change (caniuse.com). There is no reason to wait until "all" browsers catch up, because the risk of a regression is close to zero. That property is exactly what makes the feature so attractive for production shops that depend on good Core Web Vitals. The formal basis is the W3C CSS View Transitions Module Level 2, which specifies the cross-document part (W3C CSS View Transitions Module Level 2).

@view-transition: the base transition without JavaScript

The entry point is deliberately minimal. You set the at-rule @view-transition with navigation: auto in the CSS of both participating pages. As soon as a user navigates between two opted-in pages of the same origin, the browser automatically creates a smooth cross-fade between old and new page. navigation: auto permits view transitions for same-origin navigations of type traverse, push and replace - excluding reloads and address-bar navigation (MDN Web Docs).

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

view-transition-name: morphing the product image

The real aha moment happens when an element glides to its new position across the page change instead of simply fading out and back in. That is the classic category-to-product case: the small product image in the listing smoothly grows into the large hero image on the detail page. To do that you give the same logical element the same view-transition-name on both pages. The browser recognizes it as the same object and automatically animates position, size and shape between the two states.

/* 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);
}

It is important that a view-transition-name is unique per page. If eight product cards appear on a category page, they must not all carry the same name - otherwise the browser aborts the transition. In practice you therefore assign the shared name only to the clicked product, typically via a click handler or dynamically in the pageswap event. The same principle applies to image quality as for any product display: cleanly sized, modern formats. How to serve product images performantly is covered in our guide on adaptive image loading with AVIF.

• Uniqueness: Each view-transition-name may appear only once per snapshot - otherwise the transition is skipped.
• Name only the active element: In listings, give the shared name only to the clicked card, not to all of them.
• Fixed dimensions: Set width/height or aspect-ratio so the image does not jump during the morph.
• Style the snapshots: Fine-tune duration, curve and blending via ::view-transition-old() and ::view-transition-new().
• Use groups: With ::view-transition-group() you control the movement of the morphing pair as a unit.

pageswap and pagereveal: steering transitions dynamically

Static cross-fades need only CSS. But as soon as you want the transition to be direction-aware - animating forward navigation differently from the back button - you need two events. The pageswap event fires on the page being left, just before its final frame is rendered. Here you can adjust view-transition-name values or store state in sessionStorage. Its counterpart pagereveal fires on the new page after it is initialized but before it is first rendered (MDN Web Docs). Via navigation.activation or event.activation you read where the user came from and pick the matching animation direction.

// 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: near-instant page changes

A smooth transition only feels right if the destination page is genuinely there fast. This is where the Speculation Rules API comes in: it tells the browser, via a JSON rule, which pages to load ahead of time (prefetch) or even render fully in the background (prerender). Combined with view transitions this creates the impression of a near-instant change - the browser has already rendered the product page when the user clicks and only needs to cross-fade.

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

The Speculation Rules API runs in Chromium browsers (Chrome, Edge, Opera) and reaches around 75 % of users; Firefox and Safari do not support it yet (caniuse.com). Since January 2026 prefetching on mobile follows simple viewport heuristics - a rule triggers roughly 50 milliseconds after a link scrolls into view (Chrome for Developers). Because speculation rules are progressive enhancement too, using them does no harm - browsers without support ignore the block. For the necessary server speed, look at edge caching and a performant hosting setup.

Accessible implementation: respect prefers-reduced-motion

Motion is not pleasant for everyone. People with vestibular disorders can react to large zoom or slide animations with dizziness or nausea. That is why operating systems signal a preference for reduced motion to the page - queryable via the media query prefers-reduced-motion: reduce (MDN Web Docs). An accessible shop then turns off the animated snapshots and delivers a calm, instant change instead. The content stays identical, only the motion is dropped.

/* 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;
  }
}

Motion is a feature, not an end in itself. Respecting prefers-reduced-motion delivers the right transition to every user - from a smooth morph to a calm, instant change.

XICTRON development team

Common pitfalls in the shop

The same mistakes come up again and again in implementation. Knowing them saves a lot of debugging - because a failed transition usually shows up as a hard jump with no error message at all.

• Duplicate names: The same view-transition-name used multiple times on a page makes the transition fail silently - name only the active element.
• Flickering hero image: If the product image on the destination page is reloaded instead of coming from cache, it flashes during the morph. Preload and modern formats help (see our image loading guide).
• pagereveal registered too late: Not placed parser-blocking in the <head>, the listener misses the first rendering opportunity (Chrome for Developers).
• Cross-origin navigation: There is no cross-document transition between different origins - the effect only applies same-origin.
• Four-second timeout: Slow pages skip the transition automatically - fast rendering and prerendering are mandatory.
• Layout shift between snapshots: Without fixed width/height the morphing element jumps and degrades Core Web Vitals along the way.
• prefers-reduced-motion ignored: Not evaluating the setting excludes users and risks an accessibility violation.

Conversion impact: why smooth changes pay off

Transitions are not just cosmetics. They lower the perceived wait and keep the visual context across the page change - the user does not lose sight of the product. And raw load speed, which view transitions in combination with prerendering directly support, is a proven revenue lever: according to the Google-commissioned Deloitte study Milliseconds Make Millions, a load time just 0.1 seconds faster raises retail conversion by 8.4 % and average order value by 9.2 %; for travel providers the conversion uplift was 10 % (Google/Deloitte). Conversely, when load time rises from one to three seconds, bounce probability increases by 32 % (Google/SOASTA).

Introducing view transitions in your shop

1. Phase 1 - Find candidates (week 1): Identify the most important navigation paths - typically category to product and product back to the listing. These changes have the biggest impact.
2. Phase 2 - Base transition (week 1-2): Add @view-transition { navigation: auto; } to all relevant pages and test the default cross-fade. No JavaScript, pure progressive enhancement.
3. Phase 3 - Morphing (week 2-3): Assign view-transition-name for the shared product image, unique per page. Fine-tune duration and curve via the pseudo-elements. Ensure fixed image dimensions.
4. Phase 4 - Direction and polish (week 3): Build direction-aware animations with pageswap/pagereveal. Evaluate prefers-reduced-motion. Harden timeout and cross-origin cases.
5. Phase 5 - Speculation rules (week 4): Set up prefetch/prerender for likely next pages so the change feels instant. Ensure fast server response times (see Brotli compression).
6. Phase 6 - Measure and iterate (ongoing): Keep an eye on Core Web Vitals, evaluate real user data and use transitions only where they improve orientation. For questions on implementation, our development team is happy to help.