What is Core Web Vitals?
By Matthew Edgar · Last Updated: February 09, 2024
Core Web Vitals is part of Google Page Experience Algorithm. It evaluates a website on three metrics:
Understanding Core Web Vitals
Before defining these metrics in detail, it is important to understand two things about Core Web Vitals: how it influences ranking and how it is measured.
Are Core Web Vitals a Google Ranking Factor?
No. Core Web Vitals is not a ranking factor. Google has clarified this as recently as February 2024. Even if you meet Google’s thresholds for Core Web Vitals, that does not mean your website will rank in search results.
Instead, Core Web Vitals is one way for Google to measure a website’s Page Experience. Page Experience also evaluates the use of SSL certificates to help improve security (since 2014) and evaluates the use of intrusive interstitials and pop-ups (since 2017). You can even see some emphasis on user experience in Google switching to mobile-first indexing in 2019. This emphasis on user experience is also reflected in their helpful content evaluations.
The bottom line is that user experience and site quality matter as part of Google evaluating the website and determining if the website should rank in search results. While you should focus on improving the Core Web Vitals metrics, Core Web Vitals should not be the primary focus. Instead, what Google is emphasizing is that companies need to find multiple ways to improve all aspects of their website’s user experience. One way, of many, to improve your website’s user experience is to improve site speed.
How Does Google Measure Core Web Vitals?
Google’s Core Web Vitals measurements are not based on how quickly Googlebot can load the website during a crawl. Instead, Google uses data from the Chrome User Experience (CrUX) report. The CrUX report contains performance timing data for actual, real-world people who visited the website using Chrome over the last 28 days.
The data from real-world visitors is referred to as field data. It is only available for indexable pages and pages with sufficient amounts of traffic. Websites with less traffic will not be able to access data in the CrUX report.
When measuring Core Web Vitals, it is important to remember that the website may load quickly for you on a high-speed connection but that may not reflect the experience other visitors have. To understand how real visitors are experiencing speed, review field data in PageSpeed Insights. You can also replicate real-world conditions in tools like WebPageTest.
Interaction to Next Paint (INP)
Interaction to Next Pain (INP) measures how quickly the website responds to a visitor’s interaction. When a visitor clicks a link or taps a button, the website should respond as quickly as possible. If there is a longer delay between the visitor’s action and the result of that action, the website will feel broken and unresponsive to visitors. Slow interaction times will deter people from interacting with the website and keep people from converting.
Initially, Google used a different metric to measure interaction times: First Input Delay (FID). INP replaced FID as a Core Web Vitals metric in March 2024. Where FID only measures part of the first interaction with the page, INP measures the entire interaction time for all interactions on the page. With this change, Google is encouraging websites to take a more holistic view of interactions with the website.
What is a good INP score?
The INP ranges are:
- Good <=200ms
- Needs Improvement <=500ms
- Poor >500ms
This means the website must respond within 200 milliseconds to the visitor’s interaction. This quick of a response will feel nearly instantaneous to the visitor, creating a better overall experience with the website.
INP observes all interactions with a webpage, not just the first interaction. However, the final INP value will only reflect the longest INP observed on that page.
INP only observes click, tap, and key press interactions. Scrolling and hovering interactions are not observed (currently).
What is an interaction?
To understand INP, it is important to understand how an interaction works. When somebody interacts with a website (for example, by clicking or tapping a button), there are three phases of that interaction: input delay, processing time, and presentation delay.
- Input delay starts when a user interacts with the webpage, such as clicking or tapping a button, interacting with the webpage, and ends when the webpage begins to respond to that interaction.
- Processing time is the amount of time it takes the website’s code to completely respond to the interaction.
- Presentation delay is the time it takes the browser to render and paint the result of that interaction to the user’s screen.
See the screenshot below highlighting each of these steps and the differences between INP and FID. This makes INP a more comprehensive metric given that it measures the time it takes from when a visitor starts interacting with a webpage (like clicking a button or a link) until the result of that interaction appears on the user’s screen.
Improving INP requires improving the performance across all phases of the interaction. INP can be improved by having more idle time on the website so that there is little delay between the interaction and the website beginning to respond. In addition, reducing INP requires optimizing the website’s code so that it can be processed more quickly and prioritizing faster rendering in response to the visitor’s interaction with the website.
What is Largest Contentful Paint?
Largest Contentful Paint (LCP) measures when the largest element on a given page of your website is rendered (displayed) in the browser. LCP doesn’t mean that your entire website needs to load within the particular time constraints. Instead, LCP is measuring how long a visitor to your website must wait before they can see the main content of a page—the longer people have to wait, the worse the experience of using that website.
An assumption about LCP is that the largest elements on a page represent the main content of the page. More often than not, that assumption proves to be true. Larger elements—like images, videos, and blocks of text—are typically more important for visitors to see and, therefore, those elements should be visible as quickly as possible. However, as you review your website, you might find that larger elements are less important for visitors. In those cases, you may need to not only optimize the larger elements for speed but also reconsider the purpose of that page as well.
What is a good LCP score?
Google’s current LCP ranges are:
- Good <=2.5s
- Needs Improvement <=4s
- Poor >4s
This means that the largest elements on your website’s page need to be visible within the first 2.5 seconds of a user loading that page. For example, if the largest element on a page is an infographic, then you need to optimize the infographic image and the rest of your website enough so that the image can render into the browser within the first 2.5 seconds of a visitor loading that page.
Text and images are the most common candidates for LCP. As of August 2023, Google began including the first frame of autoplay videos as an LCP candidate along with the first frame of animated images.
Improving LCP by Understanding the Viewport
So far, I’ve been saying “largest element on the page”. While that is the basic concept, it misses a bit of the nuance of this metric: LCP measures what is rendered in the visible portion of the users’ browser, or the viewport. This further emphasizes a common theme Google and others have made for many years now: the items above the first scroll (what users are most likely to see) needs to load quickly. This also means that if you have a larger item on your page, below the first scroll for most of your visitors, that item will not be counted toward LCP.
The difficulty though, is that the viewport will change for almost every user depending on the device’s screen dimensions and if the user has resized the browser window. As a result, one of the first steps to improving your website’s LCP is to know what viewport sizes your visitors are using.
Once you know the viewport sizes, you can load your website in those different sizes and determine what largest elements are visible within each viewport size. Reviewing this will give you an idea of what elements to prioritize when optimizing your website and will also help you find better ways to test your website’s performance.
What is Cumulative Layout Shift?
The final Core Web Vitals metric is Cumulative Layout Shift (CLS). CLS measures how much the various elements move around on the visitor’s screen in an unexpected manner. Elements include images, ads, text, videos, and more.
The key word in this definition is “unexpected”. If elements shift in response to a visitor’s interaction with your page, that will not present a problem for CLS. For example, if there is a “read more” link on a page and clicking that “read more” link shows hidden text. When that hidden text is shown, other elements below that text will shift lower down the page. This will not be counted as part of CLS because people would expect that shifting to happen in response to clicking on “read more”.
The goal is to minimize unexpected shifting. A high CLS score means there is a lot of unexpected shifting and the page looks visually unstable for visitors. This makes the page much harder for visitors to use.
What is a good CLS score and what does this score mean?
CLS is based on a formula (see below) that produces a decimal value that measures the total amount of unexpected shifting that occurs on a website. As with the other Core Web Vitals metrics, this score is grouped into three buckets:
- Good <=0.1
- Needs improvement <=0.25
- Poor >0.25
The lower the CLS score, the better. However, the CLS scores provided aren’t as intuitive as the other Core Web Vitals metrics. To make it more intuitive, we need to understand the CLS formula.
To arrive at a CLS score, you have to multiply two metrics. The first metric represents how much space a shifting element uses on the screen. This is called the impact fraction. The other metric represents how much that shifting element moves. This is called the distance fraction. When the impact fraction is multiplied by the distance fraction, you get the layout shift score.
The layout shift score is no longer measured as the total shifting across the entire session with the page.
Shifting is measured by evaluating session windows where the shifting occurs. A session window starts when the shift is detected and lasts up to five seconds. A window includes a group of one or more shifts that occur during those five seconds.
The shifting within the session window is totaled and the session window with the largest amount of layout shift is used for the page’s final CLS score.
Here is an example of session windows from Web.dev. There are three session windows, each with various shifting. Session window 1 appears to have the most shifting in this example, so the total of shifting within that window would be used for the final CLS score.
From Web.Dev. Example of session windows. Blue bars represent the scores of each individual layout shift.
Now that we know what factors into the formula, we can get a better sense of what that CLS score means. The more space the shifting element takes up, the bigger the problem. The bigger the distance the element moves, the bigger the problem. To fix a high CLS score, you want to focus on minimizing the size of the elements that move and minimizing how far those elements move. That means a 100px image shifting 10px is worse than that same 100px image shifting 2px—though, ideally, there would be no shifting at all.
Solving CLS With Placeholders
Understanding this formula helps us understand one way we can solve some CLS problems, by using placeholders for shifting elements. For example, let’s say you have an ad that appears in the middle of your page. However, that ad is from a third party and tends to load slowly into the browser. When it does eventually load, it causes everything below the ad to shift down the page and that shifting would not be in response to a user’s actions. This would result in a high distance score given how much this ad caused other elements to load and therefore, this page would have a high CLS score.
Using placeholders is a good solution when you may not be able to remove the shifting elements from your website. In the case of an ad, it would be critical to keep that ad on your website’s pages because it is important for your company’s revenue. Instead of removing the shifting element, you can allow space for that element with a placeholder element. In the ad example, if the ad is 300×300, you could create a 300×300 space for that ad to load into and that 300×300 space would be empty until the ad loads. That way, when the ad does appear, it would simply fill that empty space instead of causing anything to shift on your website.
Recapping Core Web Vitals: Frequently Asked Questions
What is Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) measures the time between a user interacting with a webpage (like clicking a button or a link) and the result of that interaction appearing on the user’s screen. The longest INP observed should be under 200ms to be considered Good. Only click, tap, and key press interactions are observed. Scrolling and hovering interactions are not observed (currently).
What is Largest Contentful Paint (LCP)?
Largest Contentful Paint (LCP) measures when the largest element within the first viewport on a given page of your website is rendered (displayed). The viewport represents the portion of the website visitors can see before scrolling. To improve LCP, optimize how the largest elements on the page are loaded or remove those elements from the website if they are not needed.
What is Cumulative Layout Shift (CLS)?
Cumulative Layout Shift (CLS) measures if elements shift or move around unexpectedly on the user’s screen while the page is loading. To reduce CLS, minimize how much space the shifting element consumes and minimize the distance the shifting element moves around the page.
How does Core Web Vitals improve my ranking?
INP, LCP, and CLS all have to score in the “Good” category in order to pass Core Web Vitals. However, having a Needs Improvement or Poor score won’t prevent your website from ranking. Google will prioritize high-quality websites and good content over fast websites. However, if you can have a high-quality website, good content, and the website loads quickly, so much the better.
Remember that optimizing these metrics is about more than SEO. These metrics are making the website easier to use for your visitors. If you have any questions or if you need help optimizing your website’s INP, LCP, and CLS metrics, or improving your website’s user experience more generally please contact me.