By Mehdi HassanPage transitions are one of the first things people point to on award-winning sites, and one of the last things buyers care about on yours. Our view is opinionated: for most startup marketing sites, skip them. There are good exceptions, and the browser now offers a far cheaper way to do them, so this piece covers both. It sits inside our website animation guide.
Are page transitions worth adding to a marketing website?
Page transitions are worth adding to a marketing website only when the transition itself carries meaning; otherwise they're cost without return. A visitor clicking from the homepage to pricing wants the pricing page, now. A fade-out, a wipe and a fade-in add a moment of waiting to every click, and the novelty wears off by the second page.
The exception is continuity. When an element on one page becomes the main element on the next, like a portfolio card growing into a full case study, or a product thumbnail becoming the product hero, the transition tells the visitor where they are and how they got there. That's information, not decoration.
Transition type | Carries meaning? | Our take |
|---|---|---|
Crossfade between all pages | Rarely | Usually skip; it mostly slows clicks |
Full-screen wipe or curtain | No | Skip unless the brand is built on motion |
Card expanding into detail page | Yes | Worth it for portfolios and case studies |
Persistent header or player across pages | Yes | Worth it when content keeps playing |
Tab or filter state transitions on one page | Yes | Worth it, and cheap with the right tools |
What do page transitions actually cost?
Page transitions cost build complexity, navigation speed and maintenance, and the costs are easy to underestimate. Traditional custom transitions on a multi-page site need a client-side router that intercepts every link, manages exit and enter states, restores scroll positions and keeps analytics page views accurate. Every one of those is a source of bugs.
- Speed: exit animations make every navigation wait, and full-page transitions can delay rendering the next page's content.
- Complexity: scroll restoration, back-button behavior, focus management and analytics all need handling.
- Fragility: third-party scripts, embeds and forms often break when pages swap without a full load.
- Maintenance: every new template has to work with the transition system, which slows down editing later.
Those costs land after launch, which is why they're often missed. A marketing team adding a new landing page shouldn't need a developer to make it compatible with the transition layer. If you're deciding between a single page, a microsite and a full site, the transition question is also part of that scope decision, as we discuss in landing page vs microsite vs website.
What is the View Transitions API?
The View Transitions API is a browser feature that animates between two states of a page, or between two pages, by snapshotting the old view and animating to the new one. For same-page changes, you call a function that wraps the DOM update. For navigations between pages of a multi-page site, a short CSS opt-in tells the browser to transition on navigation, with no client-side router.
The browser handles the hard parts: capturing the before and after states, crossfading by default, and letting you name elements so they morph from one position to another. You style the animation with CSS, and browsers that don't support it just navigate instantly, which is a perfectly good fallback. MDN's View Transition API reference documents the current syntax and support.
Pros
- Native, so far less JavaScript than custom transition systems
- Works on multi-page sites without a client-side router
- Shared-element morphs with a CSS name on each element
- Graceful fallback: unsupported browsers navigate instantly
Cons
- Cross-document support still varies by browser; check current support
- Complex choreography is harder than in a dedicated library
- Needs care with reduced motion and focus
- Framework integrations are still maturing
How do page transitions work in Next.js?
In Next.js, page transitions can use the View Transitions API, a library like Motion around route changes, or nothing at all, and the lightest option is usually the right one. Because Next.js already does client-side navigation, transitions are technically simpler than on a static multi-page site. React and Next.js have been adding first-class view transition support, so check the current Next.js documentation for what's stable in your version.
Libraries can animate exits and entrances around route changes, but exit animations in the App Router are fiddly, and they delay navigation. Our preference is the View Transitions API for shared-element continuity and no global page transition otherwise. The choice of library for in-page motion is a separate question, covered in GSAP vs Motion vs CSS.
For example, suppose a studio site wants case study cards to expand
For example, suppose a portfolio grid links to case study pages, and the design calls for each card's image to grow into the case study's hero. With the View Transitions API, the card image on the grid and the hero image on the case study page share a view-transition-name. On navigation, the browser snapshots both and morphs the image from its grid position to its hero position, while the rest of the page crossfades.
In browsers without support, the visitor simply lands on the case study page instantly. Under prefers-reduced-motion, CSS turns the transition animation off. There's no router to maintain, and adding a new case study needs nothing beyond giving its hero image the matching name.
Do page transitions affect SEO, accessibility or analytics?
Done badly, page transitions can hurt all three; done with native navigation and real URLs, they don't. The rule is that every page must still be a real URL with server-rendered content, so search engines and AI crawlers see the same page as a visitor arriving directly. Transitions should only affect visitors clicking between pages.
- SEO: keep real links and server-rendered content. Content that only appears after a client-side transition is a risk, especially for answer engines. See answer-first page structure.
- Accessibility: move focus to the new page's main heading or content after navigation, announce the page change, and turn animation off under reduced motion. Our guide to WCAG, ADA and the EAA covers the wider obligations.
- Analytics: client-side transitions need page views fired on route change, or your traffic numbers drop.
When are page transitions the right call?
Page transitions are the right call for portfolios, product galleries and brand-led sites where continuity between pages is part of the story. They also make sense for persistent elements, such as an audio player or a product configurator that should survive navigation. Developer-focused sites are usually the opposite: technical buyers value speed and predictability, as we see in devtools landing pages.
If a page transition is on your list because a reference site had one, ask the one-sentence question: what does this transition tell the visitor? If the answer is 'that we're a premium brand', put the effort into the micro-interactions and the hero animation instead, where it actually affects understanding.
