You can test and measure the Core Web Vitals with all of Google’s tools for web developers, from PageSpeed Insights to the Chrome DevTools, the CrUX Report, and much more.
As you can see in the image below, Google’s tools measure all the three metrics — except for Chrome DevTools and Lighthouse.
These two tools use the Total Blocking Time as a proxy for the First Input Delay. That’s because FID can only be measured with real user data (Field Data), whereas Lighthouse only provides Lab Data.
If you prefer using another performance tool, you should know that both GTmetrix and WebPageTest have started to use the Lighthouse performance score.
Keep in mind that both tools only provide you with the Largest Contentful Paint and the Cumulative Layout Shift scores.
The reason is always the same: the First Input Delay can only be measured with real user interaction, and these tools rely on the Lighthouse Lab Data.
Let’s now go over two of the most popular tools: PageSpeed Insights and Search Console. The first one helps you detect individual page issues; the other allows you to diagnose sitewide problems.
How to Test and Measure the Core Web Vitals with PageSpeed Insights
The easiest way to test your site’s pages against Core Web Vitals is via Google PageSpeed Insights.
Google’s tool provides data on all three metrics and gives specific recommendations to improve their performance.
The Diagnostics section will become your best ally to get a better score!
Just plug in your site’s URL, and you’ll see Core Web Vitals metrics in both the Field Data (based on the CrUX report) and the Lab Data (based on Lighthouse 6.0).
The Core Web Vitals metrics are marked with a blue ribbon – as long as you get it, you meet the threshold required by Google.
You should keep in mind some notes:
- The Core Web Vitals scores can slightly differ between the Field and Lab Data. In the screenshot above, LCP is 1.8 s according to the Field Data and 2.2 s in the Lab Data. That’s normal, and it depends on how data is collected.
- Not having any Field Data when running your test is not an issue. It’s because there’s not enough real user data available. It doesn’t impact your Core Web Vitals because PageSpeed Insights considers the Lab Data for the page speed score.If you’re wondering what happens with the First Input Delay, not included in the Lab Data, you’ll get your answer in a few lines!
- Always check both the mobile and desktop results. Your Core Web Vitals metrics will differ between the two. Keep in mind that the mobile score is the most relevant and the most challenging.
Let’s now look at how you can use PageSpeed Insights to identify the Core Web Vitals elements that need improvement.
Discovering the Largest Contentful Paint Element with PageSpeed Insights
As we explained, the LCP score measures how long it takes for the most meaningful element to become visible to your visitors.
To discover your site’s Largest Contentful Paint element, scroll down to the Diagnostics section and expand the Largest Contentful Paint element tab.
There, Google will display the HTML for the element that it’s using to measure LCP.
For example, on the desktop version of the WordPress.org homepage, the LCP element is an image:
However, on the mobile version of the site, the LCP element is the subheading text:
Discovering the Cumulative Layout Shift Elements with PageSpeed Insights
Quick recap: the Cumulative Layout Shift deals with how your site loads and whether or not your content “moves around” as new content is loaded.
To find the individual elements on your site that are “shifting” and affecting your score, go to the Avoid large layout shifts section in the Diagnostics area:
Discovering First Input Delay and Total Blocking Time with PageSpeed Insights
First Input Delay is about user interaction, remember? Meaning, how long it takes for the page to respond after interacting with an element such as a link or a button.
That’s why FID is based on actual user data, and you won’t find its score in the Lab Data. As we explained, you’ll only see FID times in the Field Data section — and only if the CrUX report has collected enough data.
In the Field Data, Total Blocking Time (TBT) will replace First Input Delay.
As long as you improve your Total Blocking Time, you’ll likely improve the FID score.
If you have a bad TBT score, you should go to the Minimize third-party usage section in the Diagnostics section.
Here, you’ll see what you can minimize in terms of third-party usage. It’s one of the main performance issues you need to solve – unless it’s already solved and included under the “Passed audits” sections, as you can see below:
How to Read the Core Web Vitals Report on Search Console
If you want to diagnose issues with your site as a whole, you should use the Core Web Vitals report in Google Search Console.
The report is based on an aggregate of real users’ data from CrUX. For this reason, the data included in the report could take a while before reporting issues. That’s why the Lab Data from Lighthouse is always valuable.
That said, the Core Web Vitals report is great to identify the groups of pages that require attention – both for desktop and mobile.
Once you open the report, you’ll find a Details tab that groups the URL performance by several criteria:
- Status (Poor or Need improvement)
- Metric type (e.g., CLS issue: more than 0.25 (desktop))
- URL group (the list of URLs with similar performance).
Once you have fixed the URLs that needed an improvement, you’ll also be able to click on the Validation column and move forward with the “Validate Fix” option. Keep in mind that the validation process takes up to two weeks — be patient!
How to Measure Core Web Vitals with Chrome Extensions
If you’re looking for a useful Chrome Extension, you could choose Web Vitals.
It gives you the Core Web Vital scores for any page you’re browsing:
You may also want to try CORE Serp Vitals, which shows you the Core Web Vitals results directly on the SERP. Remember that you need to enter a Chrome UX Report API key to let the extension work.
