Core Web Vitals: Everything You Need To Know About Google’s Newest Ranking Factor

Core Web Vitals are a set of real world website performance metrics that Google considers critical to user experience.

And from May June (Update was postponed) 2021…

…they’ll have a direct influence on search rankings.

Which means if you want more organic search traffic, you’ll need to get your Core Web Vitals in shape.

But don’t sweat. In this guide we’re going to cover EVERYTHING you need to know about Core Web Vitals, including:

• EXACTLY what they are
• How they’ll influence your Google rankings
• How Google measures them
• Where you can see your site’s Core Web Vitals
• How to find and fix common issues with each of the three Core Web Vitals

You can skip to a section using the menu below.

Otherwise, let’s get started by looking at what Core Web Vitals are, and how they’ll impact on your search traffic.

What are Core Web Vitals?

Google wants to reward sites that provide a good experience for their users (UX).

But there’s a problem:

For a search engine like Google, user experience can be tough to measure.

Sure, metrics such as bounce rate and dwell time may give Google hints. But they can also be gamed. And there can be big variations depending on the purpose of an individual page or site.

Enter “Web Vitals”.

A set of metrics and signals that Google can definitively say have a positive (or negative) impact on user experience. And all of which can be detected (or considered) by an algorithm.

Google’s Web Vitals focus on speed, responsiveness (in terms of user interaction), and layout stability.

Why? Because they’re objective:

• A fast website is always going to be better for a user than a slow one.
• A website which responds quickly to user interactions is going to reduce frustration.
• A stable layout will help prevent unintended clicks.

Makes sense right?

And going forward, Web Vitals will have an increasing influence on how Google ranks web pages.

Bottom line:

Improving your site’s user experience will bring you more search traffic.

But…

….not every “Web Vital” is a “Core Web Vital”.

Let me explain.

How Core Web Vitals will combine with other speed and UX factors to influence your Google rankings

This is partly semantics.

But it gets a little confusing. So we’ll keep this as simple as possible.

Core Web Vitals (CWV) are a subset of Web Vitals. Over time Google will add more metrics to CWV. But for now there are three.

Note: These metrics are a little complex to explain in one paragraph. So don’t worry if you’re unfamiliar with the terms — we’ll go into full detail on all three of them shortly.

1. Largest Contentful Paint (LCP)

The time for the largest visible element (i.e. “above the fold”) on a page to fully load. To pass Google’s Core Web Vitals assessment, the Largest Contentful Paint element on a page must be fully loaded within 2.5 seconds.

2. First Input Delay (FID)

The delay between a user taking their first action on a page (i.e. clicking a button, clicking on a search box, opening a menu) and the website responding. To pass Google’s Core Web Vitals assessment, a page must have a First Input Delay under 100 milliseconds.

3. Cumulative Layout Shift (CLS)

A measurement of visual stability. Any elements which shift (move) during load will add to the page’s CLS score. To pass Google’s Core Web Vitals assessment, a page must have a Cumulative Layout Shift score under 0.1.

Other Web Vitals (not classed as “Core”) include:

• Time to First Byte (TTFB)
• First Contentful Paint (FCP)
• Total Blocking Time (TBT)
• Time to Interactive (TTI)

And finally, we have four traditional UX factors:

• Whether a site is mobile friendly
• Whether it runs on HTTPS
• Whether it’s safe to browse
• Absence of intrusive interstitials (annoying popup ads)

Which, while Google doesn’t label them as such, we believe should also be considered as Core Web Vitals.

Because they combine with the three Core Web Vitals to form what Google calls its “Page Experience” signal.

And from June 2021, this Page Experience signal will influence Google rankings.

“Today we’re announcing that the page experience signals in ranking will roll out in June 2021. The new page experience signals combine Core Web Vitals with our existing search signals including mobile-friendliness, safe-browsing, HTTPS-security, and intrusive interstitial guidelines.”

Which means that if you want to rank high in search, you’ll need to pass Core Web Vitals.

