Table of contents

Czytasz teraz:

Core Web Vitals – What Are They and Why Are They Important?

• Core Web Vitals – Quality Over Quantity
  • Website Quality Factors
• Core Web Vitals – let’s have a look!
  • About PageSpeed Insights
• Three Core Web Vitals metrics
• Core Web Vital: LCP – Largest Contentful Paint
  • Largest Contentful Paint – score
  • Poor LCP Score – How to improve?
  • Slow server response
  • JavaScript and CSS rendering blocking
• Core Web Vitals: FID – First Input Delay
  • First Input Delay – score
  • Poor FID score – how to improve it?
• Core Web Vitals: CLS – Cumulative Layout Shift
  • Cumulative Layout Shift – score
  • Poor CLS score – how to improve it?
• Core Web Vitals – UX matters!

Close

The internet is constantly evolving. There’s no doubt – websites from “ancient” digital times are hardly similar to those that we visit today. Modern websites have different layouts and present the data in different ways, mostly because users’ needs and habits have vastly changed over the years.

The differences also include the way the website is perceived – today it is not enough that it simply IS. In this context, site owners need to consider what Core Web Vitals are and what we need from them. Or what Core Web Vitals need from us to improve the website’s search result ranking.

Core Web Vitals – Quality Over Quantity

Google has been putting a great emphasis on the page speed and visual stability for a long time – in fact, for years. One of the first signs of these changes was certainly the step towards mobile users (also known as “Mobilegeddon”), which in 2015 electrified SEO specialists and web developers. The next one was focused on the need to ensure the security of the website and its users. Now it is turning towards the user experience.

In May 2021 the quality of the site became the official part of the Google algorithm, and, consequently, one of the factors that influence website position in Google search results. According to official Google statements, the site quality is not more important than the published content but is still a major aspect. It means that the page experience ranking factor has to be taken into consideration while developing or updating the website.

(You will find the rest of the article below the form)

Website Quality Factors

Website quality is analyzed in terms of several factors:

• Mobile-friendliness (mobile-first indexing from March 2021)
• browsing safety – no harmful and misleading content, i.e. malware and phishing elements;
• HTTPS in URL address (you can read more about safe browsing in the article about TLS/SSL certificate);
• no full-screen ads that prevent access to site content.

Core Web Vitals can be described as indicators that are designed to gauge the user experience when it comes to page loading, visual stability, and availability during and after rendering.

Google underlines that site quality research bound to Core Web Vitals will be continued – we can be sure the list of important factors will be extended in the next few years. Of course, such info will be published in advance, giving web developers enough time to prepare websites for the upcoming Google page experience update.

Core Web Vitals – let’s have a look!

One of the most controversial topics related to SEO is page speed. So many times we were the witnesses of long, intense discussions regarding how a high PageSpeed Insights score and speed metrics, in general, improve the rank in SERPs (Search Engine Results Pages). 

The truth is a high GPI score is not directly bound to search engine rankings. It is known, however, that a website that has no problems with displaying its content correctly even with a slower internet connection, will be appreciated by users. This, in turn, will increase the average length of the visit, the willingness to share a link, and the chance to achieve a high conversion rate. Tools that analyze page loading speed check specific elements of the site, but do not provide full information on the user’s page experience. Their analysis is necessary, but it focuses on aspects other than Core Web Vitals.

Core Web Vitals represents a distinct facet of the user experience – or at least CWV try to define the website’s overall user experience. The data that determines site quality is collected based on users and their visits to the website. Thanks to real user monitoring, the site is examined on a wide range of data – different network connections, screen sizes, and technologies used in devices. Therefore, there is enough data to analyze how the users interact with the website.

About PageSpeed Insights

PageSpeed Insights is one of the Google tools that reports on the performance of a website (including mobile and desktop devices) and suggests improvements to the website. This Google tool provides types of data: lab data and field data. Lab data are collected in a controlled environment with the predefined device and network settings. Field data are collected from real users visiting a website.

Three Core Web Vitals metrics

When it comes to measuring Core Web Vitals, there are three core web vitals:

• Largest Contentful Paint – LPC
• First Input Delay – FID
• Cumulative Layouts Shift – CLS

Let’s have a look at all of them.

Core Web Vital: LCP – Largest Contentful Paint

LCP checks the time needed to render the largest element of the web page visible in the browser window (in short, everything we see before starting scrolling). The elements that are taken into account are:

