Core Web Vitals is a new ranking signal introduced by Google.
The signal consists of a number of factors that Google thinks are important when it comes to the user experience offered by a web page.
Specifically, the Core Web Vitals assessment measures 3 components of page speeds:
- Overall speed (Largest Contentful Paint)
- Interactivity (First Input Delay)
- Visual stability (Cumulative Layout Shift)
The new signal is still in the early stages of development and will be slowly rolled out, beginning in May of 2021. In order to help webmasters adjust to the new signal, Google has provided a guide that explains the new signal in detail.
In this guide, we'll build on that guide, and explain everything you need to know about this new metric, and what you can do to pass the Core Web Vitals assessment.
What are Core Web Vitals?
The Core Web Vitals ranking signal is part of Google's measure of overall page experience. The Core Web Vitals part of this signal includes three measures of page speed.
In order to pass the Core Web Vitals assessment, a page needs to score "good" for all three Core Web Vitals:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Core Web Vitals operates alongside existing measures of page experience. These include:
- Safe Browsing (no malware)
- Mobile Friendliness (mobile-responsive and optimized website)
- HTTPS (SSL certificate installed properly)
- Intrusive Interstitials (no intrusive pop-ups)
By including each of these factors into its algorithm, Google is helping the web become a better experience for users across devices and browsers.
3 Criteria of Core Web Vitals
Core Web Vitals are a set of metrics which can be mapped to overall speed, visual stability and responsiveness.
The signal is made up of three specific metrics:
- Largest Contentful Paint (LCP) is the time taken for the main content to load. The ideal measurement is 2.5 seconds or faster.
- First Input Delay (FID) is the time taken for a page to be interactive. If a user clicks on something interactive, such as a video or button, the FID will increase if there is a delay in responding after a user clicks on it. To pass, this must be 0.1 seconds or less.
- The Cumulative Layout Shift (CLS) is the amount of the unexpected shift in the visual layout of the page content as it loads. CLS isn't measured in seconds like most of the other metrics—to pass it must be 100 milliseconds or less.
These metrics are designed to aid owners measure the overall user experience when it comes to loading speed, interactivity, and visual stability.
Google's PageSpeed Insights

There are many tools available to test a site's speed, but Google offers an official site speed tool known as the PageSpeed Insights tool.
This is the primary way developers test their site's speed. It also contains real data from Google's Big Query on whether or not the page and website as a whole pass the Core Web Vitals Assessment.
PageSpeed Insights Score

The most prominent feature on this report is the score at the top.
This is a score from 0-100 based on the estimated speed of the URL being tested.
This score is based on the different metrics included in the Lighthouse calculator. More information on the Lighthouse calculator is provided below.
There are variables included in this score which are not included in the Core Web Vitals assessment, so be careful about obsessing too much about this score.
It's important to note that this score is based on lab data, not on field data.
Mobile vs Desktop

The report allows you to toggle between mobile and desktop, since your site will load differently depending on the device.
It is important that your site passes the Core Web Vitals assessment on both desktop and mobile, with mobile carrying more weight due to Google's "mobile first indexing" initiative.
Sites will typically be faster on desktop than on mobile.
Field Data vs Lab Data

The PageSpeed Insights report has 2 types of data: field data and lab data.
- Field data is real data collected from users over a 28-day collection period.
- Lab data is simulated data from Google's crawl while the report was loading.
As mentioned before, Google assesses Core Web Vitals via field data, not lab data.
When updates are made to your site, the changes should be reflected immediately in your lab data, but not in your field data. That's because your lab data is a crawl of your page in its current state, whereas your field data will take 28 days to fully update.
The metrics found in the lab data can be thought of as where your field data is going to be in 28 days.
Where to Find the 3 Components of Core Web Vitals Within PageSpeed Insights

The 3 components of the Core Web Vitals assessment can be found within the field data section of the PageSpeed Insights report. They are highlighted in the screenshot above and have a blue marker next to them.
First Contentful Paint (FCP) is not included in the Core Web Vitals assessment since it is a means to an end. The end is Largest Contentful Paint (LCP).
First Contentful Paint (FCP) is the time it takes for the first part of the page to show.
If you have a slow First Contentful Paint, it means that it is taking users a long time for the server to deliver your site.
Without a fast First Contentful Paint, it is difficult or impossible to have a fast Largest Contentful Paint
Page vs Domain Core Web Vitals -- Origin Summary

When you run a test on a page using the PageSpeed Insights tool, the score shown is of the page, not the domain.
Google's Big Query keeps a record of every site's page speeds as a whole, which is reported in the Origin Summary section of the report.
Unless the page is highly trafficked, the report will say:
"The Chrome User Experience Report does not have sufficient real-world speed data for this page."
Below that, the report says whether or not the domain passes the Core Web Vitals assessment.
In this case, the screenshot above says the following:
"Over the previous 28-day collection period, the aggregate experience of all pages served from this origin passes the Core Web Vitals assessment."
To check your domain's origin summary over time using the Chrome User Experience Report (CrUX Report). This can be set up using Google's Data Studio.

The report looks like this.
What are "Good" Core Web Vitals Scores?

