In May, Core Web Vitals will become part of Google’s algorithms. They measure your website’s loading, interactivity and visual stability — site speed factors that matter to search engines. So now is the time for websites to tackle the Page Experience Update.
Surprisingly for Google, in addition to the timing of the change, they’ve provided the exact metrics you need to measure and improve. They include Largest Contentful Paint (LCP), First Input Delay (FID) and Cumulative Layout Shift (CLS). Let’s look at each of them.
Largest Contentful Paint
How long it takes for the largest item on the screen to load.
- Good: < 2.5 seconds
- Needs Improvement: 2.5 – 4 seconds
- Poor: > 4 seconds
First Input Delay
How long it takes for the site to respond when a user clicks on something.
- Good: < 100 milliseconds
- Needs Improvement: 100 – 300 milliseconds
- Poor: > 300 milliseconds
For purposes of testing, a similar metric is “Total Blocking Time (TBT).” First Input Delay requires field data, but when it’s not available, Total Blocking Time can use lab data.
Cumulative Layout Shift
Whether a page jumps around as the user scrolls through.
- Good: < .1
- Needs Improvement: .1 – .25
- Poor: > .25
Your site audit should focus on areas ranked as “poor” for the biggest gains, then move on to those that “need improvement.” Here’s one way to approach that audit. You’ll need three things to begin:
- Your website’s domain.
- A PageSpeed Insights API key (from the Google PageSpeed Insights documentation page).
- A paid version of the Screaming Frog website crawler.
(Note: You get around 25,000 PageSpeed Insights queries per day. That’s plenty for smaller sites. For larger sites, you’ll have to extrapolate the data from those queries across the remainder of your site.)
In Screaming Frog, navigate to Configuration > API Access > PageSpeed Insights. Paste your PageSpeed Insights API key into the “Secret Key” box and click “Connect.” Once connected, click “Metrics,” choose “All Metric Groups” and click “OK.” This gives you access to the following metrics groups:
- Overview – General information such as page size and potential load savings for each.
- CrUX Metrics – Chrome User Experience Report data from real, opted-in users.
- Lighthouse Metrics – Lab data including LCP, TBT and CLS scores.
- Opportunities – Suggestions for page-by-page speed improvements.
- Diagnostics – Additional information about the overall performance of the site.
Start Crawling the Site
Paste the domain of your site into the box at the top of the crawler that says “Enter URL to spider.” Wait for the “Crawl” and “API” progress bars in the top right-hand corner to reach 100% before you start looking at your data.
Assess the Size of the Problem
To see what percentage of pages fail each Core Web Vitals minimum, in the top navigation bar, select “PageSpeed” and then “Export.” In your exported data, find these columns and filter as noted:
- Largest Contentful Paint Time (milliseconds) – Filter for LCP > 4000ms.
- Total Blocking Time (milliseconds) – Filter for TBT > 300ms.
- Cumulative Layout Shift – Filter for CLS > 0.25.
Add this data to a separate datasheet so you can easily see which pages fail each Core Web Vital and detect any patterns (for example, only blog pages).
This is where the PageSpeed Insights API goes to work. On the right-hand side, in the “Overview” tab, scroll down to “PageSpeed” for a list of issues and recommendations for page speed and Core Web Vitals. Click on an issue to see the pages affected, and export them into your datasheet to see how many and which pages are affected by that issue.
For each recommendation, look at the “Savings” that could be gained by fixing that particular issue, either in bytes or milliseconds. Add up the potential savings for each issue, and the average savings that could be made per page by fixing it, to see which issues offer the biggest potential load savings. Make these your highest priority.
Looking at the issues specific to a page offers more granular data so you can quickly see what the issue is and whether it can be fixed.
Take render-blocking resources, for example. Select one of the URLs affected by this issue, and select the “PageSpeed Details” tab in the bottom navigation bar. The bottom left panel shows page speed information for that page. Select Opportunities > Eliminate Render Blocking Resources. The bottom-right panel will list the URLs of render-blocking resources on that page, their size (in bytes) and the potential page load savings that could be made (in milliseconds) if they’re eliminated.
Look for any patterns. The same resources will often appear on multiple pages or even on every page on the site, so solutions can be applied sitewide. Gather the data for every issue on the site, and use it to deal with each issue in priority order. Once all changes have been made, crawl the site again and compare, but remember that some issues will take time to resolve.
Sites that meet or exceed Core Web Vitals minimum thresholds are likely to see an improvement in rankings, as Google notes they will “prioritize pages with the best information overall…” Meeting the minimums gives your site a measurable advantage in terms of search visibility. But you need to start now.