• images,
• videos,
• an element containing background graphics downloaded using the “url (…)” function in CSS,
• block elements (e.g. <p>, <div>, <ul>, <ol>, <hx>, etc.).

Content in individual tags that extends below the scroll line is not taken into account in the analysis. In the case of images, the analysis is based on the smallest size achieved by the element. If the image after rendering is smaller than the values specified in the tag during rendering, its rendered size will be crucial for the analysis. When the graphic is stretched, the size of the sample taken for testing will depend on the values specified in CSS.

How does the tool know which item is the largest? Web pages render in steps, and the HTML code is read in sequence – from the first line to the last. Therefore, as your site renders, the object marked “largest” will change. A given fragment of the web page is defined as the “largest rendering of the content” only when it is fully loaded. Note – If the user scrolls the screen while rendering the web page, further changes to “largest contentful paint” will not be taken into account.

What about items that are loaded off-screen and only later appear in the view? In most cases, these snippets will not be reported. In the opposite situation – when they render within the viewport and are pushed below the scroll line, they will still be taken into account and may be included in the final result.

The image above shows the limit of the optimal LCP result – 2.5 seconds from the start of site rendering. Above this time – up to the 4-second limit, the result is considered “requires work” and over 4 seconds – simply poor.

Largest Contentful Paint – score

In PageSpeed Insights LCP scores are shown in two ways:

• percentage, collected on the basis of data collected from users over the last 28 days. In 39% of the percentages, the LCP data was at a satisfactory level:

• in seconds, based on the research performed during the page load simulation:

PageSpeed Insights analyzes only data related to the given URL address. For more detailed information on web pages within the entire domain, you have to check out the Google Search Console’s newest tabs labeled Core Web Vitals. In the Google tool, there are two reports available on the page displayed on mobile devices and on computers.

The Core Web Vitals report in GSC lists the web pages where there is a problem with poor LCP results. If the Google tool has identified the same problem on many subpages – the table contains one address and an annotation about the number of pages on which the error repeats. The exact URL addresses are available in the extended view, available after clicking on the record.

Poor LCP Score – How to improve?

The key to achieving a good LCP score is the optimization of crucial points that slow down the page performance. A slow server, the need to execute JS and CSS code that blocks further site rendering, and client-side rendering – these are the most common causes of poor results. Let’s take a look at a remedy for the most common problems:

Slow server response

The key value here is TTFB – Time To First Byte (time from sending the query to receiving the first byte of the response). Slow response is reported in PageSpeed Insights, it can also be checked with other site speed analysis tools.

The primary way to improve the TTFB score is to optimize the server and eliminate processes that decrease its performance. For this purpose, it is worth looking at the advice of your hosting provider or using the help of a specialist;

JavaScript and CSS rendering blocking

The tricks that are recommended for every site speed optimization will be much of help – CSS minification, inline critical CSS, implementing lazy loading, removing unused fragments, and considering asynchronous loading of style files. In terms of JavaSript, the optimization will be similar – minification of files and removing unused JavaScript code fragments;

Optimization of other elements, e.g. image compression, use of CDN (Content Delivery Network), and prioritization of loading certain resources, may also contribute to the improvement of the LCP score.

Core Web Vitals: FID – First Input Delay

First input delay measures the site – user interaction – it defines the time between the first action performed by the user and the moment when the browser’s engine starts executing this action. Clicks (in the case of mobile – taps) and button presses are taken into account. The FID score focuses on the analysis of the response time but does not examine the processing time of a user-initiated event.

The lag on the first action will not always be measured – some users choose not to interact with the web page while loading. In the case of this indicator, the analysis is conducted only during the actual use of the website.

You’ve surely had a situation when after entering the website you wanted to immediately click on an interactive element, but at first, it was inactive. Why do such delays happen? While the site is rendering, the user’s browser is busy handling the files that make up the page. Only after completing this process, the browser is able to react to user input. The waiting time can be subjectively described by the user as “slow” or “fast”.

Earlier in the article, in the part about LCP, I mentioned that HTML code is loaded line by line – why is it not possible for the loaded fragments to be active earlier? Some tags – such as <input>, <a> or <select>, require rendering of the main thread to be finished. As for the other obstacles – the <head> section of the .html file usually contains links to CSS and JS resources. The user’s browser must parse them before continuing to render the page. That’s why such files should be minified (i.e. whitespace removed) and fragments unnecessary for rendering the first view should be moved to the rest of the code. In the case of events that are registered by “event detectors” placed in the JS, their operation is possible only after all the code has been executed.