We should point out here that the traditional UX signals — mobile friendly, safe browsing, HTTPS, no intrusive interstitials — are already ranking factors.

And it’s likely that they will continue to be individual ranking factors, as well as contributing to a page’s overall “experience” score.

Why optimizing your website’s Core Web Vitals is essential for SEO

Core Web Vitals are going to directly influence rankings.

Pass Google’s Core Web Vitals assessment and your website is likely to rank higher in search.

Fail… and your rankings could drop.

But if you need some more convincing of just how important getting your Core Web Vitals up to scratch is, consider the following:

1. Pages with a good page experience score will be eligible for Google Top Stories on mobile

For many newsworthy searches, Google shows a “Top Stories” section right at the top of the search results.

That’s prime SERP real estate.

At the moment, to be eligible for Google’s “Top Stories” on mobile your site has to use AMP.

But from June 2021 that will no longer be the case.

“Any page that meets the Google News content policies will be eligible and we will prioritize pages with great page experience, whether implemented using AMP or any other web technology, as we rank the results.”

Which means if your website fails core web vitals, you’re missing out on a HUGE traffic opportunity.

2. Pages that pass Core Web Vitals could get a thumbs-up in search results

Want another sign of just how important Core Web Vitals and Page Experience are going to be?

Google may identify pages that pass Core Web Vitals and the other Page Experience criteria directly in the search results.

“Visual indicators on the results are another way to do the same, and we are working on one that identifies pages that have met all of the page experience criteria. We plan to test this soon and if the testing is successful, it will launch in May June (updated) 2021”

In other words:

Pages that pass Core Web Vitals could get a user experience thumbs-up from Google directly in the search results.

Think that will influence click-through rates? You better believe it!

So now you know just how important getting your Core Web Vitals in shape is going to be, let’s look at how Google measures them.

How does Google measure Core Web Vitals?

If you run your site through Google’s PageSpeed Insights tool, you’ll notice that the report is split into two sections:

You’ll get “Lab Data” and “Field Data”.

So what’s the difference?

Well, to quote Google, “Lab data” is…

based on a simulated load of a page on a single device and fixed set of network conditions.

In other words, it’s not based on actual user interaction with your website.

Field data on the other hand is provided by Google’s Chrome User Experience Report. Which is…

powered by real user measurement of key user experience metrics across the public web, aggregated from users who have opted-in to syncing their browsing history, have not set up a Sync passphrase, and have usage statistic reporting enabled.

In a nutshell:

Google collects data from millions of Chrome users all over the world. The data they collect includes the three Core Web Vitals.

So the “field” metrics you see for them are based on actual visits to your site.

Bad news for privacy conspiracy theorists. Good news for website owners, as we get to see how our site is performing in the wild.

Note: we’ll cover more ways to check your website’s Core Web Vitals later in this guide. But first, let’s take an in-depth look at the three Core Web Vitals.

Why you need to optimize all three Core Web Vitals

So now we know where the data comes from, let’s take a closer look at the three Core Web Vitals.

Which to recap, are:

• First Input Delay (FID)
• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)

Many of the factors that affect Largest Contentful Paint also impact First Input Delay. Indeed there is also cross-over with Cumulative Shift.

So while generally LCP would come first in the chain (loading > interactivity > visual stability), we’re going to start by covering First Input Delay. As there’s one major loading issue that will tend to have the most significant impact on FID.

But the key is, all three Core Web Vitals metrics are connected. For example, improving LCP will normally help FID and CLS.

And to pass Google’s overall Core Web Vitals assessment, you’ll need to pass all three individual metrics.

Let’s take a look at the first Core Web Vital.

First Input Delay (FID)

First input delay is a measure of a web page’s responsiveness.

Specifically, it’s a measurement of how long a web page takes to respond to a first “action” from a user.

What counts as an action for FID purposes?

• Clicking (or tapping) a button
• Clicking a link
• Opening a menu
• Clicking on a form field

What doesn’t?

Continuous actions such as scrolling and zooming.

