CSS Page Transitions with Hidden Cost of Smooth - View Transitions API Masterclass

Added: 2026-05-05

[00:00:00]Hey everyone and welcome. Today we're diving into something I'm really excited about. The view transitions API. You know, it's one of those new web features that promises to make our sites feel unbelievably smooth. But as with most things, that smoothness can come with a hidden [music] cost. So, we're going to dig into what that cost is and more importantly, how you [music] can master it. So, let me just start with this question. What if your website could actually feel as smooth as a native app?

[00:00:27]Seriously, think about [music] it. No more of those jarring white screen flashes between pages. No more abrupt, confusing jumps. Just seamless, [music] fluid transitions. That right there is the big promise behind the view transitions API. And you can really see the difference here. On the left, you've got that classic web navigation. You click a link and bam, everything disappears and reappears. It's kind of jarring and users can totally lose their place. But on the right, with view transitions, it's fluid. It's contextual. It's all about bridging that gap, helping users see where they came from and where they're going. [music] It just makes so much more sense to the human brain. And the beautiful part, getting this on a multi-page site takes exactly one line of CSS. That's it. One rule on the page you're leaving, same rule on the page you're arriving at, [music] and the browser does the rest.

[00:01:18]No library, no build step, no JavaScript, [music] just this. Okay, but how does this magic actually work? Let's pop the hood for a second and take a quick look at what the browser is doing behind the scenes. So, here's the secret sauce. The view transitions API is built right into the browser. And what it does is pretty clever. It takes a before snapshot of your page and then an after [music] snapshot. Then the browser itself does all the heavy lifting to animate smoothly from one to the other.

[00:01:46]And the best part, it takes very little code from you and me. The whole process is actually pretty straightforward.

[00:01:52]First up, the browser grabs that screenshot of the old view. Then, while everything's kind of paused, it updates the web page DOM to its new state. And finally, it takes a snapshot of that new view and animates between the [music] two. Simple, right? But so, so powerful.

[00:02:09]Now, here's what this actually looks like in code. [music] For a single page app, you wrap your DOM update inside start view transition. The callback is where your state change lives. [music] router push inner HTML swap whatever you use for a multi-page site it's even simpler drop this at view-transition block into your CSS both pages [music] need it and the browser handles the entire animation for you now you can use this in two main ways for what we call single page apps or spas you kick it off with a little bit of JavaScript but for your more traditional multi-page websites it's even easier you just need a single line of CSS on both the starting page and the destination page page. [music] Yep, that's it. No JavaScript needed for the basic fade effect. It's pretty amazing. All right, I know what you're thinking. This all sounds fantastic. Maybe a little too fantastic. So, here comes the reality check. We've got to talk about the performance cost that a lot of people are overlooking. Which of course leads us to the million-doll question. [music] Is this incredible user experience actually free? Come on. As developers, we know there's almost always a trade-off hiding somewhere. And here it is. Real world data from AB tests shows there's an average penalty of about 70 milliseconds on your largest contentful [music] paint, your LCP for mobile navigations. Now, I know 70 milliseconds might not sound [music] like a ton, but when you are fighting for every single millisecond to get your LCP under that 2.5 second goal for core web vitals, 70 milliseconds is a pretty big hit, [music] especially on mobile. Before you ship view transitions on any page, run this in dev tools or [music] add it to your page temporarily. This is a performance observer watching for LCP entries. It logs your LCP value in milliseconds. If that number is already sitting above 2,00, stop right there.

[00:03:58]Fix your performance first, then add the transitions on top. Now, check this out because this is where it gets really telling. Look at how CPU speed affects things. [music] On a fast machine with no throttling, the difference is tiny.

