Core Web Vitals for Beginners: What are They and Why are They Important?

In November 2020, Google announced that starting this year in mid-June, the Page Experience ranking would go live. This means that Google will now apply core web vitals metrics to determine search ranking. In simpler words, Google will consider users’ experience to rank websites. 

All website owners should be aware of this Web Vitals Initiative to provide the quality signals that represent an optimal web user experience. 

There are tons of tools out there that help measure a site’s performance. While these technicalities come as second nature to some, most find it challenging. But site owners do not need to be web experts to understand the quality of experience they are providing their users.

Google created this initiative to simplify the process and focus on the metrics that matter the most. These Core Web Vitals are the focus of this article, but first, let’s briefly discuss how vital a page’s performance is. 

Why is Page Performance important?

Page performance refers to how fast a webpage downloads and displays on a web browser. We have mentioned before how a poor experience will doom a webpage to oblivion. 

The reason?

Two words: bounce rate. 

Bounce rate is the percentage of visitors that enter a website and move on to the next after viewing only one page. No clicking anywhere. No interactivity. 

If your bounce rate is unusually high for your home page, Google will consider that you are not offering a great experience to users. 

According to Google, if page load time goes from 1 to 3 seconds, the bounce rate increases 32%, and if page load time increases from 1 to 6 seconds, bounce rate goes up by 106%.  

Core Web Vitals

There are several web vitals that you should be looking at to optimize a site’s performance. Core Web Vitals are the three most important of these field metrics, and they each represent a different aspect of the user experience. It is important to note that these metrics are not static, but they evolve over time. Since 2020, the focus of these vitals are:

• Loading
• Interactivity
• Visual stability

Summary Table of Core Web Vitals and their Thresholds

LCP (Largest Contentful Paint)

The Largest Contentful Paint metric measures visual loading performance, determined by the time it takes for the largest text block or image to show up in the viewport since the instant the page started loading. 

The LCP of a webpage is the largest element visible in the viewport. The viewport refers to the area of the webpage that the user can view at first glance without scrolling. An LCP, for instance, could be the large featured image, a background image, the h1 tag, or even a portion of the content. 

For example, on our website, the LCP is the <h1 tag> We are Shopify & Mobile App Experts.

An optimal LPC loading time is less than 2.5 s. Anything between 2.5 and 4.0 seconds is not that bad altogether, but Google recommends working on improvements. A loading time >4.0 seconds is considered poor. 

Measuring your website’s LCP can quickly be done through specialized tools that we will cover later in this article. Our focus at the moment right now is what LCP (and the other metrics) is and what makes it have a poor performance. 

Optimization

Google lists four factors that primarily affect LCP:

• Slow server response times
• Render-blocking JavaScript and CSS
• Slow resource load times
• Client-side rendering

We will not be going into the specifics on all the technical specs to fix these issues, as that is not the scope of this article. But in we can mention some basic page speed optimizations that can help reduce slow LCP:

• Cache your content 
• Have good hosting
• Optimize your images
• Set up a CDN

If you have other issues such as rendering blocking CSS or JS, things get more technical, but that is not a match for your heroes at Contra Collective.

FID

This field metric measures interactivity, determined by when a user clicks on an interactive feature to when the browser responds to that interaction. This metric aims to understand a user’s impression of a site’s interactivity and responsiveness. Some examples of interactions are:

• Clicking on a link or button
• Selecting a drop-down menu
• Inputting text into a white field

Whenever your visitors come to your site, and there is a clickable option, they expect to see a fast response when they take action. Very few things are more annoying than clicking on a menu button and getting a slow response or no response at all. 

Google recommends an optimal FID time of under 100 ms. If whenever a user clicks on a button or interactive, and the response takes more than 300 ms, performance is considered poor. Yes, people need an immediate response from the stuff they click on. 

We have found that the most common cause of a slow FID is heavy Javascript execution. So, when the browser tries to respond to the user’s request, it cannot do so as fast because it is busy doing something else.   

Optimization

Some of the steps that you can take to help optimize FID include:

• Use a browser’s cache
• Use a web worker
• Break up long tasks into smaller bits
• Minimize JavaScript or reduce execution time
• Optimize webpage for interaction readiness

CLS

Cumulative Layout Shift is how stable a page is as it loads. For example, have you ever been to a site, and just when you were about to click on something, it moves to the bottom, making you accidentally click on something else?

CLS looks at how much content has shifted in the viewport and the distance these effective elements moved.

It is easy to tell that having a high CLS is not good, as this means that elements are moving around as the page loads, providing a poor experience for the user. 

You want your page to stay stable as it loads so that your visitors do not have to move around looking for a moving element. 

This implementation of this metric received an update in June this year, and now it only considers the shifting during the first five seconds of a webpage load time. 

Google has created a threshold for this metric, assigning a score of less than 0.1 to optimal performance. A score between 0.1 and 0.25 needs improvement, and, of course, anything beyond 2.5 is considered poor.  

Optimization

The most common causes of CLS are:

• Ads, iframe, and embeds with no dimensions
• Images without dimensions
• Fonts or styles applied too late to the code
• Dynamic content

Fixing these issues is relatively easy and can be done in little time. In the case of photos and videos, you just need to add dimension attributes to use CSS aspect ratio boxes. In the case of ads, iframes, and embeds, you can create static elements to allow space for them.   

Types of Data for Metrics Gathering

You have been reading in this post about “field data,” and we should clear that out for you to better understand how these data affect core web vitals metrics. 

Field data

This data refers to the actual user experience and is generated from the Chrome User Experience Report (CrUX). In essence, Google uses information generated from Chrome users who opted in to share info such as browsing history. 