At the top of Seobility’s homepage (on mobile) there are two elements that a user would be likely to click first:

1. A hamburger (mobile) menu
2. A “Sign Up Free” button

They’re both prominent above the fold. And if we’re doing our CRO right, the “Sign Up Free” button should be one of the first elements a user clicks.

So let’s see how our homepage is performing.

There are several places we can see FID (and other Core Web Vitals data). But for now, let’s use Google’s PageSpeed Insights.

We can see that during the past 28 days, our homepage has an average First Input Delay of 17ms.

Is that good or bad?

Well, Google wants to see a FID of less than 100 milliseconds.

“To provide a good user experience, pages should have a FID of less than 100 milliseconds.”

So we’re doing pretty well here.

It’s taking less than one 50th of a second for our website to respond to the user’s first input. Which let’s be honest, for a human, is instant.

Sidenote: if you’re wondering why Google picked 100ms, that’s long been the accepted limit for a user “feeling” a system is reacting instantaneously. Response times below that we just can’t perceive.

What can cause a website to have First Input Delay issues?

A browser reads a web page’s code top to bottom.

And when it gets to an external script (most notably Javascript) it has to:

1. pause loading other elements
2. disable user interaction until it has downloaded and processed that file

Why?

Because that external script could modify the behavior of individual elements on the main page.

Confused? Here’s an example that you’ll recognize.

Many image galleries use Javascript to open a popup lightbox when a user clicks on an individual image.

 

But that lightbox functionality only works once the Javascript file that powers it has been downloaded and processed by the browser.

Before that, when a user clicks they’ll simply be taken to the image URL. The Javascript modifies the behavior of the link element — preventing a click from taking the user to a new page, and opening a lightbox instead.

So by default, when a browser comes across an external JS file, it thinks:

“I’d better check this Javascript doesn’t change the functionality of the page before I proceed. Let’s put everything else on hold!”

This behavior is known as “render-blocking”.

And if you have issues with your site’s FID, it’s likely to be the cause.

How to prevent Javascript from blocking your page

The good news? Preventing Javascript files from blocking your main page is relatively painless.

All you need to do is add one of the following two attributes to your script tags:

1. “Defer”
2. “async”

Which one you add will depend on the type of script you’re calling.

Option 1: Defer loading of a Javascript file

Best for: scripts that alter the functionality of your page, or that need to be loaded in a specific order.

<script src=”yourscript.js” defer></script>

The defer attribute tells the browser not to wait for the script (which would “block” the page), but simply to load it in the background while the rest of the page renders.

Why is the order important?

Scripts with the “defer” attribute execute in the order they appear within a page’s HTML.

Example:

If you have a custom jQuery function you would want to ensure that the main jQuery library is loaded before your custom script:

<script src=”jquery.js” defer></script><script src=”customquery.js” defer></script>

Otherwise… it won’t work!

Option 2: Load a Javascript asynchronously

Best for: external scripts that don’t affect the functionality of your page, and don’t require to be loaded in a specific order.

<script src=”externalscript.js” async></script>

Similar to defer, the scripts will be loaded in the background, allowing the rest of the page to render.

However in this case the scripts will not be executed in a specific order. As soon as a script with the async attribute is loaded, it will run.

Generally it’s safe to load analytics scripts, tracking pixels, and ads asynchronously as they are not dependent on other libraries, nor do they affect the overall functionality of your page.

For more details on async and defer, see this guide.

How to find (and fix) render blocking scripts

Google’s PageSpeed insights will give you a heads up on which scripts are currently blocking your page.

To demonstrate, we created a simple test page which calls three render blocking scripts (one local and two third party).

If we run the page through PageSpeed Insights we can see that the scripts are blocking the main page for 1.1 seconds.

PageSpeed Insights > Opportunities > Eliminate render-blocking resources

Also note the “Time to interactive” of 1.9 seconds (more on that in a moment).

So let’s add the “defer” attribute to the local script, and “async” to the third party scripts.

Here is the new page.

