Introduction
Ensuring your users have a positive digital experience should play a key role in any online business as page experience impacts your Google search ranking.
Part of Google's ranking algorithm is already dedicated to evaluate the User Experience (UX). In August 2021 Google added another signal to assess UX quality: Core Web Vitals (a group of performance metrics that measure real-world user experience for loading performance).
Page experience is a set of signals that measure how users perceive the experience of interacting with a web page beyond its pure information value.
Improving your Core Web Vitals can lead to a better user experience, increased organic traffic and ultimately more conversions for your website.
Core Web Vitals
Largest Contentful Paint (LCP)
Collect from Web Browser API
Largest Contentful Paint (LCP) measures loading performance and is part of the Core Web Vitals. Google will use Core Web Vitals as a search ranking signal in 2021.
Understanding Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) measures the render time of the largest content element visible within the viewport (so before the users scroll).
LCP focuses on the speed of delivering the largest (excluding background images, and excluding content displayed outside the viewport e.g. below the fold) and consistent content (temporary content such as loaders or splash screens are ignored).
According to Google guidelines, your web pages should have a LCP under 2.5s, for at least 75% of your users (including both desktop and mobile traffic).
Common causes of slow LCP include large design elements such as images, videos and third-party scripts.
Optimization example
Optimize resources, use lazy load and trim JS to the essentials.
Cumulative Layout Shift
Collect from: Web Browser API
Cumulative Layout Shift (CLS) measures page stability, by monitoring significant movements of elements on the page that may frustrate or mislead the user, during the entire page lifespan.
CLS is part of the Core Web Vitals. Google will use Core Web Vitals as a search ranking signal in 2021.
Understanding Cumulative Layout Shift
Cumulative Layout Shift measures the total sum of all individual layout shifts that occur during the entire lifespan of the page (including after the user has started to interact with the page), taking into account the size of the concerned area, and the distance of the shift.
The CLS algorithm monitors every layout shift in the current context, thus excluding the content of iframes.
Layout shifts that happen 500 ms after an active user interaction (like a click, a keystroke, or the resize of the window) have no impact on the CLS. Hovering, scrolling, and update flinging are not considered active interactions.
Each of the other layout shifts are scored according to the total affected area and the distance covered by the moved elements. Cumulative Layout Shift is the sum of all the considered layout shifts scores.
According to Google guidelines, your web pages should have a CLS under 0.1 for at least 75% of your users (including both desktop and mobile traffic).
Optimization example
To improve your Cumulative Layout Shift, make sure that the browser can allocate the right space for your images and iframes (including ads), even before it starts loading them, by defining their width and height, or aspect ratio.
Max potential First Input Delay
Collected from: Web Browser API
First Input Delay (FID) measures the time between a user’s first interaction and how long it takes for the interaction to be processed (interaction can be clicking or tapping a link or button).
The Max Potential First Input Delay (Max Potential FID) is the worst value a First Input Delay could have. First Input Delay (FID) is the delay a user experiences when interacting with the page for the first time (example: delay to get a feedback from the page when clicking an element).
The FID depends on the business of the page (tasks preventing responsiveness) and when the user interacts.
FID is collected from a given interaction of a real user, whereas the Max Potential FID can be computed without a user, the value is the delay that a user would face by interacting with the page when the page is least responsive (worst case scenario).
According to Google guidelines, your web pages should have a FID under 100ms for at least 75% of users (including both mobile and desktop traffic)
How it's calculated
Max Potential First Input Delay is computed by finding the longest task after the First Contentful Paint (as we can assume a user would not attempt to interact with a page before any content is displayed).
Note: First Input delay is a field metric so can be leveraged with Speed Analysis RUM to measure input responsiveness. Use Total Blocking Time (TBT) when using synthetic monitoring. |
Total Blocking Time
Total Blocking Time (TBT) measures the total amount of time that a page is blocked from responding to user input (clicks, keyboard presses, etc) after the page has started to render content.
How it's calculated
The Total Blocking Time calculation is based on the Long Tasks. A Long Task is a treatment that monopolizes the web browser for a while (>50 milliseconds) and blocks other critical tasks from being executed (e.g. reacting to user input).
The Total Blocking Time is a sum, calculated by adding the blocking portion of all Long Tasks between First Contentful Paint and Time to (Consistently) Interactive. The blocking portion of the long task is the duration in excess of 50 ms.
Example of a page loading with 3 long tasks
[longtask 1: 55 ms] FCP [longtask 2: 110 ms] [longtask 3: 200 ms] TTI
- longtask 1 is ignored as occurring prior to the FCP
- blocking portion of long task 2 is 60 ms (110 - 50).
- blocking portion of long task 3 is 150 ms (200 - 50).
The Total Blocking Time thus is 210 ms (60 + 150).
Why is Total Blocking Time sometimes not computed?
As the Total Blocking Time is computed between the First Contentful Paint (FCP) and the Time to (Consistently) Interactive, both metrics need to be defined for the TBT to exist. When there are recurring and repeated Long Tasks, there is not really a time when the interface is consistently interactive, so there is no “end” to the range of time TBT should be computed into.
If you need to track your Long Tasks but the TBT cannot be calculated, you can use the "Sum of Long Tasks" metric instead.
Interaction to Next Paint
Collected from: Web browser API
Interaction to Next Paint (INP) is a metric that assesses the responsiveness of a web page. It measures how much time elapses between a user interaction, such as a click or key press, and the next time the user sees a visual update on the page. (Please note, that the visual update may be unrelated to the interaction).
Google announced that FID will be replaced by INP in March 2024. FID will no longer be used for ranking websites but INP will (along with LCP and CLS).
Differences between INP and FID
-
FID only measures the first interaction of the page whereas INP measures all page interactions.
-
FID measures the delay between the user interaction and when the browser is actually able to begin processing it.
- INP measures the delay between the user interaction and when there is a subsequent UI change.
INP is much more representative of the potential visual delay of user’s experience when interacting with a page. FID focuses more on a technical delay in the beginning of the page view (first interaction only).
How does INP work?
INP aims to capture the duration between a user initiating an interaction and the subsequent rendering of the next frame, striving to achieve this for most, if not all, user interactions. INP value is the worst delay observed (for page views with more than 50 interactions, the outliers are excluded as INP will be the 98th centile value)
Interactions observed for INP are:
- Clicking with a mouse
- Tapping on a device with a touchscreen
- Pressing a key on either a physical or onscreen keyboard
According to Google guidelines, your web pages should have an INP under 200ms for at least 75% of users (including both mobile and desktop traffic)