First Input Delay – score

As mentioned in the image below, a satisfying score in this core web vitals metric ranges from 0 to 100 ms. If the result extends this time, it is worth introducing corrections, and above 300 ms – you simply have to.

The data from PageSpeed Insight are collected from user input – in this case, 82% of cases are described as satisfying.

You can find more detailed data with specific URL addresses that need improvement in Google Search Console.

Poor FID score – how to improve it?

In a perfect world, tools would return 95-99% of “green results”. If your current scores are not that high, the site should be improved. First of all – as in the case of the aforementioned  LCP –  it is recommended to optimize the code that is necessary to load the key elements of the website and move the fragments with a lower priority to the rest of the file. It is also worth minifying the code and removing unused fragments.

The main villain here is JavaScript code. Optimizing JS files and breaking down individual fragments into smaller, asynchronously executed parts should significantly speed up the rendering process and reduce resource blocking. The other factor that can affect the time of the browser response can be the code coming from outside the page – limiting it will reduce the number of processes performed by the browser.

Core Web Vitals: CLS – Cumulative Layout Shift

In a nutshell, CLS can be defined as an indicator of visual stability of the website. The Cumulative Layout shift (CLS) score is the sum of the changes performed due to an unexpected page layout shift. Such changes happen when the individual element changes its position in comparison to its location while rendering. CLS does not include new elements that appear on the page and elements that change their dimensions – as long as such shifts do not affect the positions of other website elements. The mechanics of CLS is slightly different – contrary to the indicators listed above, CLS collects data during the entire visit to the page, not just in the first seconds of rendering.

Shifts in the page layout are created mostly by asynchronous loading resources or by dynamically adding elements to the DOM structure. Such situations are noticeable, for example, when using pages with images without a declared size – matching image size to the page size may cause large layout shifts.

Resources downloaded from external sites can also cause similar issues, if they are built on another basis than the target page. Unexpected shifts can also be caused by extended font rendering.

What is important – not every shift is detrimental. Depending on the page design, some user actions will cause changes in relation to the original order of elements. It is important, though, that this type of shift should be directly related to the action performed by the user.

CLS is based on data collected from user’s input and allows you to determine the actual users’ page experience. As a website developer, you can omit something or simply not take it into consideration at the development stage. CLS will surely find such issues.

Cumulative Layout Shift – score

A decent CLS score oscillates between 0-0.1. If the page experience scores are higher than 0.25, you should definitely introduce some changes in order to improve the users’ page experience. In general, the website is considered stable if at least 75% of users get a score below 0.1.

The data about Cumulative Layout Shift can be found in PageSpeed Insights:

The percentage score is based on an analysis of user data – in this case, 90% get a satisfying score.

The PSI tool provides also information collected under laboratory conditions:

More detailed information on specific subpages can be obtained from Google Search Console.

Poor CLS score – how to improve it?

The cumulative Layout Shift (CLS) score can be improved by following good practices of web development. The most important aspect here is adding attributes related to the size of images and videos: width, height, and aspect ratio. It makes it easier for the browser to properly arrange elements during rendering, without the need for changing subsequent fragments of existing content. In the case of images added dynamically, it is recommended to use placeholders that reserve space for the element added later.

Recently PageSpeed Insights has been recommending the use of css font-display descriptor, which is responsible for keeping the font on the page. Another possibility is to load the font in advance with the help of a preload attribute inside the <link> element. Preload pushes the selected resources to be downloaded before rendering the page. With such mechanics, in the further part of the page display, the problem of downtime and waiting for all files from the first part of the loading queue is eliminated.

Core Web Vitals – UX matters!

Are Core Web Vitals important? Core Web Vitals metrics are considered a revolution for site owners, but in fact… it is hardly a massive change. Many core metrics were already recommended by Google in the first versions of PageSpeed Insights. However, indicators and their official debut in the search engine algorithm are a good reason to take a closer look at your websites and make important changes. This affects both online positioning and positions in search engines, as well as the comfort of using the website by users.

Now you have gained proper knowledge about Core Web Vitals and supplemental metrics. To all the site owners – analyze your website, identify opportunities to improve, implement, and enjoy more traffic in Google Analytics!