The View Transitions API is now available cross-browser. Safari 18.4 shipped support earlier this year, joining Chrome and Edge where the API has been stable since 2023. Firefox shipped support last month. The API is finally a serious option for production marketing sites without polyfills or fallbacks.
We have shipped View Transitions on twelve client projects in the last six months. Across those projects the pattern is consistent: a marketing site with View Transitions feels faster, even when the underlying load metrics are identical. The trade-offs are real, but for the right project the gain is meaningful.
What the API does
View Transitions API gives the browser a way to animate between two states of the DOM. The most common use is between two pages — a click on a link transitions visually from the source page to the destination page, rather than the standard ‘page disappears, white flash, new page appears’ default.
The single-page version (within an SPA) lets you transition between views of the same application. The multi-page version (cross-document) lets you transition between actual page navigations, which is the version that matters most for marketing sites.
The API is declarative. CSS controls the transitions. JavaScript hooks let you customize the timing, the elements involved, and the animation curves. The browser handles the choreography.
Why the perceived performance shifts
The objective load time of a page is not faster with View Transitions. The bytes are the same. The render is the same. What changes is the user’s experience of the transition.
A standard browser navigation has three discrete states: source page, blank, destination page. The blank state is short but jarring. The brain registers it as ‘something stopped, then something started.’
With View Transitions, the navigation animates continuously from source to destination. Elements that exist on both pages — typically the header, the navigation, sometimes a featured image — animate smoothly between their old and new positions. Elements that are new fade in. Elements that are leaving fade out. The brain registers it as ‘one thing turned into another.’
The objective LCP timer might be identical. The user’s experience of speed is different.
The cases where it goes wrong
Three failure modes we have hit on client projects:
1. The destination is slow. View Transitions need the destination page to be rendered quickly enough that the transition does not stall. If the destination has a 4-second LCP, the transition starts, the new content is not ready, and the user sees a half-finished animation that freezes mid-way. The perceived performance becomes worse, not better.
The fix is to make the destination fast first, then add View Transitions. The API is a polish layer, not a performance fix.
2. Over-animation. Some marketing sites we audited had been given View Transitions with custom morphing animations on every element. Hero images morphing into card thumbnails. Navigation animating across multiple paths. Every transition was a four-second cinematic sequence.
This is the equivalent of every page transition being a TED talk. Users do not want a TED talk between every page. The transitions should be fast enough that they feel like a continuous interface, not a slideshow.
Our default is 300 to 400 milliseconds for the full transition. Anything longer than 500 milliseconds is too long for a marketing site.
3. Element identity mismatches. The transition matches elements by view-transition-name. If two elements have the same name and you do not expect a transition between them, weird things happen. Two unrelated images can suddenly animate from one position to another because they share a name.
The fix is careful name scoping. We use page-specific or component-specific naming conventions to avoid accidental matches.
Where it works well
Three patterns that consistently improve the perceived performance:
Persistent navigation. The header, nav bar, and footer remain in place across page navigations rather than re-rendering. The result is that the site feels like an application — the chrome persists, only the content changes. This is the highest-impact single transition we ship.
Featured image continuity. On a card-to-detail flow — clicking a blog post card to land on the article page, or clicking a product card to land on the product page — the featured image animates from its card position to its full hero position on the detail page. The user’s eye does not lose track of what they clicked.
Cross-fades between hero sections. On adjacent pages with similar above-the-fold structure — a series of campaign landing pages, or the home page to a service page — a cross-fade transition replaces the flash. The result is smoother than a hard cut.
The implementation cost
On a typical marketing site, adding View Transitions for the patterns above is about 8 to 16 hours of work. Two hours to identify the elements that should be persistent across navigations. Four hours to wire up the view-transition-name properties. Two to four hours of CSS for the animations. Two hours of testing across browsers and edge cases.
That is a small budget for a meaningful UX improvement on a site that gets a lot of internal navigations. For a marketing site where 70 to 80 percent of sessions visit more than one page, the gain is real.
For a site where most sessions are single-page (a paid acquisition landing page, a microsite, a one-page brand site), View Transitions add no value. There are no transitions to animate.
The browser support reality
As of mid-2026, the API works in Chrome, Edge, Safari 18.4+, and Firefox 124+. Older browsers fall back to the standard navigation behavior. The fallback is graceful — the site works, the user just does not get the transition.
For a marketing site, the small percentage of users on older browsers is not a deal-breaker. They get the same experience the site had before View Transitions. The newer-browser users get the upgrade.
The integration with frameworks
Most of our projects use the API directly with vanilla JavaScript and CSS. The frameworks that have first-class integration as of 2026:
- Astro: built-in support via the <ClientRouter /> component. Two lines of configuration to enable.
- Next.js: third-party libraries handle it. Native support is in development but not yet stable.
- Nuxt: native support in 3.x via nuxt-route-announcer integration.
- Plain HTML: the cross-document API works directly. No framework needed.
For a vanilla HTML or Astro marketing site, the implementation is the simplest. For a Next.js app, it requires more wiring but is still tractable. Astro’s built-in support is one of the reasons we have recommended it more often this year.
The verdict
For marketing sites with multi-page navigation, View Transitions are now worth shipping. The implementation cost is small. The perceived UX gain is meaningful. The browser support is good enough. The fallback is graceful.
For single-page applications and one-page marketing sites, the feature does not apply.
For marketing sites that are already slow — LCP above 3 seconds — fix the underlying performance first. View Transitions are not a performance optimization. They are a polish layer that magnifies the perception of a fast site, but they do not make a slow site feel fast. Pair them with the boring performance work that actually matters, and you ship something that feels meaningfully different from the marketing sites of three years ago.