Clicking a product should feel like turning a page -- yet in many shops a white area flashes up for a fraction of a second between category and product. The browser discards the old page, builds the new one from scratch, and this very hard cut makes even fast pages feel sluggish. For a long time the only answer to this was a JavaScript framework that turns the shop into a single-page application and takes over navigation entirely -- with all the cost in complexity, maintenance and main-thread load. Since 2024 there has been a simpler path: the Cross-Document View Transitions API brings native, browser-rendered page changes to classic multi-page shops, enabled by a single CSS rule and with no JavaScript framework at all (web.dev). This article shows how the View Transitions API works, how same-document and cross-document differ, how shared elements such as the product image morph from one page to the next, and what all of this means for Core Web Vitals and conversion. In our Core Web Vitals optimization we routinely check such techniques for whether they measurably improve perceived speed, rather than just looking good.
Key takeaways
- Cross-document view transitions animate the change between two real HTML documents and bring smooth page changes to classic multi-page shops -- enabled via CSS and without a JavaScript framework (web.dev).
- It is enabled through the at-rule @view-transition with navigation: auto in the stylesheet of the source and destination page, both of which must belong to the same origin (MDN). The formerly common meta-tag variant is considered outdated (Chrome for Developers).
- Shared elements keep their identity via view-transition-name: on click, the product image in the category overview visibly grows into the large image on the product page, without a script calculating the intermediate steps.
- Chrome has shipped cross-document transitions since version 126 in June 2024 (Chrome for Developers), Safari since version 18.2 in December 2024 (MDN). Where support is missing, the browser navigates as usual -- no polyfill, no branch.
- The animation runs on the compositor, barely burdens the main thread and does not count as an unexpected layout shift. The gain lies in perception: a load time faster by 0.1 seconds (Deloitte) lifted the retail conversion rate by 8.4 percent (Deloitte).
Why Page Changes in a Shop Still Jank
A classic multi-page shop loads a completely new HTML document on every click. The browser tears down the existing display, briefly shows the empty background and then repaints the destination page piece by piece -- a visible break perceived as jank or flicker. On fast connections this is barely noticeable; on an average mobile device on a cellular network it is very much so. And speed decides revenue: 53 percent (Google) of mobile users abandon a page that takes longer than three seconds to load, and the probability of a bounce rises by 32 percent (Google) when load time increases from one to three seconds. As many as 47 percent (Akamai) of users expect a page to appear in under two seconds. How closely load time and purchase completion are linked is explored in our article on page speed, conversion rate and revenue.
To avoid the hard switch, many shops moved to single-page architectures in recent years: a JavaScript framework intercepts every click, loads only the data of the destination page and swaps the visible area softly. The result feels fluid but comes at a price. The browser has to load and execute a large script bundle and manage the interface itself while running -- work that lands on the main thread and can endanger responsiveness. Responsibility for history, scroll position and server rendering also shifts from the browser into your own code. Why server-side rendering and the subsequent hydration can themselves become a load brake is covered in our article on server-side rendering and hydration. The View Transitions API reverses this relationship: it gives the smooth transitions back to the browser without abandoning the multi-page architecture.
What the View Transitions API Does
Same-Document and Cross-Document: the Difference
The View Transitions API comes in two flavours. The older same-document variant runs within a single document and is aimed at single-page applications: JavaScript changes the DOM, and the API animates the transition between the old and the new state. Chrome shipped this variant back in March 2023 with Chrome 111 (Chrome for Developers). It is powerful but still requires the application to control navigation itself. How to measure such script-driven changes cleanly at all is shown in our article on soft navigations and Core Web Vitals.
The newer variant, decisive for shops, is cross-document: it animates the transition between two real, separate HTML documents -- exactly the classic navigation from one URL to the next. This gives a multi-page shop the same smooth changes as a single-page application, without a single line of JavaScript being needed (web.dev). The browser recognizes the navigation, briefly holds the old view, loads the new document and fades over smoothly. The only requirement is that both pages belong to the same origin and both opt in to the transition via CSS. It is precisely this variant that resolves the old trade-off in which you had to choose between a simple multi-page architecture and a fluid app-like feel.
| Trait | Same-document (SPA) | Cross-document (MPA) |
|---|---|---|
| Trigger | JavaScript changes the DOM | Navigation between two URLs |
| JavaScript framework | usually required | not needed |
| Activation | startViewTransition() in code | @view-transition via CSS |
| Typical use | app-like interfaces | classic shops and websites |
| Main-thread load | raised by the framework | low, the browser handles it |
How to Enable Native Transitions Without JavaScript
For a classic shop the entry is remarkably brief. Both pages involved -- the source and the destination page -- must opt in to the cross-document transition in their stylesheet. This is done via the CSS at-rule @view-transition with the descriptor navigation: auto. As soon as this rule is present on both pages and both belong to the same origin, the browser fades over smoothly on every navigation -- by default as a gentle cross-fade of the whole page (MDN). The formerly common meta-tag variant is considered outdated; the CSS at-rule is the current path (Chrome for Developers).
/* On the source and destination page, same origin required */
@view-transition {
navigation: auto;
}
/* Adjust the duration of the default transition */
::view-transition-old(root),
::view-transition-new(root) {
animation-duration: 0.25s;
}
/* Shared element: the product image keeps its identity */
.product-image {
view-transition-name: hero-product-image;
}Nothing more is needed for the first smooth transition. Anyone who wants to steer the motion more finely reaches for the pseudo-elements ::view-transition-old and ::view-transition-new and describes duration, timing curve or direction of the animation through them. Because everything runs via CSS, the main thread stays free for what really counts: interactivity. This clean separation between presentation and logic is one of the reasons why native transitions fit well into a lean frontend optimization.
Shared Elements: the Product Image Morphs Along
The most impressive effect comes with shared elements. If an element has the same name on both pages via the CSS property view-transition-name, the browser recognizes it as the same object and moves it smoothly from its old to its new position -- instead of fading it out and fading it back in elsewhere. In the shop this means: the small product image in the category overview visibly grows into the large image on the product page on click. The user keeps the reference because the object visually persists. It is precisely this continuity that lowers the cognitive load and makes the change feel fast and natural -- an effect familiar from native apps that, on the web, previously had to be paid for dearly.
Name the Element
Through view-transition-name an element gets the same identity on both pages. The browser thus knows that thumbnail and large image are the same object and animates the path between them itself.
Morph the Position
The browser interpolates size and location automatically. The product image travels and grows in one motion from the overview to the detail page, without a script calculating the intermediate steps.
Style with CSS
Duration, curve and direction live entirely in the stylesheet. This lets the transition match the character of the brand and be suspended for cautious users via prefers-reduced-motion.
Browser Support in 2026 and Progressive Enhancement
Cross-document view transitions have arrived in most browsers by 2026. Chrome has shipped them since version 126 in June 2024 (Chrome for Developers), and Safari followed with version 18.2 in December 2024 (MDN). Firefox has supported the same-document variant since version 144 in October 2025 and is working on cross-document support (MDN). This means two of the three major browser engines already ship the seamless page changes, with the third to follow. In practice: in modern Chromium and WebKit browsers users see the smooth transition, in older browsers the familiar, instant navigation.
No Risk Thanks to Progressive Enhancement
Effect on Core Web Vitals: CLS and Perceived Speed
A common misconception is that a smooth transition costs performance. The opposite can be the case. Because the browser handles the animation on the compositor, it barely burdens the main thread and runs evenly even on weaker devices instead of janking -- much like any well-implemented, smooth animation without jank. For Cumulative Layout Shift, the metric for visual stability, it is important to know: the motion that runs during a view transition does not count as an unexpected layout shift, as long as it was triggered by the navigation. How to deliberately avoid unwanted shifts, by contrast, is covered in our article on Cumulative Layout Shift in the shop.
The biggest gain lies in perceived speed. Studies show that even minimal accelerations move revenue: a load time faster by 0.1 seconds (Deloitte) increased the retail conversion rate by 8.4 percent (Deloitte) in a broad study. A fluid transition does not shorten the actual load time, but it bridges the brief wait visually and thereby makes the page appear faster and of higher quality. Precisely because only 62 percent (Web Almanac 2025) of mobile websites reach a good Largest Contentful Paint under 2.5 seconds, every perception improvement without technical cost is valuable. On responsiveness, measured as Interaction to Next Paint, native transitions act neutral to positive, because they do not block the main thread further.
The Core in One Sentence
Implementation in the Shop: What Matters in Practice
In practice a few conditions must be observed so the transitions take hold cleanly. Both pages must belong to the same origin -- a switch to a foreign domain triggers no transition. Both documents must opt in to the transition via CSS, otherwise the hard cut remains. Shared elements need the same, unique view-transition-name on both pages; if the same name appears twice at once, the mapping breaks. And rapid click sequences should not have to wait for a long animation: a short duration of about a quarter of a second keeps the transition noticeable but not obstructive. Anyone who wants to speed up navigation further combines the transitions with anticipatory loading via speculation rules for instant navigation.
- Add @view-transition with navigation: auto to the stylesheet of the source and destination page
- Serve both pages under the same origin -- otherwise the transition stays off
- Mark the product image as a shared element with a unique view-transition-name
- Keep duration and curve short and reduce them for prefers-reduced-motion
- Verify in Chrome and Safari as well as in a browser without support
- Measure before and after: responsiveness and layout stability must not degrade
As with any frontend technique the rule is: measure, do not guess. A smooth transition must not degrade responsiveness or introduce layout shifts. On very slow connections or in data-saver mode it can also make sense to reduce the animation -- how pages adapt to weak networks in general is shown in our article on adaptive loading for slow networks. And because elaborate transitions that occupy the main thread can endanger interactivity, it pays to look at how compute-heavy tasks can be moved off the main thread using web workers.
Native page transitions are the rare case in which a shop feels noticeably more refined without a single additional resource being loaded. We introduce them as progressive enhancement and then verify in the field data whether stability and responsiveness remain untouched.
This is exactly how we proceed on a project: we enable the transitions, name the shared elements, keep the animation subtle and then measure the effect in the field. Native view transitions are one building block among many -- they replace neither a fast server response nor a lean frontend but sit on top. Which measures deliver the greatest effect in which order we classify in our overview of performance services, and specifically for shops in Shopware performance. Anyone who wants to understand the three Core Web Vitals in context will find the classification in the article on Core Web Vitals 2026.