How to check whether a performance fix has reached Core Web Vitals

What Core Web Vitals reporting shows

Why the report moves slowly after a fix

What you need to follow a performance fix

• The date and a description of the change that was released
• The addresses of two or three pages the change affects
• Access to the Core Web Vitals report in Google Search Console
• A way to run PageSpeed Insights or Lighthouse on those pages

Check a performance fix in Core Web Vitals, step by step

1. 1

   Write down what was released and when

   Record the release date and what the change was meant to improve: loading speed of the main content, responsiveness, or layout shift. Note whether it reached every page or only some templates. Everything else in this guide depends on those dates.

   You will know it worked when You have a release date, an intended improvement and a list of the page types affected.

2. 2

   Confirm the change with a lab test

   Run PageSpeed Insights on your example pages. Google's report help says the test shows both live test data and data from real users, and that the figures can differ from the Search Console report. Use the live test to see whether the page itself behaves as intended now.

   You will know it worked when A live test on each example page shows the improvement you expected, or you have a note on why it does not.

3. 3

   Find your pages in the report

   Open the Core Web Vitals report and choose mobile or desktop. Google says the report groups similar URLs and gives each group the status of its worst-performing metric. Find the group that contains your example pages and note its status and which metric is causing it.

   You will know it worked when You have written down the group, its status and the metric responsible.

4. 4

   Check whether there is enough data

   Google says a group without enough data for both LCP and CLS is omitted, and that a no data message means a new property or too little data for that device type. If your pages are missing, that is not evidence of a problem. Use the lab test as your evidence.

   You will know it worked when You know whether each group has data, and you are using lab results where it does not.

5. 5

   Wait for the 28-day window before judging

   Google defines the group figures over the last 28 days. Note the date 28 days after the release was complete. Until then, the report mixes days before and after the change, so a small movement is expected, not a failure.

   You will know it worked when Your calendar has a review date 28 days after the whole fix was live.

6. 6

   Start tracking once the fix is everywhere

   When the issue is fixed on all URLs, you can use Start Tracking to begin a 28-day monitoring session. Google says this does not trigger re-indexing or any active behaviour. It restarts a four-week monitoring period, and the issue is fixed only if it appears nowhere in the window.

   You will know it worked when Tracking was started after the fix reached all affected URLs, and the end date is on your calendar.

Common mistakes when you check a performance fix

• Judging a fix after a few days. The report describes the last 28 days.
• Starting tracking before the fix has reached every URL, which lets the issue appear in the window.
• Treating the Search Console report and a PageSpeed Insights test as the same number. Google says they can differ.
• Assuming missing data means a problem. Google says it can mean a new property or too little data.
• Expecting Start Tracking to ask Google to re-crawl. Google says it does not.

Terms used when you check a performance fix

Field data

Measurements collected from real visitors' browsers, as used in the Core Web Vitals report.

Lab test

A test that loads a page once under fixed conditions and reports straight away.

LCP, INP and CLS

Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift: the three Core Web Vitals metrics.

URL group

A set of similar pages that the report treats together and gives one status.