Core Web Vitals
What are the Core Web Vitals and why do they matter? Learn how to improve the Core Web Vitals
Core Web Vitals
Core Web Vitals are a subset of the Google Page Experience. The Core Web Vitals are high-level metrics, designed by Google, to capture the user experience. Three core Web Vitals metrics are measured: Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. Each of these metrics is automatically assigned a rating of Good, Needs Improvement, or Poor based on the industry standard methodology and testing designed by Google.
You will learn what the Core Web Vitals are and how to measure and improve them.
Table of Contents
- Core Web Vitals
- Google page experience and Core Web Vitals
- What are the Core Web Vitals?
- How to measure the Core Web Vitals
- How to pass the Core Web Vitals?
- Largest Contentful Paint
- First Input delay (FID)
- Cumulative Layout Shift (CLS)
- What should you learn to become a Core Web Vitals expert?
- Do Core Web Vitals plugins work?
- Should I focus on mobile or desktop?
Google page experience and Core Web Vitals
You can find your site's Page Experience data Core Web Vitals data in the 'Experience' section of your Google Search Console account.
What are the Core Web Vitals?
Google's Core Web Vitals are three metrics (Largest Contentful, Paint First Input Delay and Cumulative Layout Shift) that measure the user experience on websites. These metrics rate how quickly page content loads, how quickly a browser can respond to a user's input, and how (un)stable the content is as it loads in the browser.
Why do the Core Web Vitals matter?
Now that you know what the Core Web Vitals are the next question is: "Why should I care about the Core Web Vitals?". Now this is a great question.
Core Web Vitals = great UX
Mostly the Core Web Vitals are about a great user experience . The Core Web Vitals give you an idea of how user wills experience your website. When users have a better experience, they’re more likely to convert into customers and return to your site.
Core Web Vitals = ranking factor
The Core Web Vitals are also a (small) ranking factor in Google. Passing the Core Web Vitals might just give you that competitive edge. I have seen this happen many times over. This is what Google themselves say about the matter: "Great page experience doesn't override having great page content. However, in cases where there are many pages that may be similar in relevance, page experience can be much more important for visibility in Search."
Core Web Vitals = top stories
Also good to mention: Previously an AMP page was required for a position in Top Stories of the mobile Google Search. The goal with this was to speed up the mobile web. But with the Core Web Vitals, AMP will no longer be a necessity.
What is important from 2021 is that your mobile pages simply score well on page experience.
But that doesn't mean you should convert your AMP pages either. If your AMP pages score well on Core Web Vitals, that's totally fine and then leave it be.
This also applies the other way around: your mobile website does not need AMP, but must therefore score well on the Core Web Vitals.
How to measure the Core Web Vitals
The Core Web Vitals are measured by Google and are recorded in the CrUX dataset. CrUX is the official dataset of the Web Vitals program. All user-centric Core Web Vitals metrics will be represented in the dataset.
- The CrUX Dashboard is a Data Studio dashboard that allows you to query and render CrUX data into an interactive dashboard, as well as exporting PDF reports.
- CrUX on BigQuery provides a publicly accessible database of all origin-level data collected by CrUX. It is possible to query any and all origins for which data is collected, analyze any metric that CrUX supports and filter by all available dimensions. Full metric histograms are stored in the BigQuery tables allowing for visualization of performance distributions, including experimental metrics.
- The CrUX API provides programmatic access to CrUX data by page or origin, and can be further filtered by form factor, effective connection type and metrics.
- PageSpeed Insights uses CrUX to present real-user performance data alongside performance opportunities powered by Lighthouse.
- The PageSpeed Insights API offers programmatic access to the data shown in PageSpeed Insights, including Core Web Vitals data from CrUX.
Rum data is collected from Real User Monitoring. RUM data is the next best thing to the CrUX dataset. The CrUX dataset is highly anonymous and does not lend itself to be analyzed very well. The CrUX data is also 28 days behind. That is why many Core Web Vitals professionals rely on Real User Metrics. Just like the CrUX data, real user data is being used to measure the Core Web Vitals.
Lighthouse is a powerful tool. But understand this: Lighthouse does not measure the Core Web Vitals! Lighthouse is a so-called LAB tool. Lighthouse performs an analysis under specific circumstances. It does not navigate between pages, does not cache resources, does not interact with the website and does not mimic real life circumstances.
Nevertheless lighthouse is a great tool and if used properly it will tell you a lot about the Core Web Vitals issues on a page.
How to pass the Core Web Vitals?
Each of these metrics is automatically assigned a rating of Good, Needs Improvement, or Poor based on the industry standard methodology and testing designed by Google. To pass the Core Web Vitals at least 75% of your visitors need to have a 'good' LCP, FID and CLS score in the Google CrUX dataset.
Let's take a closer look at those metrics, see what they are and how to improve them.
Largest Contentful Paint
Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics. The LCP captures the Loading part of the Core Web Vitals and represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport.
What is the Largest Contentful Paint?
The largest Contentful paint is a largest single element that has content of the type image or text that has been painted on the visible part of the screen. The LCP timing indicates the time in milliseconds between requesting the page and when the largest contentful (DOM) element is displayed on the visible part of the web page (above the fold).
The LCP is chosen because it focused on a visitor's user experience. When the LCP occurs you can assume that a visitor thinks the page is finished (while that may not be the case at all).The LCP was created to answer the question: ' When is the content of a page visible?'.
What is a good LCP score?
A good LCP score is anything below a 0 and 2.5 seconds. If your LCP score is between 2.5 and 4 seconds it needs improvement. Any LCP score above 4 seconds is considered poor. To pass the Core Web Vitals for the Largest Contentful Paint at least 75% of your visitors need to have a 'good' LCP score.
How to improve the LCP
When a page renders a lot might happen. Styles, scripts, fonts and images usually compete for network and CPU resources. Everything that happens either network or CPU wise before the LCP element has been painted will affect the LCP.
- Prioritize your LCP element with resource hints
- Make LCP element Cache-able
- Load LCP element from your main domain
- Remove render blocking resources.
- Avoid unnecessary resource hints
- Use critical CSS, split up your CSS files or defer non-critical CSS
- Break up long tasks
- Consider a CDN
- Pre-render your content
First Input delay (FID)
First Input Delay (FID) is the second of the Core Web Vitals metrics. The FID captures the interactivity or usability part of the Core Web Vitals and represents how quickly the browser responds after the first interaction with a web page.
What is the First Input Delay
The First input delay captures the first impression of a site's interactivity or load responsiveness: or how quickly a page responds to the users first interaction.
The First Input Delay measures the time from a users first interaction with a page to the time when the browser is able to respond to that interaction. The first Input Delay cannot be measured by Lab tools like lighthouse because it requires real user input.
In lighthouse the Total Blocking Time metrics correlates pretty well with the First Input Delay. While the FID is usually (a lot) lower the the Total Blocking Time, improving the TBT will also improve the FID.
What is a good First Input Delay Score
A good FID score is anything below a 100 milliseconds. If your FID score is between 100 and 300 milliseconds it needs improvement. Any FID score above 300 milliseconds is considered poor. To pass the Core Web Vitals for the First Input Delay at least 75% of your visitors need to have a 'good' FID score.
How to improve the First Input Delay
- Split scripts into smaller bundles.
- Break up Long Tasks
- Use a web worker
- Avoid iframes
- Async decode your images
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) is the last of the three Core Web Vitals metrics. The CLS captures the Visual Stability part of the Core Web Vitals and represents unexpected movements of elements on the page as content renders or new content is shown on the page.
What is the Cumulative Layout Shift
The Cumulative Layout Shift focuses on the visual stability of a webpage. In plain English: 'it measures if parts of the page jump around'.
The CLS score is based on 2 'fractions'. The impact fraction and the distance fraction. When an element is visually 'unstable' it will change it's dimensions causing other content to shift. The distance is the number of pixels relative to the viewport. The impact is the size of the affected elements relative to the viewport.
How to improve the Cumulative Layout Shift
The Cumulative Layout Shift can be improved by making sure elements on the page immediately render with their correct and final dimensions
- Specify image dimensions. Images without width and height set are by far the number one cause of layout shifts. When image dimensions are missing the image will first render at 0x0 and only when the image has loaded it will take up the space it needs.
- Minimize webfont impact. Web fonts can cause layout shifts when they are swapped with the fallback font.
- Use placeholders when fetching data. Data that is inserted into the page at a later time will always cause a layout shift. IT is usually a great idea to reserve the space.
- Be careful when banners or frames. Banners and iframes can cause large layout shifts. Reserve the (minimal) space that banners or frame might take up.
What should you learn to become a Core Web Vitals expert?
So you want to eb an expert. That is great! You are in for a bumpy ride! Some parts of the Core Web Vitals are easy to fix. Others are really hard and require years of experience. To become a Core Web Vitals export you basically need to master 4 traits.
Third you need to be an HTML and CSS expert because the way you build your applications matters a lot. There is often a fast and a slower way of doing things.
Fourth you need to know how networks and webservers work. Fast networks, the right http headers and the the right protocol for the right situation can make a huge difference in the Core Web Vitals. When yo are going to advice larger corporations you better come prepared!
Do Core Web Vitals plugins work?
There are a lot of plugins and tools out there that try to improve the Core Web Vitals. For example wp-rocket.
I can talk for hours about how I feel about those tools. I will spare you the details for now. The fact of the matter is that they sometimes improve the Core Web Vitals and sometimes they have very little effect.
It all depends on the nature of the 'Core Web Vitals mistakes' that you are trying to fix. Did you forget to lazy-load your images or forget to defer your scripts? Those tools might then improve the Core Web Vitals considerably. On the other hand, if your slowness is caused by 'critical scripts that change the layout of your page' (like a slider plugin) or 'a large DOM size' those plugins will often do more harm than good.
Basically a plugin will fix the issues that any good programmer could fix in a matter of hours. They won't fix and might even worsen the more complicated issues.
Should I focus on mobile or desktop?
That is a great question. As a rule of the thumb you should focus on mobile.
When you manage to pass mobile Core Web Vitals it will become a lot easier to also pass the Desktop Core Web Vitals (if you are not passing them already). This is because your average mobile device is slower because of lower bandwidth, less memory and less CPU power then your average desktop.
There are a few exceptions though. On a desktop the visible viewport is larger. It is common for a mobile LCP element to be a text based element while on a Desktop a lower placed image will become the largest Contentful Paint element. On desktop the possibility for (smaller) layout shift also increases because there is just more screen and more visible elements to shift.