View Transitions Made Our Client Sites Feel Expensive

There is a category of engineering work whose entire job is to make a site feel expensive. Not faster in a way a metric captures, not more functional, just smoother in the way that makes a visitor unconsciously trust the brand. For the past few months, the highest-return item in that category has been the View Transitions API.

If you have not played with it yet: the browser snapshots the old page, snapshots the new one, and animates between them. Elements that persist across pages, a product image, a heading, a nav bar, can morph continuously from their old position to their new one. It is the effect that used to require a client-side router, a state management strategy, and a prayer. Now it is a CSS opt-in.

The part that feels like cheating

For same-origin multi-page apps, Chrome now supports cross-document view transitions behind a single CSS rule:

@view-transition {
  navigation: auto;
}

.product-hero {
  view-transition-name: product-hero;
}

That is genuinely most of it. Give the persisting element a view-transition-name on both pages, and the browser morphs it across the navigation. A product card flowing into a product detail hero, with zero JavaScript and no hydration cost, is the kind of thing we used to budget two weeks for. We now budget two days, and most of that is design review of the motion itself.

Everything is customizable from there with regular CSS animations targeting the transition pseudo-elements, so our motion team can tune easing and duration to the brand instead of accepting a default crossfade.

Progressive enhancement or nothing

The support story is the obvious catch. Cross-document transitions are Chromium-only right now, with Safari signaling interest and Firefox further out. This is exactly the kind of feature that tempts teams into either of two mistakes: waiting for universal support, or shipping a JavaScript polyfill heavy enough to defeat the purpose.

We do neither. The API is perfectly designed for progressive enhancement, because a browser that does not understand it simply navigates normally. No broken states, no fallback code. Chrome users get the expensive feel today, everyone else gets the same fast site they had yesterday, and the feature turns itself on in other browsers as they ship it. We wrapped the JavaScript API variant in one guard for the few places we trigger transitions manually:

if (!document.startViewTransition) {
  updateDOM();
} else {
  document.startViewTransition(() => updateDOM());
}

Motion needs a design owner

A warning from experience: the moment engineers get a free animation API, sites start wobbling like a 2011 keynote. Every transition we ship goes through Nadia's motion team with the same rigor as any brand animation. The rules we converged on: durations under 350 ms for navigations, one hero element morph per transition, and reduced-motion preferences respected without exception. The prefers-reduced-motion media query disables the whole show for users who ask, and that is not optional.

Why this matters beyond polish

The strategic point is bigger than one API. For years, the argument for shipping a heavy single-page app to a content site was "it feels better." View transitions, along with modern prefetching via the Speculation Rules API, remove most of that argument. We can ship plain, fast, cacheable multi-page sites that feel like native apps, and our performance budgets barely notice.

The web platform is quietly having a great year. We intend to keep taking the free wins.