The internet is constantly changing. Websites from its early days barely resemble those we see today. Not only has their appearance and the way they present information changed, but so have our expectations. Among the differences is the way a website is evaluated – today, it's no longer enough that it simply IS. In this context, we need to consider what Core Web Vitals are and what they actually tell us.
Core Web Vitals – website quality comes first
Google has long placed a strong emphasis on the speed and readability of presented content. One of the first elements of this change was undoubtedly the shift toward mobile users (also known as "Mobilegeddon"), which electrified SEO experts and website developers in 2015. Other changes include the need to ensure the security of the website and its users, as well as SSL. Now, it's turning to user experience.
In May 2021, page quality will become part of Google's algorithm and will influence a site's ranking in the search engine. According to official sources, page quality will not outweigh content, but it will promote sites that deliver content in a way that's tailored to user needs.
The quality of a website will be analyzed based on several factors mentioned above:
(The rest of the article can be found below the form)
- adaptation to mobile devices (mobile-first indexing for all pages from March 2021);
- browsing security – no harmful or misleading content, i.e. malware or elements allowing information theft;
- HTTPS;
- no interstitial ads that prevent access to website content.
There are also Core Web Vitals, also known as Basic Internet Vitals. These metrics are intended to help measure user experience in terms of page loading and accessibility during and after rendering.
Google emphasizes that work on the method for measuring website quality will continue. In the coming years, the list of factors taken into account will undoubtedly change and be expanded with additional items. We will be informed of any changes in advance, and the search engine will also give us time to adapt our sites to the new requirements.
Basic Internet Metrics – Let's take a closer look
One of the most controversial SEO topics is website speed. In specialized groups, we've witnessed lengthy discussions about how a high PageSpeed Insights score improves a website's ranking. It's true that a website's rating in the tool doesn't directly translate to search engine ranking . However, it's clear that a website that displays content correctly even with a slower internet connection will be more favorably received by users. This, in turn, will translate into longer visits, greater willingness to share links, and a higher chance of achieving the conversion rate we've set.
The research conducted by the tools I mentioned in the article about page speed examines specific website elements, but it doesn't provide comprehensive information about the user experience. While their analysis is necessary, it focuses on aspects of the website other than Core Web Vitals.
Core Web Vitals allow us to determine the experience our website users have. Data used to determine website quality is collected based on actual website visits. This allows us to examine website performance across a broad range of scenarios, including varying network connection speeds, device sizes, and technological capabilities.
The current version of Core Web Vitals focuses on three elements:
- the largest content rendering,
- delay on first action,
- collective system shift.
As I mentioned earlier, Google plans to expand its website quality analysis, and we can expect this list to expand in the coming years. Google also hasn't ruled out modifying current metrics, for example, expanding the scope of the research.
LCP – Largest Contentful Paint – Largest Content Render
LCP determines the rendering time of the largest portion of the page visible in the browser window (everything we see before scrolling). The elements taken into account are:
- graphics,
- video,
- an element containing a background graphic, downloaded using the url(…) function in CSS,
- block elements (e.g. , , , , , etc.).
If the content of individual tags extends below the scroll bar, these fragments are not considered during analysis. For images, the analysis is based on the smallest size the element can reach. If the image is scaled down during rendering relative to the values specified in the tag, its rendered size will be crucial for the analysis. When the image is stretched, the sample size taken for testing will depend on the values specified in the CSS.
How do you know which element is the largest? Web pages render in stages, and the HTML code is read in order – from the first line to the last. Therefore, as the website renders, the object marked as "largest" will change. A given section of the page is only considered the "largest content render" once it has fully loaded. Note – if the user scrolls the screen while the page is rendering, further changes to the "largest contentful paint" will not be taken into account.
What about elements that load off-screen and only later appear in the user's view? In most cases, these fragments won't be reported. Conversely, if they render within the viewport and are pushed below the scroll bar, they will still be considered and may be included in the final output.
Largest Content Rendering – Result
The graphic above shows the optimal LCP score at 2,5 seconds from the start of the website rendering. Anything above this time, up to 4 seconds, is considered "needs work," and anything above 4 seconds is considered poor.
In PageSpeed Insight, values are provided in two ways:
- in percentage, based on data collected from users over the last 28 days. In 39% of cases, LCP was at a satisfactory level:
- in seconds, based on tests conducted during page loading simulation:
Below is also information regarding which item was considered the “largest”:
PageSpeed Insights analyzes data for a given address. For more detailed information about pages across an entire domain, it's worth checking out Google Search Console and one of the newest tabs, "Core Web Vitals." Two reports are available there, one for mobile and one for desktop. 
The GSC report contains a list of pages experiencing poor LCP performance. If the tool identifies the same issue on multiple pages, the table lists a single address and notes the number of pages with the error. The exact addresses are available in an expanded view, accessible by clicking on the record.
Poor LCP score – effective ways to improve
The key to a good LCP score is optimizing the areas that slow down your website. A slow server, the need to execute JS and CSS code that blocks further rendering of the site, and client-side rendering, which I discussed in more detail in my article " Website SEO and JavaScript ," are the most common causes of poor results. Let's take a look at solutions to the most common problems:
- Slow server response – the key value here is TTFB – Time To First Byte (the time from sending the request to receiving the first byte of the response). Slow response is reported in PageSpeed Insights, among others, and can also be checked using other website speed analysis tools.
The primary way to improve your TTFB score is to optimize your server and eliminate processes that degrade its performance. For this, it's worth considering the advice of your hosting provider or seeking professional help;
- Blocking rendering with JavaScript and CSS – tricks recommended for any website speed optimization will work here – minifying CSS, removing unused fragments, and considering asynchronous loading of style files. In terms of JavaScript, optimization will be similar – minifying JS files and removing unused fragments;
Optimizing other elements, such as image compression, using CDNs, and prioritizing the loading of certain resources, can also improve the LCP score.
FID – First Input Delay – Delay on first action
FID refers to a website's interactivity—it measures the time between the first action performed by a user and the moment the browser begins processing that action. Clicks (or taps on mobile) and button presses are taken into account. The FID score focuses on response time analysis, but does not measure the processing time of an event initiated by the user.
First-click latency won't always be measured – some users choose not to interact with the page while it's loading. Interestingly, this metric is analyzed only during actual page usage – similar tests aren't performed during Lighthouse's simulation.
Every internet user has surely encountered the experience of immediately wanting to navigate to the next section after entering a website. However, clicking a link or expanding further text wasn't possible immediately – the website's response to our movement was significantly delayed. Why does this happen? While the website is rendering, the browser is busy handling the files that make up the page. Only after this process is complete is it able to respond to user behavior. The wait time for a page to become interactive directly translates into a subjective user rating of the page as "slow" or "fast."
When describing LCP, I mentioned that HTML loads line by line – so why isn't it possible to make loaded fragments active earlier? Some tags – e.g. , or whether they require the main thread to be closed for rendering. As for other obstacles, the .html file section typically contains links to CSS and JS resources, which the browser must parse before continuing with page rendering. Hence, the earlier suggestions for minifying these files (i.e., removing whitespace) and moving fragments unnecessary for rendering the first view to the next section of the code. In the case of events registered by "event listeners" placed in JS, their execution is only possible after the entire code has been executed.
Delay on first action - result
As indicated in the graphic above, a satisfactory result falls within the range of 0-100ms. Anything above this time is worth making adjustments, and anything above 300ms is necessary.
PageSpeed Insight information is based on user data – in this case, 82% of cases achieve satisfactory results.
More detailed data, including information about specific addresses requiring improvement, is included in the “Core Web Vitals” tab in Google Search Console.
Poor FID result – effective ways to improve
Ideally, the tools would report 95-99% "green" responses. If our current results aren't that high, making changes to the website would certainly benefit them.
As with LCP, it's recommended to first optimize the code necessary for key website elements to load, moving lower-priority fragments further down the file. It's also worth removing unused fragments and minifying them.
The main cause of low FID scores is usually the JavaScript code. Optimizing files and breaking individual fragments into smaller, asynchronously executed batches should significantly speed up the rendering process and reduce resource blocking.
The browser's response speed will also be affected by off-page code - limiting it will reduce the number of processes performed by the browser.
CLS – Cumulative Layouts Shift
The CLS score is the sum of changes resulting from an unexpected page layout shift. A change is counted when an element changes its position at the time of rendering. New elements appearing on the page or changes to the size of existing elements are not counted towards the CLS score, as long as they don't cause other page components to shift. Unlike the metrics listed above, CLS collects data throughout the entire page visit, not during the initial moments of rendering.
Jumps in page layout can occur, for example, as a result of asynchronous resource loading or the dynamic addition of new elements to the DOM structure. Such situations are noticeable, for example, when using pages that load images without a declared size – adjusting the appropriate size to the screen size can cause a sudden change in the page's appearance, redirecting the user to a different part of the page.
Resources downloaded from external sources, built based on values different from the target page, and personalized content generated without proper formatting can also pose problems. Unexpected offsets can also be caused by slow font rendering.
Not every shift is bad; depending on the page design, some user actions will result in changes to the initial layout of elements. It's important that this type of shift is directly related to the action performed.
CLS is based on data collected from users and allows us to determine the actual experience on the website, which is not always available in the conditions in which the website developer works.
Cumulative System Shift – result
A good CLS score is between 0 and 0.1. A score above 0.25 indicates a need for changes and improved user experience. A site is considered stable when at least 75% of users receive a score below 0.1.
Data on the shift can be found in PageSpeed Insights:
The percentage score is based on user data analysis – in this case, 90% achieve a good result.
PSI also provides information collected in laboratory conditions:
We can again obtain detailed information about a larger number of subpages from Google Search Console. 
Poor CLS score – effective ways to improve
A better CLS score can be achieved by adhering to general website design standards . Accurately describing images and videos plays a particularly important role here. Adding attributes related to element size ( width , height , and the associated aspect ratio ) helps the browser correctly arrange elements during rendering, without requiring changes as subsequent content fragments load. For dynamically added images, it's recommended to use placeholders, which reserve space for a later added element.
For some time now, PageSpeed Insights has recommended using the font-display CSS method, which is responsible for preserving fonts on a page. Another option is to preload the font using the preload attribute in the <link> element. Preloading downloads the specified resources before the page rendering begins. This eliminates the problem of downtime and waiting for all files in the first part of the queue to load later in the page display.
Core Web Metrics – UX Matters!
If you look at the solutions that will positively impact the results of individual metrics, it's easy to see that they're nothing new. Google recommended many of them in the first versions of PageSpeed Insights. However, these metrics and their inclusion in the search engine algorithm are a good reason to take a closer look at your websites and actually implement changes that will make them easier to use. This impacts both your online positioning and higher search engine rankings, as well as the user experience.
Summary
The above article covers the following topics:
- the role of Core Web Vitals in assessing user experience,
- characteristics of LCP, FID and CLS indicators,
- website optimization for the user, which simultaneously strengthens search engine results and improves the convenience of using the website.
