Page transitions that don't annoy on the second visit
View Transitions, route-level fades, and why most slick page animations should be turned off after the first session.
Page transitions are the easiest place to spend animation budget on something that backfires. The first time a user navigates and the page fades, they think smooth. By the tenth navigation, they're tapping their foot waiting for the fade to finish so they can use the new page.
Page transitions should be short, purposeful, and skip-able. Here's the actual ceiling.
Time budget
- Cross-fade between routes: 120–180ms. Past 200ms, users feel it as latency.
- Shared-element transitions: 250–350ms. Slower because they're carrying information, the user is tracking the element across the transition.
- Modal open/close: 150–200ms. A modal feels broken if it teleports in; it feels slow if it takes longer than 250ms.
Use the View Transitions API
Modern browsers ship a native View Transitions API. It's faster, GPU-accelerated, and degrades to instant on browsers that don't support it. There's no reason to ship a JS-based route fade in 2026 unless you need full control.
Shared-element transitions
The thumbnail on the index page becomes the hero on the detail page, smoothly. This is one of the few transitions that genuinely helps users: it conveys this is the same thing, you didn't lose your place.
It's also the easiest to over-use. If everything is a shared-element transition, the user can't tell what's actually persistent. Reserve for the primary card-to-detail flow on your product.
Respect prefers-reduced-motion
If the user has reduced-motion set in their OS, every transition above 100ms should be replaced with an instant change. This is accessibility, not a nice-to-have. The View Transitions API handles this automatically; custom transitions don't.
Build one
The page-transitions entry has the anatomy and tuned prompts. Default to cross-fade; reach for shared elements only on the flows that benefit.
Keep reading