View transitions: page changes without the flash of white
How view transitions let a static multi-page site change pages smoothly without becoming a single-page application.
The short answer
When you click a link on a traditional website, the browser unloads the page and loads the next one, and for a moment the screen is blank or white. Single-page applications avoid that by loading one page and swapping content with JavaScript, at the cost of a large script, their own routing, and constant care to stay accessible and indexable. View transitions offer a third way. The site remains a set of separate pages served as static files, and the browser animates the change between them: a header that stays in place while the content below changes, a card image that grows into its position on the detail page, a brief cross-fade instead of a flash. The pages stay fast, simple and indexable, the browser does the animating with little or no script, and older browsers get an ordinary page change. We use it for continuity, keep it subtle, and switch it off for visitors who have asked for reduced motion.
Three ways to change page
| Approach | How it works | Cost | Result |
|---|---|---|---|
| Traditional navigation | Unload, load, render the next page | None | A brief blank between pages |
| Single-page application | One page; JavaScript swaps content and manages routing | Large script; complexity; accessibility and indexing work | Smooth, but heavy and fragile |
| Multi-page site with view transitions | Separate pages; the browser animates between them | Small or no script; a few styling rules | Smooth, light, simple, indexable |
How we apply it
- Build the site as separate static pages, fully working without any transition.
- Enable transitions at the site level, so every navigation gets a brief cross-fade instead of a blank.
- Name the persistent elements, header and navigation, so they stay in place.
- Name the leading elements where it helps: a card image and its detail counterpart, an article title and its heading.
- Keep durations short, in the low hundreds of milliseconds.
- Respect reduced motion: transitions become instant for visitors who have asked for less.
- Test in a browser that supports transitions and one that does not; both must feel correct.
Why this matters for the architecture
For years the argument for building business websites as applications was smoothness: no flashes, continuous navigation. View transitions remove that argument. A static multi-page site can now feel as continuous as an application while staying a fraction of the weight, indexable by default, resilient when JavaScript fails and simple to maintain. It is one of the reasons the modern static approach is the right default for business sites, not a compromise.
What this means for you
View transitions give a normal multi-page website the continuity people associated with applications, without the weight, complexity or fragility. Pages stay static and fast, the browser does the animating, older browsers fall back gracefully, and visitors who have asked for less motion get instant changes. Used subtly, it is the difference between a site that flashes between pages and one that simply flows.
Frequently asked questions
Is this the same as a single-page application?
No, and that is the point. A single-page application loads one page and then swaps content with JavaScript, which requires a large script, its own routing and a lot of care to keep accessible and indexable. View transitions keep the site as separate pages served as files, and simply animate the change between them. The site stays simple; the navigation feels continuous.
Does it work in every browser?
It works in the browsers that support it and falls back to an ordinary page change in the ones that do not, so nothing breaks. Support has broadened across major browsers, and because the fallback is a normal navigation, there is no cost to visitors on older ones. The site is built as a multi-page site first; the transitions are an enhancement.
What should transition and what should not?
Elements that persist across pages, such as the header and navigation, should stay put. An element that leads to the next page, such as a product image or an article card, can move into its place on the new page, which tells the visitor where they went. Everything else should simply fade briefly or change instantly. Large, elaborate transitions on every navigation slow the experience and annoy, and all of it respects reduced motion.
Sources
- MDN Web Docs: View Transition API (accessed 2026-09-12)