The 202406 dataset is live

[Barry Pollard]

Hi CrUX users,

This is your monthly announcement that the latest dataset has been published to BigQuery.

The 202406 (June 2024) dataset is now available and it covers 18,442,199 origins, a decrease of 1.2% over last month. Here's a look at origins' Core Web Vitals performance this month:

• 63.4% of origins (↑ 2.0%) had good LCP

• 77.8% of origins (↑ 0.5%) had good CLS

• 84.1% of origins (↑ 1.1%) had good INP

• 51.0% of origins (↑ 2.3%) had good LCP, CLS and INP

This month we saw a good increase in Core Web Vitals pass rates across all metrics—a reverse of the slight regression we saw last month. If you’ve followed us carefully you’ll be aware that some of the shifts may be seasonal, for example, in July 2023 we also saw a decrease in the number of origins, and an increase in pass rates for the Core Web Vitals.

The Chrome team has been continuing work on improving efficiencies in Chrome’s handling of the Core Web Vitals metrics and recently launched some changes to INP which may have contributed to the positive trend this month. The most notable change is to better handle use of the basic modal dialogs (alert, confirm, print). While technically these are synchronous and block the main thread—and so are not recommended if there are alternatives—they do present user feedback for an interaction. They were previously not counted as presentation feedback for INP, which could result in very high INP values for sites that did use these. From Chrome 127 the presentation of the modal will mark the end measurement time for INP and so should lead to improved INP times for those sites.

As previously mentioned, we’re planning to remove the Effective Connection Type (ECT) dimension from CrUX in September 2024. With this release, we’re including a preview of the new round_trip_time (RTT) metric in the CrUX API, which measures network latency. It is defined as the HTTP round trip time estimate for a page load, at the time the navigation was initiated. The RTT metric in CrUX comes from the rtt property of the Network Information API, which is the same API responsible for the ECT dimension but at a more granular level. By specification, ECT should use both RTT and downlink to categorize the ECT, but Chrome currently only uses RTT.

The following example query fetches the 75th percentile (p75) desktop RTT for web.dev (you’ll need to get your own API key to try this):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY"   --header 'Content-Type: application/json' --data '{"origin": "https://web.dev", "formFactor": "DESKTOP", "metrics": ["round_trip_time"]}'

For now only the p75 of the metric is available, but the differences between typical desktop and phone connections are already easily visible. At the moment, we’re seeing 230ms for PHONE and 116ms for DESKTOP for the aforementioned example, a significant difference even though both would be considered “4G” connections according to the Effective Connection Type classification. We’re hoping that this type of field data can help to understand performance issues, and are looking to surface more RTT data in the various CrUX datasets in future. We’re also looking forward to learning from you—please let us know if you find something interesting!

And finally, as a reminder, FID is deprecated and will be removed from Chrome tools in September 2024. Make sure you update any CrUX API applications to switch over to INP by then.

Cheers,

Barry