We’ve now eliminated all render-blocking resources…

…and our “Time to interactive” has improved by 1.1 seconds.

Pretty easy right?

But…

Be careful with deferring scripts that impact on UX

Core Web Vitals is all about improving user experience.

Which means:

We don’t want to do anything that could negatively affect a user’s impression of our site.

Remember our big “Sign Up Free” button?

Let’s say a click on that opened a pop-up window, rather than taking the user to a new page.

We know that clicking on that button is one of the first actions a user might take.

So guess what would happen if we deferred the Javascript that made the pop-up work?

A user might click it before the script has loaded. Which could lead to frustration (as nothing would happen).

So what should we do instead?

Prioritize loading of important Javascripts

We should prioritize the loading of that script, even if it’s going to render-block for a few ms.

Why? Because it’s essential to the functionality of the above-the-fold content.

Ideally we’d code the script for the pop-up directly into the page’s HTML. Which would save the browser some time downloading an external Javascript file.

But if that’s not possible, we’d want to store that script in its own file and load it right away.

Long story short:

If a script is essential to the functionality of your above-the-fold content, then be super careful with deferring it.

But any script that’s non essential:

Defer and async are your friends.

Using “Time to interactive” as an indicator of potential FID

First input delay is “field data”, which (to recap) means it’s a real world metric based on actual visitors to your site.

Technically you can test it (we’ll show you how later in this guide). But that test is going to be specific to your own computer/wi-fi connection at a particular moment in time.

So while you’re waiting for new, aggregated data to come in from Google, you can take a look at the “lab” metric “Time to interactive”.

First though, a warning:

Time to interactive is a bit of an odd metric, and one that should be taken with a healthy grain of salt. This blog post by dareboost does a great job of explaining why that’s the case (and what “time to interactive” actually is).

But we’re going to keep things super simple here:

As you cut down on render-blocking scripts, your “Time to interactive” (reported by PageSpeed Insights) should decrease.

Improve render-blocking by a second, and your Time to interactive should improve by roughly the same amount.

And often (although not always) you’ll see a correlation between the following three metrics:

• “First contentful paint” (FCP) when a user starts to see something on your page
• Time to interactive
• The render-blocking time

If we look at the PageSpeed Insights report for Seobility’s homepage, we can see that the “Time to interactive” is roughly the FCP + the render-blocking time.

Bottom line:

Improving your Time to interactive (by eliminating rendering roadblocks) is a good thing. So seeing that time come down as you work on your site is an indicator that you’re going in the right direction, and that your FID should also improve.

But again, just be aware that First input delay and Time to interactive are not the same thing.

Largest Contentful Paint (LCP)

Now let’s look at the second of Google’s three Core Web Vitals: Largest Contentful Paint.

The good news? This metric is a little easier to understand.

Largest Contentful Paint measures how long it takes to fully render the largest above-the-fold element on a user’s screen.

Elements considered for LCP include:

• Images
• Videos
• Containers with background images
• Text elements (paragraphs, headers etc)

And whichever individual element takes up the most real-estate above the fold is the one that counts for LCP.

On our SEO audit guide, the header is the LCP element…

…while on our meta descriptions guide (which has a shorter title), the featured image takes up more browser space.

But don’t worry, there’s no need to get your ruler out.

Unlike FID, Largest contentful paint is measurable both in the field and in the lab.

Run a page through Google’s PageSpeed Insights, and they’ll let you know what the Largest Contentful Paint element is.

PageSpeed Insights > Diagnostics > Largest Contentful Paint element

In terms of measurement, The LCP clock starts when a user types in your URL, and ends when the LCP element is fully loaded.

Let’s see how our meta descriptions post is doing.

Yikes!

A Largest Contentful Paint of 5.7s puts this page firmly in the “Poor” category.

As you can see, Google considers:

1. a LCP of under 2.5 seconds as “good”,
2. a  LCP of 2.5s to 4s as “needs improvement”,
3. a LCP above 4s as “poor”

But before we panic…

