Core Web Vitals

Google describes Core Web Vitals as a set of metrics that measure real-world user experience for loading performance, interactivity and visual stability, and says it highly recommends that site owners achieve good Core Web Vitals for success with Search^[1]. web.dev, which sets out Google’s Web Vitals initiative, calls them the subset of Web Vitals that apply to all web pages and should be measured by all site owners^[2].

The thresholds are worded a little differently by each source, so quote the one you cite. Google Search Central asks sites to strive for Largest Contentful Paint to occur within the first 2.5 seconds of the page starting to load, an Interaction to Next Paint of less than 200 milliseconds and a Cumulative Layout Shift score of less than 0.1^[1]. web.dev writes that pages should have an INP of 200 milliseconds or less and a CLS of 0.1 or less, with LCP within 2.5 seconds, and adds that a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop^[2]. Search Console’s report writes its Good range as 2.5s or less for LCP, 200ms or less for INP and 0.1 or less for CLS^[3].

The set has changed. web.dev announced that Interaction to Next Paint would replace First Input Delay as a Core Web Vital on 12 March 2024, and that First Input Delay would be deprecated^[4]. A guide or report that still lists First Input Delay is out of date.

What the metrics do for ranking is stated with care. Google says Core Web Vitals are used by its ranking systems, that there is no single “page experience signal”, and that good results in a report don’t guarantee that pages will rank at the top, because there is more to a great page experience than the scores. It adds that Google Search always seeks to show the most relevant content, even if the page experience is sub-par^[5]. Treat the vitals as part of a good experience, not as a lever.

Be clear about the base of any share you quote. Search Console’s report covers only indexed URLs, shows a sample of pages, groups similar URLs and leaves out a group without enough data^[3], so “most URLs pass” is a statement about the URLs the report holds. QueryRev’s study states its base beside every figure in the same way: it read the robots.txt of 6,294 of the 9,973 domains of its panel, 63.1%^[6]. That study measures robots.txt rules, not page speed.

The metrics are measured in the field, from real visits, and the number to read is the 75th percentile of page loads: the value that 75 in 100 visits met or beat. Search Console’s report is built from the Chrome UX Report, covers the last 28 days, and gives each URL group the status of its most poorly performing metric^[3].

PageSpeed Insights and Lighthouse can run a live test of one URL, which is useful for finding a cause. Search Console warns that the figures of a single URL in PageSpeed Insights might not match its group in the Core Web Vitals report, because an individual URL can be an outlier in its group^[3].

Record for each group of similar pages, by device, the three values at the 75th percentile, the status and the number of URLs, with the date. A group that moves to Poor affects every page in it at once, so follow groups and not single addresses.

Illustrative: an invented site, to show the method.

A coffee-equipment shop’s product pages form one URL group on mobile. At the 75th percentile their Largest Contentful Paint is 3.1 seconds, their Interaction to Next Paint 180 milliseconds and their Cumulative Layout Shift 0.02. Against Search Console’s ranges, INP and CLS are good and LCP is in the middle band, Need improvement.

The group’s status follows its weakest metric, so LCP alone sets it. The shop does not touch the two metrics that already pass. It finds the largest element on its product pages, a hero image loaded late, fixes the template, and waits for the 28-day window to roll before it reads the status again.