The Impact of CSS View Transitions on Web Performance

The Impact of View Transition API on Performance

The View Transition API allows developers to enable smooth visual transitions between views on the same site, even for multi-page applications (MPAs). These view transitions are handled by CSS transitions between two page views. Historically, CSS transitions during page load cause a delay in the LCP metric. We suspected that these in-between-page view transitions have performance implications as well, particularly on mobile devices and slower CPUs. Our Real User Monitoring (RUM) data confirmed these suspicions, along with other interesting insights into the effect on Core Web Vitals, especially the Largest Contentful Paint (LCP).

Last reviewed by Arjen Karel on February 2026

RUM Data Findings

To validate our idea that view transitions negatively impact the Largest Contentful Paint, we set up a series of A/B tests on 5 different sites and let these run for 7 days. On 50% of the pageviews we added @view-transition { navigation: auto;} to the page's stylesheets while the other 50% of pageviews were served without these styles.

We collected over 500,000 pageviews where eventually 120,000 mobile pageviews were analyzed because they originated from mobile navigations within the same site.

Real-user monitoring data has uncovered that implementing the View Transition API adds approximately 70ms to the Largest Contentful Paint for repeat mobile pageviews. This increase in LCP time is noteworthy, considering Google's recommendation that LCP should occur within 2.5 seconds of when the page first starts loading for a good user experience.

CPU Performance Correlation

Having confirmed the negative impact of view transitions on LCP, we investigated further. We proceeded to set up a series of experiments to automatically test the same 2 pages with and without view transitions. The results show a clear correlation between CPU speed and the impact of view transitions on LCP. The findings indicate that the slower the CPU, the more pronounced the negative effect on LCP when using view transitions.

If you would like to test this for yourself visit our view transition experiment homepage on GitHub.

These results highlight three key observations:

• View transitions slow down the LCP: Page views with view transitions are slower than pageviews without view transition effects.
• CPU speed is an important factor: CPU speed has a high correlation with LCP difference in views with and without page transition effects. This matters especially for low-end mobile devices.
• There is a pagespeed 'sweet spot': At 6x slowdown LCP has better performance without network cache. The simple reason is that at this CPU speed the LCP element has not yet been decoded without network caching and the transition is applied to a blank page. Immediately after the simpler transition to a blank page the LCP element is painted. Apparently this is the sweet spot where it is more efficient to transition to a blank page than to transition between images. From a UX perspective it is better to transition between images of course.

Browser Support

The View Transition API reached Baseline Newly Available status in October 2025. Same-document view transitions now work in Chrome 111+, Edge 111+, Firefox 144+, and Safari 18+, covering roughly 89% of global browser traffic. Cross-document view transitions (the ones triggered by @view-transition { navigation: auto; }) have slightly narrower support but work in all major browsers except older Firefox versions.

This wide support means more developers will adopt view transitions, making the performance implications even more relevant.

Understanding @view-transition { navigation: auto; }

Traditionally, implementing view transitions required extensive use of CSS and JavaScript. The View Transition API simplifies this process by allowing developers to define transitions declaratively. The View Transition API works by capturing snapshots of the old and new states of a document, updating the DOM while suppressing rendering, and using CSS animations to execute the transition.

Implementation Example

Here is a basic example of how to enable cross-document view transitions in your CSS:

@view-transition {
  navigation: auto;
}

Or in combination with a media query to target tablet or desktop devices:

@media (min-width: 768px) {
  @view-transition {
    navigation: auto;
  }
}

This simple addition allows the browser to handle the transition automatically when navigating between pages on the same origin.

Accessibility: prefers-reduced-motion

Users who prefer reduced motion should not be forced through animations. Wrap your view transition rule in a prefers-reduced-motion media query. This also removes the LCP penalty for those users.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

Eliminating the LCP Cost with Speculation Rules

The best way to use view transitions without the LCP penalty is to combine them with the Speculation Rules API. When the browser prerenders the next page before the user clicks, the view transition animates between two already rendered states. The LCP element is already loaded and decoded, so the transition adds no measurable delay. If you care about both aesthetics and performance, this is the combination to use.

Recommendations

The View Transition API offers smooth and visually pleasant transitions between navigations. This can lead to small benefits in business metrics like lower bounce rates and higher engagement. However, especially on low-end mobile devices, developers must carefully consider the performance implications. Here are my recommendations:

• Check your LCP budget first. If your mobile LCP is already above 2.0 seconds, adding 70ms of transition overhead puts you closer to failing. Fix LCP first, add transitions later.
• Combine with Speculation Rules. Prerendering the destination page eliminates the LCP cost of view transitions entirely.
• Use prefers-reduced-motion. Wrapping view transitions in a reduced motion media query respects user preferences and removes the performance cost for users who do not want animations.
• Test with real users. Lab tests do not capture the full range of devices and network conditions your visitors use. Run an A/B test with CoreDash to measure the actual impact on your LCP before and after enabling view transitions.
• Consider desktop only. Our data shows that desktop devices with fast CPUs experience almost no LCP impact (5ms). Restricting view transitions to desktop via a min-width media query is a reasonable compromise.