You may have noticed that the above metrics were “Lab Data”. And as I already mentioned, LCP is measurable both in the lab, and in the field.

So let’s see what our real world LCP is for this page.

That seems a lot better. But we should point out that less than 3% of this page’s traffic was mobile, so it’s a relatively small sample size.

Either way, we’re going to want to improve the LCP of this page.

How to improve Largest Contentful Paint

So how do we go about improving LCP?

Well, you might have guessed: a big part of it is going to be speeding up our site.

But this is not a page speed guide — we have one of them coming soon. In the meantime you can check out our Page Speed wiki and our SEO audit guide for some pointers.

Instead, we’ll show you how to easily find slow pages with Seobility. Then we’ll look at some specific factors that can impact LCP.

Finding slow pages with Seobility

Seobility’s site audit measures the response time for each page on a website.

We consider:

• a response time under 0.5 seconds to be good,
• a response time between 0.5 seconds and 1 second to need improvement,
• A response time above 1 second to be slow

But ideally, the faster, the better.

To find slow pages on your site you’ll need an Seobility account.

Don’t have one yet? We recommend signing up to a free, 30 day trial of our Premium plan here, which will let you crawl up to 25,000 pages.

Your next step is to add a new project and start a crawl.

Click the “Add project” button on the dashboard, enter your start URL, give the project a title, and hit “Add project and start crawling”.

Seobility > Dashboard > Add project

Seobility bot will get to work crawling your site.

Once it’s done, click on the “Tech & Meta” report under “Onpage” and scroll down to “Distribution of response times”.

Seobility > Dashboard > Onpage > Tech & Meta > Distribution of response times

In the example above we can see that 4 pages on the site are in the “Slow” category. Which means they have a response time above 1 second.

Clicking on the number gives us a list of the slow pages, along with:

1. their response time, and
2. how that response time compares with the average for the site

In this case, these 4 pages are around 3x slower than the average for the site. So we’d definitely want to take a look at them and figure out what’s up.

Two tips for optimizing Largest Contentful Paint

The fact that we know exactly what the LCP element is for each page gives us a bit of an advantage.

Why? Because we can look to optimize the loading of that element and reduce our LCP. Indeed, we could even switch out what the Largest Contentful Paint element is.

For example, if the LCP element is a featured image, we could increase the font size of the header so it becomes the LCP instead.

But beyond ‘tricks’ and ‘hacks’ what we really want to be doing is getting everything above-the-fold to load as quickly as possible.

Here are two tips.

1. Include “Critical Path” CSS directly in the HTML + defer non critical CSS

Like Javascript, CSS is render-blocking by default.

When you link to a CSS file in the standard way (in the <head> section), a browser will need to download and process the CSS before it can start displaying content.

<head>
<link rel="stylesheet" href="yourstylesheet.css">
</head>

That’s going to have an impact on FCP.

Fortunately, there’s an easy fix.

What we want to do is

1. load the styles required for rendering the above the fold content inline, then
2. load the rest of the CSS rules asynchronously (non render-blocking)

The first thing we need to do is determine which CSS rules are required to style the above the fold content.

And the good news is, there’s a tool that will do it for us.

1. Go to https://www.sitelocity.com/critical-path-css-generator
2. Enter the URL you want to generate critical path CSS for
3. Hit “Generate Critical Path CSS”
4. Copy the CSS from box

Paste the critical path CSS into the <head> section of your page’s HTML. That way all the CSS rules required to display above the fold content will be loaded immediately.

Then replace your regular stylesheet call with the following:

<link rel="preload" href="yourstylesheet.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

This will:

1. load non-critical CSS asynchronously,
2. with a fallback (inside <noscript>) for browsers that don’t execute javascript

Note: most good caching plugins will handle all this for you.

For example, if you’re using WP Rocket, then all you need to do is select “Optimize CSS delivery” under “File Optimization”…

…and you’re good to go.

But if you want to read more on how to do it manually, then check out the web.dev guide here.

2. Optimize featured images

