What is Core Web Vitals?
By Matthew Edgar · Last Updated: May 19, 2023
In May of 2021, Google introduced a new ranking factor that is part of the Google Page Experience Algorithm Update which measures different aspects of a website’s user experience. This is called Core Web Vitals and the initial roll out will evaluate a website on three metrics:
Understand Core Web Vitals in Context
Before defining these metrics in detail, it is important to understand Core Web Vitals in context. Core Web Vitals follows the same general direction as other updates related to measuring a website’s user experience. For example, Google introduced mobile friendliness factors in 2015. Mobile speed became a ranking factor in 2018 (speed on desktop has been a ranking factor for much longer). In 2014, Google began giving a ranking boost to sites using SSL certificates to help improve security. This “boost” became a mandate by 2018 when Google’s Chrome browser began noting which sites were not secure. In 2017, Google introduced a penalty for sites using intrusive interstitials and pop-ups. You can even see some emphasis on user experience in Google switching to mobile-first indexing in 2019.
User experience and site quality matter greatly to Google. With each update, including Core Web Vitals, Google continues to find new ways to determine what makes for a better user experience and what makes a website higher quality. Along with that, Google keeps finding new ways to quantifiably measure things that previously were not quantifiable within a website’s user experience. The Core Web Vitals metrics are an outgrowth of this theme: these metrics represent new ways to quantifiably measure different aspects of a website’s user experience.
The big thing to keep in mind with Core Web Vitals is that this isn’t the last time Google will roll out a change related to user experience. While you should focus on improving the Core Web Vitals metrics, the broader takeaway is that companies need to find other ways to improve all aspects of their website’s user experience.
With all that in mind, let’s talk about the metrics.
What is First Input Delay?
First Input Delay (FID) measures how quickly the website is usable. This is different than previous speed metrics that only evaluated how fast the website loaded. Instead, FID measures an aspect of how people interact with the website—making this a more direct measure of user experience.
Where FID is concerned, a website is usable when people can interact with it. That includes doing things like clicking or tapping a link, submitting forms, or playing videos. It important to note that zooming, dragging, and scrolling are not considered interactions where FID is concerned.
What is a Good FID Score?
Google buckets FID scores into three ranges: good, needs improvement, or poor. To get the ranking boost of Core Web Vitals, FID (and the other two Core Web Vitals metrics) needs to be in the good range. Here are the FID ranges:
- Good <=100ms
- Needs Improvement <=300ms
- Poor >300ms
That means when a visitor to your website first attempts to interact with your website, your website needs to respond to that interaction within 100 milliseconds to be considered good. For example, if I visit your website and click on a button, something should happen in response to my clicking that button within 1/10th of a second.
The 100ms mark isn’t arbitrary. At that timing, the response will feel instantaneous. Between 100-300ms (in the needs improvement category), the website will still feel pretty fast but a visitor will be able to perceive a delay. (Don’t believe this? Test your reaction time.) Even though it seems fast, beyond 300ms, the website will start to feel slow.
Remember, FID does not mean that your website needs to fully load within 100ms. The total load time is a different metric and that metric is not a Core Web Vital. Of course, the faster your website loads and the more efficiently your server and code work together to load the website, the faster the website’s FID will be.
FID Is About Idle Time
To reduce FID, your website must respond quickly when a visitor attempts to interact with an element on your website. This doesn’t mean your website needs to fully complete the requested task. Instead, your website should respond with some of type of acknowledgment that the visitor’s interaction has been responded to. For example, if a visitor clicks a button, a pop-up might appear within 100ms, showing a loading icon.
Technically, what FID is looking at is the idle time within the main thread. The main thread represents everything the browser is trying to process related to that website as events. When a visitor to a website clicks on a link (or interacts in some other way), that is processed on the main thread. What can happen on poorly optimized websites is that the main thread will be consumed with so many other tasks that it is unable to quickly respond to the visitor’s interaction.
Let’s walk through an example. In this example, the main thread is busy loading files and executing a JavaScript function. Those tasks take about 400ms and block anything else from being loaded until their completion. Just as those tasks begin to be processed, however, the visitor clicks on a link. The visitor would have to wait the full 400ms for those tasks to be completed before the website can respond to that link click.
The solution is to have a lot of idle time. If there is a lot of idle time in the main thread, then the website can respond quickly to the visitor’s interaction. This requires optimizing JavaScript files (including third-party files) and being more thoughtful about when certain things need to load. It also requires optimizing CSS, including deferring non-critical CSS, so that CSS doesn’t fill up the main thread and prevents your website from being able to respond quickly.
Interaction to Next Paint (INP): FID Will Be Replaced in March 2024
Google has announced FID will be replaced by a new metric in March 2024, Interaction to Next Paint (INP). FID and INP both measure how quickly people can interact with a website but in different ways.
To understand the difference between FID and 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.
FID measures the first phase of the interaction—the input delay. Unlike FID, INP measures the entire interaction through all three phases. See the screenshot below highlighting the differences. 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.
The other difference is that FID measures the input delay on the first interaction with the web page. 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.
It is important to note that INP only observes click, tap, and key press interactions. Scrolling and hovering interactions are not observed (currently).
Improving INP is harder than improving FID on a website because you have to improve performance across all phases of the interaction. Like FID, 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.
The INP ranges are:
- Good <=200ms
- Needs Improvement <=500ms
- Poor >500ms
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?
As with FID, Google buckets LCP scores into three ranges: good, needs improvement, or poor. In order to get the ranking boost of Core Web Vitals, LCP (and the other two Core Web Vitals metrics) need to be in the good range. Here are the ranges for LCP:
- 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.
Right now, the elements measured are text and images. In the future, LCP will also likely factor video into this metric. Our recommendation is to optimize your videos along with text and images right now even if it won’t directly affect this metric. That way you plan ahead for the possible metric revision and are doing even more to make your website load that much faster.
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 visual stability. In other words, it measures how much the various elements move around on the visitor’s screen while the page is loading. That can be any element on the page, including images, ads, text, videos, and more. Some unexpected shifting while the website is loading is acceptable and even expected given how certain items load into the browser (such as fonts). However, the idea behind CLS is to minimize the amount of unexpected shifting.
One of the key words 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, provided a user understands the shifting is in response to their interaction. For example, if there is a “read more” link on a page and clicking that “read more” link expands hidden text. When that hidden text expands, the other items shift lower on the page. So long as that hidden text expansion occurs right after the “read more” link is clicked, then that shifting would be acceptable; people would expect that shifting to happen in response to clicking on “read more”.
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 cumulative layout shift represents the sum of all shifting that occurs on the page.
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 First Input Delay (FID)?
First Input Delay (FID) measures how quickly the website is able to respond to a user’s interaction. To reduce FID, optimize your website’s JavaScript files so that your website is able to respond quickly when a visitor interacts.
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?
FID, LCP, and CLS all have to score in the “Good” category in order to see a ranking boost. 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.
What are Google’s Page Experience factors?
Core Web Vitals is a part of Google’s page experience criteria which also include mobile-friendliness, safe browser, secure browsing, and avoiding intrusive interstitials. In detail:
- Mobile-Friendly. The page meets Google’s standards for mobile-friendliness.
- Safe browsing. The page doesn’t contain malicious or deceptive content.
- Secure/HTTPS. The page is served over a secure connection and this secure connection is forced on your website.
- No intrusive interstitials. The content on the page is easily accessible to the user.
Final Thoughts
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 FID, LCP, and CLS metrics, or improving your website’s user experience more generally please contact me.