Source: Google
In order to get a passing score on the Core Web Vitals assessment, 75% of users must have a "good" experience across all the 3 components of Core Web Vitals.
Google defines the following as "good," "needs improvement," and "poor" scores:
Largest Contentful Paint (LCP)
- LCP below 2.5 seconds – GOOD
- LCP between 2.5 - 4 seconds - NEEDS IMPROVEMENT
- LCP above 4 seconds - POOR
First Input Delay (FID)
- FID below 100 milliseconds - GOOD
- FID between 100 and 250 milliseconds - NEEDS IMPROVEMENT
- FID above 250 milliseconds - POOR
Cumulative Layout Shift (CLS)
- CLS below 0.1 - GOOD
- CLS between 0.1 and 0.25 - NEEDS IMPROVEMENT
- CLS above 0.25 - POOR
It's important to recognize that a "good" score can still be improved. A good CLS score, for instance, can be as low as 0 for pages that are fully static and increase as the layout shifts begin to occur on the page.
Again, 75% of your users must have a page experience which meets the "Good" threshold for each component in order for you to pass the Core Web Vitals test.
Using Lighthouse to Diagnose Core Web Vitals
It's possible to go beyond the basic Core Web Vitals (CWV) Audit and Fix tool in order to better understand – and improve – the speed and performance of your pages.
The Lighthouse Calculator
The Lighthouse calculator aims to provide a balanced representation of the user's perception of performance.
The calculator is based on a number of metrics, and the weighting each is given have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.
For Lighthouse 6, the most recent iteration of the calculator, the metrics are as follows:
First Contentful Paint 15%
Speed Index 15%
Largest Contentful Paint 25%
Time to Interactive 15%
Total Blocking Time 25%
Cumulative Layout Shift 5%
Once Lighthouse is done gathering the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.
You can read more about how these scores are calculated in the Lighthouse documentation. But for most website owners, the more important thing to understand will be how to use the metrics to diagnose your website.
It's important to note that First Input Delay (FID) is a part of Core Web Vitals but is not included in the calculator since it can only be derived by real users clicking on interactive elements on the page. Time to Interactive and Total Blocking Time are meant to estimate the First Input Delay.
Using Lighthouse to Address Issues
You can use Lighthouse to find opportunities to improve page speeds.
You may need a good and astute web developer who can improve page speed or somebody else who can address these problems if you're not very technical, but the tool will show you where all areas for improvement are to be made.
Here is an example:

The biggest opportunities are highlighted in red, and the tool will give you descriptions of why they are not performing well.
The report also gives you information on how much time can be saved by fixing each issue detected with the site.
Common Ways to Improve Core Web Vitals
Preloading
Preloading allows you to inform a user's browser about critical resources you want it to load as soon as possible, prior to them being found in HTML. Preloading can be very useful when it comes to optimizing LCP, because it allows you to tell a browser to load content that Google regards as the most important first.
Preloading is usually executed via Javascript, but can be implemented in CSS also. At times, important resources that are declared or used in a certain CSS or JavaScript file may be fetched later than you would like, such as a font tucked deep in one of the many CSS files of an application.
If you know that a particular resource should be prioritized, use <link rel="preload">
to fetch it sooner.
Many types of resources can be preloaded, but you should first focus on preloading critical assets, such as fonts, above-the-fold images or videos, and critical-path CSS or JavaScript. You should also note that, since Chrome 73, preloading can be used along with responsive images to combine both patterns for much faster image loading.
Optimizing Fonts and Images
Choosing the right font is a common area for improvement.
You want to choose a font which is close enough to a computer's system font so that the page does not have a dramatic shift once CSS is applied to the font.
If the font is dramatically different, then the page will "shift" once the page loads. The page shifting after it is already loaded will harm your Cumulative Layout Shift (CLS) score.
Additionally, you want to only load the fonts being used on the site.
Plugins will often load hundreds or even thousands of fonts that are unused, which must load each time a page is requested.
Images should be optimized for resolution relative to size. You should make your images as small as possible without compromising resolution.
Tiny PNG is a tool you can use to minify image sizes while preserving its resolution.
Google would like sites to deliver images over their "next-gen" format, which can be an even smaller file size, but it can be sufficient to simply reduce file sizes using a photo-editing tool.
A good target to shoot for is to get each image size to be 50kb or less.
Improving Server Response Time Using a CDN
Your Largest Contentful Paint (LCP) is the most difficult component of the Core Web Vitals assessment to pass.
In order to have a fast Largest Contentful Paint, you must have a fast First Contentful Paint (LCP). The slower your First Contentful Paint is, the slower your Largest Contentful Paint will be.
The #1 way to improve your First Contentful Paint is by reducing Time to First Byte (TTFB), which is a measure of your server response times.
You can improve your TTFB in a number of different ways:
- Optimize your server
- Route users to a nearby server using a CDN
- Cache assets
- Serve HTML pages cache-first
- Establish third-party connections early
- Use signed exchanges
101domain's Secure Web Accelerator is powered by Cloudflare, the largest content delivery network worldwide.
A content delivery network (CDN) stores cached copies of your website on servers around the globe.
That way, a nearby server can serve your site to a user regardless of where they are around the globe. This dramatically reduces the lag between a user's request and a site loading.
Our higher-tiered plans of Secure Web Accelerator offer even faster speeds and greater protection against attacks on your site.
Additionally, our team can also help you adjust settings within Cloudflare to get the fastest site possible.
This is the easiest way to improve one's Largest Contentful Paint and overall Core Web Vitals.
Bottom Line
Core Web Vitals is the newest variable being added to Google's SEO algorithm.
It is a measure of overall page speeds, using 3 distinct areas of measurement:
- Overall speed (LCP)
- Interactivity (FID)
- Visual stability (CLS)
Historic updates have significantly affected search rankings, so it is essential that your company does all it can to pass the Core Web Vitals assessment.
If you are a business looking to perform well in Google's search results, 101domain offers solutions that can help you pass the Core Web Vitals assessment.
Contact someone on our team today to see how we can help you pass the Core Web Vitals assessment.