From the second half of June 2012, Google began to consider the performance of a website as a ranking factor.
The metrics used to establish this performance are the Core Web Vitals (essential signals) metrics, which include three key metrics: Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS).
In this guide, let’s see what these metrics are introduced by Google to improve user experience in terms of page load speed, responsiveness and visual stability, and how they affect SEO.
But above all we see how we can optimize a site by solving the problems related to these three metrics, thus improving the user experience, search engine ranking, traffic to your site.
Core Web Vitals – User Experience Signals (UX)
The Core Web Vitals are part of a package of updates, the Page Experience Update, and are essential quality signals for measuring the user experience on the Web, that is, the usability and quality of a Web page.
These are metrics that measure how well a website behaves in terms of user experience, particularly regarding page load speed, responsiveness, or interactivity, and visual stability.
But it’s not just about speed. These signals measure a set of factors that contribute to the way a page is experienced by a user navigating from a certain device, with a particular connection, from a specific location.
A good experience for someone, it may not be for others. The Core Web Vitals examine the set of user visits and the thresholds are evaluated at 75
percentile of all users.
The signals of the Page Experience Update
Part of this major update:
- Core Web Vitals
- Mobile Friendly
- Safe Browsing
- HTTPS
- No Intrusive Interstitials.
What are the Core Web Vitals
When we write this guide, the Core Web Vitals are these 3:
- Largest Contentful Paint (LCP) – Loading Experience.
- First Input Delay (FID) – Speed of Interaction Response.
- Cumulative Layout Shift (CLS) – Visual stability of content.
Let’s see them in detail.
LCP – Largest Contentful Paint
The LCP metric measures the time it takes the main content of a page, the largest element, to download and be ready to interact.
Certain elements are measured such as the largest image or context block within the user’s viewport, images, background images, videos, block-level text elements, such as paragraph tags.
The block-level elements used for calculating Largest Contentful Paint’s score can be <main> and <section> elements, as well as heading, div, form elements.
According to Google, the ideal value is around 2.5 seconds. Beyond 4 seconds, the user experience becomes “poor.”
The largest elements of a page are the heaviest content, namely:.
- video images and thumbnails
- elements with images loaded in the background (with the property of “background image”)
- text element containers: heading and paragraph elements (H1, H2, p).
Of the causes of the slowdown of the largest element:.
- the server responding slowly – Time To First Byte (TTFB) (it is perhaps the case of an upgrade or hosting change).
- “View Blocking Resources”: style sheets and scripts that are loaded into the browser window before the HTML, content, blocking initial rendering of the page begins.
- Images that are not optimized or published in outdated formats such as JPEG or PNG or in GIF that can significantly lengthen page loading times.
In summary, among the causes of poor LCP are.
1. Slow response times of the server
2. Blocking the rendering of JavaScript and CSS
3. Loading time of resources
4. Client-side rendering.
LCP – Come risolvere
As mentioned, it is good to consider an upgrade or change of provider if the problem depends on the server.
- As for blocking resources, this can be remedied by letting the most important resources, those that are used to structure the page, such as style sheets, scripts, fonts, preload by inserting the rel=”preload” attribute on the <link> tag in the HTML document.
Example: <link rel=”preload” as “style” href=css/style.css”>
Basically, the preload tells the browser that a resource must be loaded before page rendering begins.
- Anything that needs to be anticipated in the first screen (above the fold), because it serves the rendering of the page, can be inserted inline, in the HTML document of the page, and not linked externally.
- In contrast, everything what is not important for rendering the first screen can be deferred and loaded asynchronously (loaded independently of all other resources on the page).
Example: <link rel=”async” as= “script” href=”js/morescript.js”>
- Minify style sheets and scripts with elimination of blanks, comments, and indents in the code.
- Optimize images and other media: As for images, you should compress them with a good compression rate; resize; use appropriate formats such as WebP, JPG or SVG (vector); defer loading images that are off the first screen (Lazy Load).
Scalable Vector Graphics (SVG) are a lightweight image format that can be scaled without loss of quality. They are ideal for logos, icons and simple graphics.
The use of SVG can significantly reduce website load time and improve Vitals Web Cores.
Lazy Load means deferred loading of images and videos until they are needed. On WordPress you can implement this feature with several plugins.
If the cause is a slow response time of the server:
- Optimize the server
- Adopt a CDN – (Content Delivery Network) is a network of geographically distributed servers that provides digital content, such as web pages, images, videos and files
- Use the Cache.
If the cause is blocking the rendering of JavaScript and CSS:.
- Minimising CSS
- Deferring CSS (non-critical)
- Inline of CSS
- Minimize and compress JavaScript files
- Return the unused JavaScript.
Other interventions:.
- Optimize and compress your images
- Preloading the important resources
- Compress the text files
- Provide different resources based on network connection (adaptive service)
- Cache resources using a service worker.
FID – First Input Delay
This metric measures the time between the first interaction of the user on the page (eg: click on a button) and the response provided by the browser.
The goal of FID is to measure the responsiveness of a site during loading.
An ideal FID should equal less than 100 milliseconds.
What is meant by first interaction?
The first interaction is the one that occurs before the page loads completely.
By interaction is meant direct interaction, such as
- click on a button or link
- the areas of text insertion
- the dropdown and checkboxes
Scrolling (scrolling) and zooming (page enlargement or element enlargement) are not considered interactions.
What can excessive response time compared to interaction depend on?.
- Presence of third-party code all scripts loaded from a domain other than the page’s domain, i.e. third-party scripts: Google, Facebook, Iubenda, etc. Examples are tracking scripts, Google Tag Manager, cookie consent banners, etc.
- non-optimized and redundantScript, a characteristic of CMSs such as WordPress, where Javascript packages are reloaded multiple times.
- Excessive number of external resources to the page to load, in case for example there are several style sheets or javascripts.
FID – How to fix
- Reduce the impact of third-party code
- Reduce script execution time by eliminating everything you don’t need and minimizing code.
- Move the code of the heavier scripts to a Web Worker, to another javascript block that will run in the background and in parallel with the scripts that manage the user interface.
CLS – Cumulative Layout Shift
The CLS metric indicates how stable or unstable the layout of a page is; how the elements inside it move.
The CLS refers to the unexpected move of elements of the web page while the page is still being downloaded.
The elements that tend to move are fonts, images, videos, contact forms, buttons and other types of content.
Minimizing CLS is important because moving pages can cause a bad user experience.
An ideal CLS should be 0.1 or less.
Thus, in this case, the value is decimal or percentage (measured in terms of percentage occupancy of the visual area).
Shifting occurs when, for example, when the page loads we see an element at the top go down.
The difference between the two positions determines shift and displacement. The more elements move, the higher the metric rises.
CLS – How to intervene
Typically, problems with this metric have to do with the size of heavy elements found on the page, images or videos in iframes, taken from youtube or vimeo.
In detail, with these factors:.
- Images without dimensions
- Ads, embeds and iframes without dimensions
- dynamic content
- Font Web
- Actions that await a response from the network before updating the DOM”.
The solution is to declare the height and width dimensions of images and video elements in the HTML or use a CSS rule that reserves a space for these elements.
As for responsive images, however, it is good to make sure that different image sizes for different viewports use the same aspect ratio.
Two ways to indicate size:.
<img src=”pippo.jpg” width=”850” height=”520” alt=”Pippo” />
img {aspect-ratio: attr(width) / attr(height); }
In this way we fix the precise proportions of the elements.
CLS and dynamic content
Another caution is to avoid placing dynamic content (banners, CTAs, embedded objects such as YouTube videos, Tweets, etc.) within an already defined layout. This content can be uploaded in a prepared space.
CLS e Web Fonts
Also Web Fonts, like Google Fonts (or other third-party fonts), cause problems with respect to CLS metrics, which we can solve, however, by using preloading, with the rel=”preload”, and the font-display style attribute with optional value.
One way to prevent this from happening is to use rel=”preload” in the link to download the web font.
How to measure Core Web Vitals?
There are several tools with which to measure Core Web Vitals.
Search Console
The Report Core Web Vitals is available in Search Console, within the area dedicated to Page Experience Update.
The report helps evaluate site pages – both desktop and mobile side, and identify those that need attention based on actual data.
PageSpeed Insights
PageSpeed Insights has been updated to integrate Lighthouse 6.0, which makes it capable of measuring Core Web Vitals and notifying areas for action. Read the guide on how to read PageSpeed data.
Lighthouse
With Lighthouse you can do further checks on the Core Web Vitals – LCP and CLS, and on the metric – Total Blocking Time (TBT), linked to the First Input Delay.
Please note: the Search Console report shows page performance based on real usage data from the CrUX report, it is based on real data (Field Data), whereas the Lighthouse data is based on simulated users, simulated devices, and simulated Internet connections. That is, it shows data based on so-called “lab data” (Lab Data), which is useful for debugging performance issues during website development but may not capture real-world bottlenecks.
Web Page Test
It’s another tool you can use to get more technical data. The simulation integrates settings for location, browser and connection type.
H3 Chrome DevTools
Chrome devtools helps you find and troubleshoot visual page instability issues that can help shift the cumulative layout (CLS).
The tool allows you to select a layout move to view its details in the Summary tab.
To see where the move occurs, you can hover over “Move from” and “Move to”. Chrome devtools also measures Total Block Time (TBT), useful for improving the First Input Delay (FID).
Chrome UX Report (CrUX)
This report is a public set of real data on user experience across millions of websites. The report Chrome UX reports real data.
Web Extension Vitals
The extension can be installed from the Chrome Web Store and measures in real time the three Core Web Vitals metrics.
You can download and install the extension at this page.
Conclusion, waiting for Google changes
Google is continually improving its understanding of user experience by updating Core Web Vitals and other metrics, because Core Web Vitals are not the only user experience metrics to focus on. There are others (Web Vitals, which are not “Core,” i.e., not essential) that need to be taken into account in the totality of the site.
Recently, at Google I/O, Annie Sullivan and Michal Mocny presented a new metric called INP or Interaction to Next Paint, which is scheduled to enter in March 2024.
Interaction to Next Paint is a metric that evaluates the overall responsiveness of a page to user interactions by observing the latency of all qualified interactions that occur during page navigation.
To provide a good user experience, we already know that a website should try to have an Interaction to Next Paint of 200 milliseconds, or even less.