On many blog pages, the featured (or hero) image will be the LCP element.

So we want to make sure it loads as quickly as possible.

Here are a few pointers for optimizing images, with links to further reading/tools:

1. Use srcset to serve alternative images based on viewport size (tutorial)
2. Compress images (imagify is recommended for WordPress)
3. Consider serving webp versions of your images (here’s what they are, imagify can handle creating them)
4. Use a CDN to serve your images (web.dev guide)

Cumulative Layout Shift (CLS)

Cumulative Layout Shift is a measurement of the stability of a webpage’s layout. Any time an element on a page moves unexpectedly (i.e. not a movement initiated by the user) it adds to the page’s total CLS score.

Layout shifts can make for an incredibly frustrating user experience.

Take a look at the screen recording below, which shows the homepage of a Scottish newspaper loading over a period of 5 seconds.

 

Notice how the menu jumps around as ads are loaded.

Here are individual frames showing the layout shifting around before we get to the final stable version.

On the final frame an ad occupies the position where the menu was originally located.

So what would happen if a user tried to click on the menu while the layout was still shifting? Yep, they’d probably click on the ad by mistake and be taken away from the page.

We’re sure you can see why layout shifts are bad news for users.

Which is why Google wants you to keep them to an absolute minimum.

The way a page’s CLS score is calculated is a bit complex, and is not really something you need to know. So we’re not going to cover it…

…but it is detailed here if you want to fill in the gaps.

For our purposes though, all we need to know is we want a CLS score below 0.1.

Where can you see your page’s CLS score?

Cumulative Layout Shift is measurable both in the lab and in the field.

So you’ll see it in both places when you run a page through PageSpeed insights.

What causes layout shift? (and how to fix it)

Layout shifts can happen for a number of reasons. We’ll cover some of the most common below.

But the good news is, for your own page, Google will tell you exactly what’s contributing to your CLS score.

Run a page through PageSpeed Insights, and you’ll find a section called “Avoid large layout shifts” under diagnostics.

Here’s what the report says for our homepage.

We can see that the <h1> and <h2> tags are contributing to our homepage’s CLS score.

Fortunately, that’s an easy fix.

1. Ensure text remains visible during webfont load

Lots of websites (including our own) use custom fonts. Google themselves have a fantastic library of fonts that can help make a webpage more visually appealing, and easier to read.

The problem:

These custom fonts need to be downloaded before they can be displayed by a browser.

And until they are:

1. the user won’t see any text
2. the browser doesn’t know exactly how much space text elements are going to take up (which can cause a layout shift when they load)

To minimize this we can take advantage of CSS font-display to swap to a fallback, system font until the custom font has been loaded.

You’ll see this recommended (if you’re not doing it already) under “Diagnostics” in PageSpeed insights.

And if you’re using Google fonts, it’s super easy to implement.

All you need to do is add “&display=swap” to the end of the Google font stylesheet URL.

<link href="https://fonts.googleapis.com/css2?family=Noto+Sans:ital,wgh[email protected],400;0,700;1,400;1,700&display=swap" rel="stylesheet">

In fact, these days Google will automatically add it for you when you grab the embed code from their library.

In our case, adding “display=swap” cut total CLS to 0.004 (from 0.026).

And layout shift on the header elements was pretty much eliminated.

Easy peasy.

2. Reserve space for ads in your layout

Custom fonts will generally cause small layout shifts that will be (in the main) imperceptible to users.

But — as demonstrated by the newspaper site at the start of this section — ads can take a wrecking ball to your layout.

It’s fixable if:

1. you know what sizes your ad network is going to serve, and
2. you’re manually placing them in specific slots

But with Google adsense auto ads all bets are off. After all, the whole point of auto ads is that they’ll test different locations to maximize revenue. Which means you’ve literally no idea where ads will end up on any given pageview! *

For now though, let’s assume that you know which sizes of ads you’ll be displaying, and where they’re going to be.

If that’s the case, all you need to do to prevent ads from shifting your layout is set a minimum height and width for your ad container. The minimums will be based on the ad sizes you’ll be serving.