With this data, they obtain the three core web vitals and their corresponding threshold. This is the best approximation you can get on who Chrome users experience the web. To access this information, you just need to go to your Google Search Console.    

The biggest con of field data is that it has a rolling cycle of 28 days. This means that if you make any change on your website today, the full impact of this change on your vitals will only be visible on Google Console after an average of 28 days.

One important thing to know about field data is that the metrics are assessed at the 75th percentile of users. Therefore, for a page to pass the Core Web Vitals assessment, all of the metrics of these vitals must be at least 75% of good loads. If one or more have a percent less than that, then the page fails the assessment. 

On the first illustration below, note how all the metrics for the Core Web Vitals are above 75%, therefore passing the assessment.

This second illustration shows a page that does not pass the Core Web Vitals assessment. 

Lab data testing

That 28-day waiting period might seem long, especially if you need to have a good appreciation of what your site is looking like today. Here’s where lab data comes in handy. 

Lab data is generated by tools designed to run consistently under the same conditions. However, this data does not take into account users’ circumstances like equipment and internet speeds. Besides, bots are not going to interact with your website the organic way real users will. 

PageSpeed Insights provides the values for lab data: 

You can also get that information from the Lighthouse Chrome Extension and in Chrome Web Tools. 

Tools to Measure Core Web Vitals

Lighthouse

This auditing tool is used to diagnose issues and take advantage of opportunities to improve user experience. You can download it as a Google Chrome extension and simply run the extension for the site you want to analyze. 

Lighthouse CI provides other features to enable a more granular analysis of your site’s performance health regarding the Core Web Vitals. 

PageSpeed Insight (PSI)

This tool gives an exhaustive report of both mobile and desktop performance. In addition, PageSpeed Insights provides details on field and lab performance. The Chrome UX Report powers this data from real-world users, and the Lighthouse extension offers recommendations on improving page experience. 

This service provides a great overview of all your pages in need of attention. 

CrUX

The Chrome Users Experience is a set of field data that measures all the Core Web Vitals. As mentioned before, this data comes from Chrome users who have opted to share their browsing experience with Google. 

This is valuable information since the best way to assess how you perform, even with respect to your competitors, is with real-world data from users downloading your site and interacting with it. This real-time information is also known as Real User Monitoring (RUM).

To access the CrUX Report API, you need to have some general knowledge of web development and command line interfaces. You will also need to create a project to get an API key.

Other Web Vitals

The Core Web Vitals are the most crucial metrics to help deliver a greater user experience. But there are other web metrics that you should also consider if you intend to provide your users the best experience possible. We will just briefly mention and describe each. 

TTFB 

The Time to First Byte, as the name indicates, refers to the time it takes for the browser to receive the first byte of data. The Opportunities Section of your Lighthouse reports includes this metric. 

If your page’s performance is more than 600 ms, the audit will fail this metric. As you already know, a page that takes too long to load displeases users. 

FCP

The First Contentful Paint metric measures the time for the first piece of content to load. 

FCP and the Time to First Byte are helpful metrics in determining issues with LCP since they both are crucial to the loading experience. Just as TTFB has to do with slow server response times, FCP has to do with render-blocking resources.  

A good score for this web vital is less than 1.8 seconds or less. If FCP takes more than 3 seconds to load, it is considered poor performance, and you should be taking action. 

FCP can be measured using all the tools described on the field and in the lab. In your Lighthouse reports, you can filter out opportunities to improve FCP. 

TBT

Total Blocking Time is a lab metric that measures the time between the First Contentful Paint and the Time to Interactive in the event of a main thread block. This “blocking” happens whenever there is a long task (one running for more than 50 milliseconds).

Let’s say that a user loads your website but then wants to interact with a feature and click on it. If there’s a long task still taking place, the main thread is blocked and prevents input responsiveness-the browser cannot interrupt an active task. The user will perceive this delay and take the page as being sluggish. 

To measure TBT, you can perform a Lighthouse audit on your site. 

TTI

Time to Interactive is the time from when the page starts to load to when the users can actively interact with it. On average, a good TTI must be less than 5 seconds when tested on a mobile device. 

TTI measures how long it takes for a webpage to become available for the user to interact. 

Lighthouse displays the Time to Interactive in its Performance section. 

Other Page experience metrics for search ranking

Web Vitals affect the Page Experience-signals that measure how users perceive a webpage and how positively they interact with it. 

But Page Experience does not only involve Web Vitals. There are other signals that you must look into to keep the experience pleasant. Google mentions the following experience metrics that help improve the user experience. 

• Mobile-friendly
• Safe-browsing
• HTTPS
• No intrusive interstitials (those pop-ups or sliding banners that block the content)

Outcomes of a Good Page Experience

When a site meets the optimal threshold for Core Web Vitals, Google found out that users are 24% less likely to abandon a page while it loads. If your site has been optimized, users will not have time to leave as all the content has been painted in a short time. 

Google also found a 22% less abandonment rate for news sites and 24% less for shopping sites. 

Important Final Notes

The Web Vitals initiative has only started, and it is not possible to know just yet what its full impact will be on how your site performs. However, it is always a good idea to improve those aspects in the measure of the possible. 

Will all this affect your SEO? Will you be penalized if you do not implement the suggested optimizations? It is not easy to tell. Google will still prioritize content over looks, but there are instances in which page experience may override having great content. 

As John Mueller so eloquently stated, “Quality content still comes first. Page experience becomes more important when there are multiple similar results.”

Not all developers have the prowess to tap into all these optimizations effectively, lab testing might become cumbersome, and field results will take time to show. 

Here at Contra Collective, we have what it takes to take your site to the next level. We can’t wait to get your site running for the best user experience possible. So get in touch and let’s talk.