CLS is not reporting often

[delambo]

First: I'd like to thank you all for the time you put into this library!

I have a small issue with how often CLS is reporting:

On a highly trafficked site that I'm working on, we found that CLS is captured very infrequently in our analytics. In fact, only ~31% of pageviews on Chrome report a CLS metric; whereas FID is captured on ~43% (not great either) and LCP is captured on ~80% of page views.

It sounds like the implementation waits for visibility to be hidden before reporting. Is it possible that a lot of page loads are not triggering the hidden event before navigation to a new page? Any other ideas?

[philipwalton]

How are you sending the data to your analytics server. And what analytics tool are you using?

[delambo]

We POST events using a custom tool. This tool has been in production for a long time and we consider it stable. For example, we also send an event for page load time after the onload event is triggered and that reports for ~97% of page views. Some of the missing 3% is probably due to bounces or users leaving pages before the onload event is triggered, and possibly issues with some insignificant browsers/webviews. But I think that's a good example of the stability in our event tracking system.

Do you have some advice for how/when we should be POST'ing the CWV metrics?

[philipwalton]

Are you using navigator.sendBeacon() to send the data? I suspect your tool is stable when trying to send the data while the page is open, but if you try to send the data while the page is unloading, the POST requests aren't being reliably sent.

The navigator.sendBeacon() method (older but well supported), as well as fetch() method with the keepalive flag set (newer, only in Chromium) are both APIs specifically designed to handle this problem. That is, reliably send HTTP requests from a page that's actively being unloaded.

In the case of Web Vitals, since CLS is tracked during the entire page lifecycle, it invokes its callbacks in the visibilitychange event, which can happen either when a user changes tabs or when a user closes a tab or navigates away.

[delambo]

Thanks for the help @philipwalton! It appears that our tracking library is using sendBeacon. We also found that mobile is reporting a lot less than desktop. I'll close this out and work with our tracking team to see if we can't improve upon sending events when the page is exiting.

One last question for you and anyone else that's listening, which might help us better understand what we should work toward: In your experience using other analytics libraries, do you know the percentage of page views that CLS and FID typically report on?

[philipwalton]

I wouldn't necessarily expect the number of pageviews to always line up exactly with the number of CLS beacons received. Here are a few things that could account for the difference.

• If your site is an SPA, you'll probably have pageviews for URLs that aren't page loads (same thing for bfcache restores). If you're tracking page loads, specifically, then yes the numbers should be closer.
• CLS is measured using an API (Layout Instability) that's fairly new and at this point is only supported in Chromium-based browsers (e.g. Chrome, Edge, Samsung Internet, Opera, etc.), so you'd only want to compare page loads from just those browsers and filter by just the more recent versions.
• The end of a page lifecycle isn't always observable, e.g. the user go on airplane mode or otherwise not have network when they close a page.
• The visibilitychange event (while the best we currently have) isn't 100% guaranteed to fire in all cases, and of course there are browser bugs (see discussion here).

As for what results you can expect to see in the real world? I can only speak for myself. I use this library to measure Web Vitals on my personal website and here's how my numbers break down, when comparing the counts for each metric to the number of recorded page loads:

• CLS: 82%
• LCP: 69%
• FID: 35%

Note that I would expect CLS to be recorded at higher rates than LCP and FID since both of those metrics will not report for pages loaded in the background. CLS, though, in theory should always have a value, and I agree that an 18% miss rate (what I see on my site) is less than ideal.

[delambo]

Thank you, that's very helpful. It looks like our FID and LCP mostly match, so I'm not too concerned there. I'll look deeper into how our analytics tool is forwarding CLS.

[delambo]

A follow-up for the folks that may uncover this later. We did manage to improve how our analytics is sending beacons when the page is unloading and we're seeing much better reporting for CLS. Here's our current reporting numbers for page views which seem fairly in line with Philip's:

FID: 39%
CLS: 93%
LCP: 79%

Thanks again, Philip.