Core Web Vitals are currently a hot topic in the SEO community. For good reason: improving them improves the user experience, and they will also become a ranking factor for Google Search on mobile starting in May 2021. This change will most likely be implemented all at once around the world.
You must score “good” for all three Core Web Vitals—Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS)—based on field data to pass the Core Web Vitals assessment.
I’ll use the terms “field data” and “lab data” frequently throughout this article. I feel it necessary to explain the distinction right away because it is often misunderstood:
The Chrome User Experience Report (abbreviated as CrUX) collects field data from real users. Real users are not involved in the collection of lab data because it is done in a controlled environment.
Now that we’ve cleared that up, how do Core Web Vitals factor into Google’s ranking algorithms?
Currently, Google evaluates a website’s user experience by determining whether it is mobile-friendly and provides secure browsing via HTTPS. There should also be no are no intrusive interstitials (aka popups) getting in the way of a browser’s general experience and yes, it needs to be ‘generally fast, especially on mobile.
Now, in addition to these factors, they’re adding Core Web Vitals, which will form part of a group of signals used by Google to grade “Page Experience.” and become a full time component of their search ranking algorithm.
It’s important to remember that Core Web Vitals—both field data and lab data metrics—will be a moving target: they’re a proxy for measuring user experience, and because the web and its users are constantly evolving, Core Web Vitals will inevitably evolve as well.
The problem with all of this is that there is (or seems to be at first glance) a lot of techy, code-y stuff involved that most people who are not coders find confusing and intimidating. So these people – and that probably includes you, are worried about just how they are ever going to meet the Core Web Vitals standards.
Because there is a lot of misinformation about Core Web Vitals—and the correct information is scattered all over the place. Even Google can’t keep everything in one place, but here I am going to share just the basics, without the scaremongering or technical gibberish.
What Are Core Web Vitals?
Core Web Vitals are a set of user-facing metrics for speed, responsiveness, and visual stability that site owners can use to assess their users’ online experience.
The Core Web Vitals, Google says are:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
There are then non-Core Web Vitals that make up Web Vitals as a whole. These are:
- Total Blocking Time (TBT)
- First Contentful Paint (FCP)
- Speed Index (SI)
- Time to Interactive (TTI)
Before I head into just what each of these terms mean, how they are measured and what can be done on your site to improve them, you’d probably like to know why you should care about any of this in the first place.
Why Core Web Vitals Matter
The three main reasons you (and everyone else) should be concerned about Core Web Vitals are as follows:
Visitors prefer fast sites that are simple and enjoyable to use on any device and from any location. The bottom line is that if you provide a great user experience, you’ll make more money.
As I mentioned in the introduction, Google has announced that starting in May 2021, Core Web Vitals will be used as a ranking factor. While at Pearl Lemon we don’t expect a major shift in rankings by May, and relevance remains far more important we do expect it to become more important over time.
Because you’re providing a good user experience, passing the Core Web Vitals assessment is likely to result in fewer users retreating back to the SERP—and Google has hinted that they may start displaying a “Good Page Experience” badge in their search results. These are referred to as “indirect ranking factors” because they have an impact on searcher behavior (e.g., more clicks for pages with this badge), which is then fed back into Google’s algorithms.
Now you know why these metrics are important, let’s dive into each of the Web Vitals metrics, starting with the Core Web Vitals.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) is a Core Web Vital that counts down the seconds between when the page loads and when the largest text block or image element appears on the screen.
Its purpose is to determine when the page’s main content has completed loading. The LCP should be as low as possible. Because it is a metric that measures perceived load speed, a fast LCP reassures users that a page is useful. LCP can be found in both field and lab data.
As soon as the user interacts with the page, the browser will stop reporting new LCP candidates (via tapping, scrolling, a keypress, switching tabs, or closing the tab). When the LCP is finished in the lab, it’s not entirely clear. This should happen as the page approaches Time to Interactive (TTI) and it becomes clear which element is the final LCP candidate.
What does your LCP score mean?
Here’s how to figure out what your LCP score means:
- 2.5s is a good score (2.5 seconds or less)
- There is room for improvement between 2.5 and 4 seconds
- More than 4 seconds is considered poor.
What could be the cause of a low LCP score?
A low LCP score could be caused by a variety of factors, including slow server response times, render-blocking JavaScript and CSS, and having your largest content resources be too large and take too long to load.
Increasing your LCP score
You can improve your LCP score by optimizing your critical rendering path, CSS, and reducing the size of images, for example. It is far beyond the scope of this article to describe all of them. Instead, we recommend visiting web.dev’s resources on improving LCP scores as they really are the experts here.
First Input Delay (FID)
FID is a Core Web Vital that measures the time in milliseconds between when a user interacts with your site for the first time (i.e. when they click a link, tap a button, or press a key) and when the browser is able to respond to that interaction.
A user’s first impression of your site’s interactivity and responsiveness is based on the FID. Make a good first impression!
As the name implies, this metric can only be measured in the field because it is dependent on user interaction. As a result, the FID can only be found in field data. The FID should be as low as possible.
The Total Blocking Time metric is used for lab testing because it closely correlates with First Input Delay.
Important factors to consider
The FID does not account for the time it takes the browser to process an event (such as a button click) or to update the user interface afterward.
Scrolling and zooming interactions aren’t counted as actions because they’re continuous in nature and have very different performance constraints because the scrolling action is handled by the GPU rather than the CPU, or the CPU’s compositor thread (opens in a new tab) rather than the main thread.
What does your FID score mean?
Here’s how to figure out what your FID score means:
- Good: a time of less than 100 milliseconds
- Could Use Improvement: More than 100 milliseconds and less than 300 milliseconds
- Poor: More than 300 milliseconds
What could be the source of a low FID score?
A browser’s main thread is often busy parsing and executing JavaScript code, which results in a low FID score. The main thread can’t respond to a user’s interaction while it’s busy.
Increasing your FID score
If you want to raise your FID score, you should investigate what is preventing the browser from becoming interactive. You can improve your FID score by doing the following things:
- Ensure JavaScript execution time is as fast as possible.
- Ensure work in the main thread is being minimized.
- Ensure third-party code’s impact is being reduced. In practice, we have found this to be a big problem when working on the FID and web vitals in general. You can’t control third party code and so you may be left with a choice: do you remove it, or is it too useful for that?
Things like chatbots are problematic in some cases, and for those who present outside data on their sites, like real estate agents who need to pull in listings from third party sources, you may need to use a different utility or ‘take the hit’ to your FID score in favor of continuing to ensure your website provides your users with the useful experience they are expecting.
Cumulative Layout Shift (CLS)
CLS (Cumulative Layout Shift) is a Core Web Vital that calculates the total score of all unexpected layout shifts within the viewport that occur over the course of a page’s lifecycle.
Its goal is to assess a page’s “visual stability,” which has a significant impact on the user experience. CLS can be found in both field and lab data. The better the visual stability, the lower the CLS score.
CLS, unlike most other metrics, is not measured in seconds. It takes the viewport size as a starting point, then relates to elements that move between two frames (known as unstable elements) and measures their movement in the viewport. The “impact fraction” and the “distance fraction” are the two components that make up the layout shift score.
The area of the viewport taken up by the unstable element in both frames is called the “impact fraction”. The “distance fraction” is the greatest distance traveled by the unstable element between the two frames divided by the viewport’s largest dimension (width or height)
Important factors to consider
The term “a page’s entire lifecycle” refers to when a page is open for days, if not weeks, and the CLS is measured throughout that time. Because tools only collect lab data for a short period of time, this is where CLS field data and lab data will report differences.
It can be difficult to test for unexpected layout shifts in test environments because some functionality may be disabled or work differently. Cookie notifications may be disabled, live chat support may be disabled, and personalized content may not be loaded, to name a few examples.
What does your CLS score mean?
Here’s how to figure out what your CLS score means:
- Good = Less than 0.1
- Room for improvement: 0.25 – 0.1
- Poor: Less than 0.25 %
What could be the source of a low CLS score?
Unexpected layout shifts are common as a result of undefined image or ad dimensions, asynchronously loaded resources, and situations where new DOM elements are dynamically added to a page above previously loaded content. As a result, content that has already been loaded is pushed to the side. Again, for more details I’ll refer you to the web.dev resources.
Total Blocking Time (TBT)
Total Blocking Time (TBT) is a non-Core Web Vital that measures the total time in milliseconds between First Contentful Paint (FCP) and Time To Interactive (TTI), during which the main thread is blocked for long enough to become unresponsive to user input.
TBT has a strong correlation with First Input Delay (FID), so it’s the best option for testing in a lab setting where real-world user interaction isn’t possible. TBT can be collected in the field, but it is easily influenced by user interaction, so it isn’t a reliable metric for determining how long it takes for a page to become responsive to user input. As a result, TBT is only used in laboratory data.
Any task that takes more than 50 milliseconds to complete is considered a long task, and the time beyond 50 milliseconds is referred to as “blocking time.” TBT is calculated by adding the blocking portions of all long tasks together.
First Contentful Paint
FCP (First Contentful Paint) is a non-Core Web Vital that tracks the time it takes for a page to load to any part of its content being rendered on the screen. A speedy FCP assures users that something is going on. Text, images (including background images), <svg> elements, and non-white <canvas> elements are all considered content in this context.
The lower the FCP, the better. FCP is available in both field and lab data.
You can improve your FCP score by removing render-blocking resources, removing unused CSS, minifying CSS, and using a CDN, among other things.
The subject of increasing your FCP score is worthy of its own article. I strongly advise you to check out web.dev’s resources on improving FCP scores until we write one.
Speed Index (SI)
Speed Index (SI) is a non-Core Web Vital that determines how quickly a page’s contents are visible populated during page load. It’s calculated by analyzing your page’s load behavior frame by frame and counting the visual progression between frames every 100ms.
SI can be measured in both field and lab data.
Here’s how to interpret your SI score:
- Good: less than 4.3s
- Needs improvement: between 4.3s and 5.8s
- Poor: more than 5.8s
What could be the source of a low SI score?
Anything that slows down the page’s loading time will lower your SI score. Some of the causes mentioned for the other metrics, such as the main thread being blocked, are also applicable here.
How to raise your SI score
If you concentrate on improving overall page load performance, your SI score will improve as well.
Time to Interactive (TTI)
Time to Interactive (TTI) is a non-Core Web Vital that tracks how long it takes for a page to load and become fully interactive.
It must include the following features in order to be fully interactive:
- Display content that is useful (measured by First Contentful Paint).
- Render the majority of the page’s visible elements.
- Respond to user interactions within 50 milliseconds.
While measuring TTI in the field is possible, it is not recommended because user interaction can have a significant impact on your page’s TTI. As a result, TTI should only be used in a lab data environment.
What does your TTI score mean?
Here’s how to figure out what your TTI score means:
- 3.8s is a good score.
- Needs to be improved: Between 3.9s = 7.3s
- More than 7.3s is a poor score.
What could be the source of a low TTI score?
Many of the factors that contribute to poor scores in the other metrics we discussed apply to TTI as well, because it is a metric that encompasses those other metrics. So, once again, your TTI should improve as you work through improving the other items.
Comparing Apples to Apples in Web Vitals
It’s critical to compare apples to apples when it comes to Core Web Vitals data. That is why the distinctions between field data and lab data, as well as mobile data and desktop data, must be hammered out.
Again, there are two types of data in Web Vitals: field data and lab data:
The Chrome User Experience Report (“CrUX report”) collects field data from real users, each with their own device and network connection.
Without the involvement of real users, lab data is collected in a controlled environment with predefined device and network connection settings.
It’s critical that you understand the distinction between these two types of data. Take a moment to absorb that, because it’s probably the most misunderstood aspect of Core Web Vital metrics.
You might be getting great Lighthouse (lab data) scores and high-fiving yourself, but your actual users are having a bad time (field data). Alternatively, you can have the opposite—excellent field data scores and poor lab data scores!
Then there’s the “Origin Summary,” which is based on field data and depicts the overall experience of all pages served from your site. It’s worth noting that if you have any page templates that are notoriously slow to load, this will lower your Origin Summary score, however great the rest of the pages are.
Other Considerations On Field Data
- If your pages aren’t getting enough visitors, which means there isn’t enough CrUX data, it’s possible that they won’t be available. This applies to individual URLs as well as your Origin Summary.
- Is less useful for debugging because you’ll have to wait for new CrUX data to come in after you’ve made some changes. As a result, for debugging purposes, it’s best to rely on lab data.
- Data from markets you aren’t necessarily catering to is also included. If you’re primarily targeting the United States, but you’re also getting a lot of traffic from emerging markets that don’t have the same access to fast internet and hardware, you’ll see a lot of mixed field data, simply because the audience from which your field data is collected is also very mixed.
Other Considerations On Lab Data
- Is collected by simulating a Moto G4 phone with a fast 3G connection (as of March 2021)
- Because lab data is simulated, it does not include user interaction data. As a result, First Input Delay (FID) isn’t available in labs.
- Because you control the hardware and settings, the results are repeatable (internet connection and CPU performance).
Mobile Vs. Desktop Core Vitals
When researching your Core Web Vitals scores, you’ll come across mobile data, desktop data, and a combination of the two.
In PageSpeed Insights and Google Search Console, as well as by exploring the CrUX data, you can see the field data for mobile and desktop separately. It’s common that your desktop scores will be better tham mobile at first, as a desktop computer has more powerful hardware and a more stable internet connection.
The problem here is that Google’s is now a mobile first index, so it’s the mobile Core Web Vitals scores that they will take the most notice of. When debugging and redeveloping keep that mobile experience top of mind, even though its likely you’ll be working on desktop, so any field data will derive from there.
Core Web Vitals in the Future
I’ve gone over the current state of the Core Web Vitals, but what does the future hold for them? Over the next few years, we’re likely to see a lot of changes as Google continues to tweak them. You can also expect that the values currently considered non-core will shift to the core, which is why taking as much notice of them as the Core Vitals now will save you a lot of extra debugging in the future.
The Moto G4 on a fast 3G connection currently leads in determining your page’s Core Web Vitals, but as new, more advanced phones are developed and made available, and faster internet connections become the norm, we expect Google to default to those.
Websites may also begin to consider blocking traffic from non-target markets: websites that receive a lot of traffic from non-target markets that lack access to fast hardware and internet connections may begin to consider blocking users from these markets from accessing the website, preventing a negative impact on their Core Web Vital scores.
Then there are those proposed badges. Consumers are trained to look for these kinds of things. A few years ago many had no idea why they should care if a web address was led by http or https, but now most understand that the latter is more secure, and will sometimes avoid sites without it. Over time, they may use a Web Vitals badge to save them the hassle of heading to a site that won’t offer them a good experience.
What Should You Do About Web Vitals?
The first thing you should do about Web Vitals is, and this comes from Google’s Search Liaison Danny Sullivan himself, is don’t panic. Measure your current scores – here’s a great list of resource options to choose from – and then plan on working on problems one by one. Yes, you want to get them as good as possible, but it’s unlikely to be the end of the world if you aren’t in that position by May 1st.
The second thing you should do is pay attention. Web Vitals do need to be addressed as a part of your SEO. And much of this is all very technical and frankly, overwhelming. Get help where you can, and where you need it, and remember, these are just another element of the many factors that go into great SEO, so don’t let up on paying lots of attention to all that stuff too.
Head really spinning? Get in touch with Pearl Lemon. We maintain a large and diverse SEO team who will be happy to discuss your current challenges – including Web Vitals – and what they can do to help you.