<div id="ad-slot1" style="min-width: 300px; min-height: 250px;"></div>

You can then use media queries to change the minimum height/width depending on a user’s screen size.

@media screen and (max-width: 960px) {
#ad-slot1 {
min-height: 100px;
}
}

Full instructions on how to do it here.

*if you know of a solution for auto ads then please let us know in the comments!

3. Make sure all image tags include width and height attributes

Most websites will have a responsive layout, where images automatically resize based on the user’s screen size.

Indeed, with the srcset attribute, browsers are able to display images (i.e. a small, medium, large variation) in different sizes to match the display.

However it’s still important to set the width and size attributes of the parent image in the <img> tag.

Why? Because if those attributes are missing, the browser won’t be able to calculate the height to reserve for the image prior to it loading.

Which will cause layout shift when it does.

So always make sure you set size attributes for your images. This is particularly important for above the fold elements (for example a site logo).

How (and where) to check your site’s Core Web Vitals

Throughout this guide, we’ve focused on Google’s PageSpeed Insights, as it has:

1. Been around for a while
2. Most webmasters/SEOs will be familiar with it

But there are plenty of other places you can check Core Web Vitals for a website or page.

So let’s quickly cover them.

1. Google Search Console

First up, Google now reports issues with your site’s Core Web Vitals in Google Search Console (GSC).

You’ll find the report by clicking on “Core Web Vitals” under “Enhancements” on the left menu.

Let’s zoom in on the chart.

We can see that GSC has split the report into “poor”, “need improvement”, and “good”.

Clicking “Open Report” will show us the issues.

And we can click on an individual issue to see example pages.

For some reason, Google groups pages with similar issues together. So to see more, we’ll need to click on one of the example pages.

And we’ll get more URLs in the sidebar.

2. Web Vitals chrome extension

We mentioned earlier that it is possible to test First Input Delay.

Although to reiterate, that test will be based on your own computer/network (and indeed your own personal reaction time), so it’s not as reliable as aggregate field data.

But with that being said, here’s how to do it.

First you’ll need to install the Web Vitals Chrome extension.

Once installed, you can click on the extension to view Core Web Vitals for any page.

But while testing, we recommend checking “Display HUD overlay” in the settings options. That way you’ll automatically get CWV for each page without having to click.

Here’s how the extension displays the CWV for Google’s homepage.

Fair play Google… that’s rapid.

3. Google’s Lighthouse (Chrome Dev Tools)

You can use Google’s Lighthouse in Chrome Dev Tools to get lab scores for Largest Contentful Paint and Cumulative Layout Shift.

To access Chrome Dev Tools, just press  F12 on your keyboard (while using Google’s Chrome browser) and pick the Lighthouse tab.

Lighthouse does not currently report First Input Delay.

4. Google PageSpeed Insights

To recap, in Google’s PageSpeed Insights you’ll get:

1. lab metrics for LCP and CLS (but not FID)
2. field metrics for all three Core Web Vitals (when sufficient data is available)

It’s comprehensive, which is why we used PageSpeed Insights for our examples throughout this guide.

5. Chrome User Experience Report

If you’re technically minded you can also access CWV data directly from the Chrome User Experience Report API.

This guide explains how to do it.

You’re all set for Core Web Vitals becoming a ranking factor

That wraps it up for our guide to Google’s Core Web Vitals.

While they don’t directly influence rankings at the moment…

…the clock is ticking down to them becoming a direct ranking factor in June 2021.

And Google has been pushing them hard. So it’s likely that sites with poor CWV performance will see a negative impact on their search traffic.

Which of course means that sites with strong CWV metrics could see a noticeable boost.

Unlike some Google updates, we’ve had plenty of warning.

But we recognize it’s a complex topic. So please feel free to ask any questions you have regarding Core Web Vitals in the comments, and we’ll get back to you asap.

Good luck improving your Core Web Vitals!

PS: Get blog updates straight to your inbox!