How to check your Core Web Vitals

What Core Web Vitals measure

Why Google points to Core Web Vitals

What you need to check Core Web Vitals

• A web browser
• The addresses of three or four important pages, such as the home page, an article and a product or service page
• Access to Google Search Console with the site added as a property
• A note-taking app or paper for the results

Check your Core Web Vitals, step by step

1. 1

   Choose your pages

   Pick pages that represent your main page types. Pages built from the same template usually behave alike, so one of each type is a good start.

   You will know it worked when You have three or four full addresses, one for each main page type.

2. 2

   Run each page through PageSpeed Insights

   Enter the address into PageSpeed Insights. It reports on both mobile and desktop and gives real-user data and lab data for the page. See the PageSpeed Insights documentation.

   You will know it worked when You can see a report for each page, with mobile and desktop views.

3. 3

   Read the real-user results first

   Real-user data comes from the Chrome User Experience Report over the previous 28 days. If a page has too few visits, the tool falls back to figures for the whole site, and sometimes shows none.

   You will know it worked when For each page you know whether the numbers are for the page, for the whole site, or missing.

4. 4

   Compare each metric with its target

   Google’s targets are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1, measured at the 75th percentile. A page passes only if all three are met. See web.dev’s explanation of Web Vitals.

   You will know it worked when For each page you have noted whether each of the three metrics meets its target.

5. 5

   Use the lab results to find causes

   Lab data comes from a controlled test and is useful for debugging, but may not capture real-world bottlenecks. Use its diagnostics as a list of things to ask a developer about, and treat the real-user numbers as the judge.

   You will know it worked when You have a short list of diagnostics for any page that failed a target.

6. 6

   Open the Core Web Vitals report in Search Console

   The report groups similar pages and shows each group’s status, based on its worst metric, for mobile and desktop. Only indexed pages appear, and it is a sample. A new property may show no data for a few days. See the Core Web Vitals report help.

   You will know it worked when You can name which page groups are Poor or Need improvement, and for which metric.

7. 7

   Recheck after changes, but not straight away

   Real-user data covers the previous 28 days, so an improvement takes time to appear in the reports. Note the date you made a change and look again after a few weeks.

   You will know it worked when You have a dated note of what changed and when to look again.

Common mistakes when you read Core Web Vitals

• Judging by the lab score alone. Google says lab data may not capture real-world bottlenecks.
• Chasing a perfect score. Google says that purely for SEO reasons it may not be the best use of time.
• Expecting good results to guarantee a top position. Google says they do not.
• Reading an empty report on a new site as a fault. A new property may need a few days for data to appear.

Terms used when you check Core Web Vitals

Core Web Vitals

Three measures of real-world page experience: loading (LCP), responsiveness (INP) and visual stability (CLS).

Field data

Measurements from real visitors’ experiences of a page, collected by Chrome over a period of time.

Lab data

Measurements from a controlled test of a page, useful for finding causes but not the same as real visitors’ experience.

Interaction to Next Paint (INP)

A Core Web Vitals measure of how quickly a page responds when someone interacts with it.