Skip to content

What is Core Web Vitals?

March 05, 2021

In May of 2021, Google will be introducing 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.

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

Let’s recap what the metrics mean:

  • First Input Delay (FID) measures how quickly the website is able to respond to a user’s interaction.
  • Largest Contentful Paint (LCP) measures when the largest element within the first viewport on a given page of your website is rendered (displayed) in the browser.
  • Cumulative Layout Shift (CLS) measures if elements shift or move around unexpectedly on the user’s screen while the page is loading.

Remember that all three of these metrics have to score in the “Good” category in order to see a ranking boost from Google’s Core Web Vitals ranking factor. More importantly, remember that optimizing these metrics is about more than SEO. These metrics are making the website easier to use for your visitors and are a part of Google’s page experience criteria which also include:

If you have any questions or if you need help optimizing your website’s FID, LCP, and CLS metrics, please let me know.

You may also like

How to Check HTTP Response Status Codes

Every page on every website returns a status code. How do you check the status code for your website’s pages? What do the status codes mean?

How To Find & Fix 404 Errors On Your Website

How do you find the 404 errors on your website? Once found, how do you fix the 404 errors? What tools can help? Find out in this in-depth 404 guide!

JavaScript & SEO

You can use JavaScript more now, without nearly as much risk to your SEO work. But this doesn’t mean you should use JavaScript for everything. Learn how you need to adjust your JavaScript code for optimal SEO performance.