[00:04:11]just 5 milliseconds. But as we start simulating slower CPUs, [music] you know, like the ones in many everyday mobile devices, that LCP penalty just climbs and climbs. At a 20 time slowdown, it jumps all the way to 77 milliseconds. [music] This is a huge deal. You can reproduce this yourself in Chrome. [music] Open the performance panel, hit the gear icon, and set CPU throttling to six times. That's roughly a mid-range Android. But even better than testing it manually, you [music] use a media query to just opt users in first. This targets only screens wider than 1,024 pixels. Mobile users see no transition, no penalty. Desktop users get the full experience. Ship it, measure, then expand. So, let's just sum up what we're seeing here. First, view transitions consistently make your LCP slower. Second, the speed of the devices CPU is a massive factor. And third, all of this is felt the most on the very mobile devices your users are probably on right now. Okay, so we've identified the problem. But don't worry, now we get to the fun part. Let's open up the strategic playbook and figure out how we can get the best of both worlds. That buttery smooth feel without killing our performance. [music] But first, let's just cover the ground rules for those cross- page transitions.

[00:05:29]There are three things that are absolutely mandatory. One, both pages have to be on the same origin. Two, both pages have to opt in with that CSS rule we talked about. [music] And three, the user has to actually initiate it, like by clicking a link. It's not going to work if they just type a new URL in the address bar. All right, here we go.

[00:05:49][music] This is your five-point action plan for doing this the smart way.

[00:05:53]Number one, and this is the [music] big one. We'll come back to it. Use the speculation rules API to pre-render pages. Two, and this is non-negotiable, always respect user motion preferences.

[00:06:04]Three, if I were your consultant, I'd say you should seriously consider targeting only desktop devices at first.

[00:06:10]Four, check your LCP budget. If you're already slow, this will not help. And five, for those cool custom animations, use unique view transition name properties. Let's just double click on that accessibility point because it is so important. You should always wrap your transition rules inside this media query. It respects users who've set their devices to prefer reduced motion, which is crucial for people with vestibular disorders. [music] And that brings us to the most powerful trick in the entire playbook. The absolute best way to use view transitions without that LCP hit is to combine them with the speculation rules API. See, when the browser pre-renders the next page in the background, the transition is just happening between two pages that are already rendered. And [music] the result, no measurable delay. It's the perfect solution. Let's walk through this. The href_matches pattern tells the browser which pages to pre-render. The /star means all pages on the same origin. And eagerness controls when it fires. Moderate means the browser pre-renders when the user hovers a link, which is usually the sweet spot.

[00:07:16]Eager pre-rennders everything visible on the page immediately, which is powerful, [music] but uses more memory.

[00:07:23]Conservative waits until the user actually starts [music] clicking. Safer, but less benefit. So, before we wrap this up, I want to leave you with one more prolevel tip for your troubleshooting toolkit. [music] For those times when things just aren't looking quite right, let me introduce you to your new best friend, the Chrome Animations panel. [music] It's this awesome feature hidden away in DevTools that lets you inspect, control, and most importantly, slow down your animations.

[00:07:50]Honestly, it is a complete gamecher when you're trying to figure out what's going on in a transition that just happens [music] way too fast. And it's so easy to use. Just pop open Dev Tools, search for the animations panel, and crank the speedway down to, say, 25% or even 10%.

[00:08:06]Then just trigger your navigation and watch. You'll see every single step of the animation play out in glorious slow motion, making it a thousand times easier to spot where things are going wrong. One more thing that saves you a lot of pain during debugging. Override the transition duration to something really long, say 3 seconds. Add this to your CSS temporarily. It targets the root view transition pseudo element and stretches the animation out. Combined with the animations panel at 10% speed, you can basically pause and read every single frame. just remember to remove it before [music] you ship. So, we started this whole conversation with a question, aesthetics or speed. But what I hope you've seen [music] today is that with the right strategy, you don't actually have to choose. You can have both by being smart about how and when you [music] use Vue transitions. You can build those beautiful native like experiences without giving up on performance. So, I guess the only real question left is what incredible seamless experience are you going to build next?

[00:09:11]Hey,