One of the really cool things about mobile apps are the transitions between pages or views. You tap a button and the next page flies in from the right or fades in or the button animates to give the effect of going into it, etc. This has been missing on websites, there have been some javascript solutions but they are generally not good for performance and especially bad for core web vitals which has become increasingly important in recent years.

All this is about to change with view transitions api. Currently this only works behind a flag in chrome, to enable it simply copy the following lines into the address bar of chrome and enable them:

chrome://flags#view-transition
chrome://flags#view-transition-on-navigation

Then add the following meta tag to the head of your templates:

<meta name="view-transition" content="same-origin" />

Basically that’s it, you will now have a fading page transition.

If you want to transition an element on one page to another element on the next page you simply give each of the elements the same css view-transition-name:

.element-on-page-one {
	view-transition-name: cheesecake;
}
.element-on-page-two {
	view-transition-name: cheesecake;
}

I won’t go much further into the implementation of view transitions, there’s a lot of writing out there already. I found a great writeup over at https://daverupert.com/2023/05/getting-started-view-transitions/, definitely worth a read.

What I was curious about is how view transitions will affect performance and core web vitals therefore I applied view transitions to this site so I can test it. If the flag is turned on, you will see pages fade from one to another. Also on the homepage when you click on a blog post to view it, the title will animate to its position at the top of the blog post page.

Cumulative Layout Shift

Usually if there is any movement in elements during the loading of a page then it is seen as a layout shift and could affect CLS scores. I suspected view transitions would not affect CLS as they are purposeful transitions that could be beneficial to usability, and I was right. There was no impact on CLS at all.

Largest Contentful Paint

This is where things got a little interesting. My test methodology was:

I repeated these steps for:

The tables below show the average of the 5 runs for each scenario.

Mobile text element
No throttling Fast 3G
Without With Without With
FP 188.216 172.074 1.21 1.22
FCP 188.216 172.074 1.21 1.22
LCP 188.216 172.074 1.21 1.22

Not too much interesting in the above table, no throttling with transitions was slightly faster but fast 3G was slightly slower with transitions. With the LCP being a text element it is no surprise that first paint (FP), first contentful paint (FCP) and largest contentful paint (LCP) all have the same timings.

Desktop text element
No throttling Fast 3G
Without With Without With
FP 183.63 226.096 1.222 1.24
FCP 183.63 226.096 1.222 1.24
LCP 183.63 226.096 1.222 1.24

The above table shows that desktop was slower with transitions in both no throttling and fast 3G. This is what I was expecting with both mobile and desktop as the browser has to do slightly more work to setup the transitions.

Mobile image element
No throttling Fast 3G
Without With Without With
FP 214.924 292.668 1.246 1.294
FCP 214.924 292.668 1.246 1.294
LCP 256.132 292.668 3.758 3.776

Image element on mobile shows to be slower with both no throttling and fast 3G with transitions. The interesting thing here is that when the LCP is an image it is expected that it will be slower than FP and FCP which will usually be text elements, but no throttling with transitions, the image LCP was also the FP and FCP. This was the case for all 5 runs.

Desktop image element
No throttling Fast 3G
Without With Without With
FP 187.924 178.136 1.25 1.266
FCP 187.924 178.136 1.25 1.266
LCP 212.414 187.888 3.746 3.752

This time no throttling is slightly faster with transitions but 3G is slightly slower with transitions. One thing to note here is that no throttling with transitions, the LCP is showing as only slightly slower than FP and FCP, the reason for this is that for 4 of the 5 runs, the LCP, FP and FCP were all the same. This is similar to what we saw with mobile where all 5 runs were the same.

It seems like with transitions on and an image element as LCP on a fast network, the LCP is also generally the FP and FCP. Is this a good thing? Not sure really. If the LCP is speeding up to be in line with the FP and FCP then yes, but if the FP and FCP are slowing down to be in line with the LCP then no.

Limitations

There are some limitations to these results. The tests were done on this site which is a very small and fast site so the variations in timings could be just noise.

Also I only did 5 test runs for each scenario which might not be enough.