Core Web Vitals are a set of user-related metrics. These measure speed, responsiveness and visual stability when websites are loaded. This allows website owners to measure and improve the user experience on the web.
Long gone are the days when Internet pages were loaded and displayed line by line. The vast majority of users expect an immediate response and will leave a website if it does not load properly and quickly. To improve the users’ online experience, Google released the Core Web Vitals.
Even if it often looks different, websites are loaded bit by bit. This means that forms, images and headings are visible on the screen at different times. The loading speed of each element contributes to the total loading time. In order to satisfy impatient visitors and to know the core web vitals thresholds, it is important to know how a page is performing.
Why speed and a great user experience are important
A study conducted by Google in August 2020 shows that less than 15 percent of websites would pass a Core Web Vitals test. Google has long tried to increase page speed through Pagespeed Insights and Acelerated Mobile Pages (AMP). Just increasing the page speed led to search engine optimization. By using Core Web Vitals, the websites are now really involved in SEO.
Owners who know their site’s metrics can start adding value and delivering a pleasant experience to potential customers. The Google bots reward good core web vitals with a high ranking. According to Google, the Core Web Vitals will affect the page ranking from May 2021.
The three key figures of the Core Web Vitals
The Core Web Vitals are three metrics with which the so-called core experience can be measured. The core experience tells whether a website feels fast or slow to users when loading, and thus offers a good or bad experience. These metrics are Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift.
Largest Contentful Paint (LCP)
Largest Contentful Paint is probably the easiest measure to understand. LCP measures how quickly users get the largest item displayed on the page. This is likely the content that the user is particularly interested in. This can be a banner image, a piece of text, or some other element. The fact that this element is the largest amount of content on the page is a good indicator that it is the most important element. LCP is relatively new. Previously, First Contentful Paint (FCP) measured a similar metric. LCP is now believed to be better suited to determining when the content of page elements is fully displayed on the screen that the visitor is likely to want to see.
LCP measures the charging power and is a good replacement for all old metrics that were previously used for this. The time is measured from the appearance of the first byte on the screen until the element is fully displayed. This metric does not cover all the information available, but tries to give a good indication of the page load from the user’s point of view.
Google recommends that the LCP of a website be kept under 2.5 seconds for 75% of page loads.
The LCP thresholds:
- <2.5 seconds = good
- 2.5 seconds to 4 seconds = improvement needed
- > 4 seconds = bad
So the first step is to write down the most suitable LCP candidates for each page type. In the case of a blog post, for example, this can be the elements H1, the cover picture and the first paragraph of the article. In the case of a product detail page, this can be the product picture, the name and the price. Website optimizers can set up a table with all the page types of the LCP candidates.
The second step is to prioritize the elements of the LCP candidates. The aim is to display them as quickly as possible.
What Could Cause a Bad LCP Score?
There can be a variety of causes for a poor LCP score. This could be, for example, slow server response times, render-blocking JavaScript and CSS. Or insufficient content resources because the large items take a long time to load.
Examining the initial server response times is a good way to determine if there are any fundamental infrastructure issues that can affect the LCP results. If the server response time is slow, there may be a problem with the infrastructure. This may be remedied by updating the infrastructure, the firewall or the DNS.
First input delay (FID)
Another element within the Core Web Vitals metrics is the input delay, called First Input Delay (FID) by Google. It measures how much time a page needs to be interactive. In other words, when a user clicks a button or a JavaScript element, for example, how much time does the browser take before it begins to process the input and return a result.
For users, it is not a good experience if they click something and nothing happens, or if the response is excruciatingly slow. This response time is what FID measures. For example, the time may depend on third-party JavaScript code. There are different ways to investigate and fix this.
Google recommends that websites keep the FID under 100 milliseconds for 75% of page loads.
The FID thresholds:
- up to 100 ms = good
- 100 ms to 300 ms = improvement needed
- > 300 ms = bad
FID does not measure the time it takes for the browser to process an event, nor the time it takes to refresh the user interface afterwards.
Interactions such as scrolling and zooming are also not counted as countable actions because they are continuous in nature and have very different performance limitations. Image functions are also performed by the GPU, not the CPU.
What Could Cause a Bad FID Score?
A common reason for a bad FID value is the main thread of a browser, for example when it is busy opening a new tab or analyzing and executing JavaScript code. When the main thread is busy, it cannot yet respond to user interaction.
Improving a bad FID score
Before an FID score can be improved, it should be carefully examined what is preventing the browser from becoming interactive. Examples of measures to improve your FID value are:
- Reduced JavaScript execution
- Minimizing the work done in the main thread
- Reduction of third party code impact
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) is what Google calls a central web core Vital. This metric measures the cumulative score of any unexpected layout shifts within the viewport that occur throughout a page’s life cycle.
According to gradinmath, CLS is rated from zero (no shift) to a positive number (frequent shift). Screen shifts are caused by drop-down banner ads, buttons displayed, or images that cause a block of text to move. All of these contribute to a negative user experience, which is why it is important to reduce the drifts on a webpage.
Google recommends aiming for a CLS value of 0.1 or less for websites.
The CLS thresholds:
- up to 0.1 = good
- 0.1 to 0.25 = improvement needed
- > 0.25 = bad
After analyzing millions of web pages, Google found that users were 24 percent less likely to abandon page loading if a website had the above-mentioned deflagration. The aim is to measure the “visual stability” of a page as this greatly affects the user experience. The lower the CLS value, the better the visual stability.
Correct checking of unexpected layout shifts can prove to be difficult, especially in test environments, as some functions there may be deactivated or function differently. Some examples: cookie notifications may not be displayed, live chat support may be disabled, and personalized content may not be loaded.
Measurement of the core web vitals
Pages that are rated “good” with regard to the Core Web Vitals achieve a desired user experience and can improve the page experience component of the ranking, provided other components are also okay.
Core Web Vitals are based on field metrics or Real User Metrics (RUM), which are made available by Google from anonymized data of Chrome users in the Chrome User Experience Report (CrUX). This data is used to measure the three metrics for the search rankings. CrUX data is available in a number of tools, including the Google Search Console.
These developer tools are available for measuring core web vitals:
- PageSpeed Insights
- Google Search Console
- Chrome UX Report
- Lighthouse
- Web Vitals Extension
- Chrome DevTools
It is important to use RUM data when measuring Core Web Vitals. Laboratory-based tools such as Lighthouse simulate the page loading processes in different networks and devices. However, these results may not reflect what the user experience of a real website corresponds to.
The measurement of LCP depends very much on the network conditions, network utilization and the processing power of the devices used. At least some smartphones work in energy-saving mode, so that the synthetic lighthouse data is usually a bit more optimistic than in practice.
Similarly, the FID often depends on the processor speed and how the device can handle content such as images, layout and JavaScript elements.
In theory, CLS is easier to measure with tools because it is less prone to network and hardware variations. Nevertheless, the charging processes simulated in the laboratory often show a CLS value that is too low.
Different ratings for desktop and mobile
All performance data contained in CrUX comes from real-life conditions and has been aggregated by Chrome users who have chosen to sync their browsing history and who have usage statistics reporting enabled. CrUX data is divided into mobile, desktop and tablet, although in most tools it is only available for mobile and desktop. The Core Web Vitals are always determined separately for mobile and desktop. Therefore, there may be differences in the ratings.
The same website can have different values from the smartphone to the desktop. When optimizing a particular website, different content areas must therefore be taken into account.
Core Web Vitals as a Ranking Factor and the Effects on SEO
For both desktop and mobile devices, the Core Web Vitals will affect the search results. In practice, however, the search engine ranking consists of over two hundred metrics. The effect of a certain metric on the ranking is therefore not that great. However, if a website has weaknesses in some metrics, bad core web vitals can make all the difference.
The other fact to consider is that some Google metrics are oversized beyond their actual ranking factors. Things like page speed are likely to cause a pretty small ranking signal, but when users experience bad times loading a page, it can have an overwhelming impact on their behavior. Google’s own studies show that visitors to pages that meet the thresholds for Core Web Vitals are 24 percent less likely to leave the website.
Even if Core Web Vitals is not an official Google ranking factor, these factors are still important as they enable a better user experience. However, it is not known how much these factors affect the ranking. In view of the fact that Google already has some criteria that measure the page experience, the impact on the ranking should be limited.
