Navigating the Waters of Core Web Vitals in 2024

In the ever-evolving domain of web development, delivering an optimal user experience is paramount, yet for many years, there were no clear standards for what constitutes a good user experience. However, this changed in May 2020, when Google introduced the Core Web Vitals, a set of standardised user-centric metrics, which help site owners and developers have a better understanding of how visitors experience their websites.

This article aims to provide some more insights on these metrics through examples, while also casting light on the significant upcoming changes with the Interaction to Next Paint (INP) metric set to replace First Input Delay (FID) in March 2024.

Table of contents:

• How to measure Core Web Vitals
• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• Cumulative Layout Shift (CLS)
• The introduction of Interaction to Next Paint (INP)

To begin with, if we want to measure our web application's Core Web Vitals scores we can use the PageSpeed Insights, which provides access to Chrome User Experience (CrUX) data in the top section labeled "Discover what your real users are experiencing".

Reviewing the Core Web Vitals until 2024: LCP, FID, and CLS

Largest Contentful Paint (LCP) measures the load speed of the main content, focusing on the point in the page load timeline when the primary content (e.g. main banner section) has been loaded — a key metric for understanding user experience. It essentially marks the time at which the page's main content has become visible to the user, providing a realistic snapshot of when they can start consuming the page's information.

The LCP thresholds. Source: web.dev

Let's say we want to improve the LCP score in a website. To improve the load time of the main content, we would have to first fine tune (e.g. compress / optimise image size per viewport) any asset(s) included in the main content and postpone (e.g. lazy load) the load of other parts of the page (e.g. header, side navigation, footer). On the other hand, if we wanted to have a very bad LCP, we would place a large, uncompressed hero image as a main banner and make sure that other parts of the page are being loaded before it does.

First Input Delay (FID) measures the page's responsiveness to initial user interactions, such as clicks, taps, or key presses, highlighting the real-world experience users have with the interactivity of a site. This metric is essential because it measures the time from when a user first interacts with a page to the time when the browser is actually able to begin processing event handlers in response to that interaction.

The FID thresholds. Source: web.dev

For better FID we would split a hefty JavaScript bundle into smaller chunks which can speed up parsing and execution. On the contrary, a monolithic JavaScript file that blocks the main thread (e.g. with many async methods) can lead to noticeable delays in interactive responsiveness, resulting in poor FID performance.

Cumulative Layout Shift (CLS) gauges the stability of a page's layout, measuring how much content shifts unexpectedly as the site loads and during its interaction. This metric is critical for user experience, as unpredictable movements can lead to mistaken clicks, difficulty in reading content, and overall frustration for the user.

The CLS thresholds. Source: web.dev

To eliminate CLS, we have to reserve space for images or other types of content before they are fully loaded on the page. Using placeholders before images and assigning fixed dimensions for media assets, prevent unexpected layout shifts as content loads. In general content that loads asynchronously without reserved space can cause disruptive shifts, increasing CLS.

Core Web Vitals in 2024: The Introduction of INP

Starting from March 2024, Interaction to Next Paint (INP) is set to offer a more detailed measure of a page's responsiveness by tracking the delay between user interactions and the visual updates that follow.

The lifecycle of an interaction. Source: web.dev

Significantly, INP will replace FID, providing a broader evaluation of a page's interactive performance. INP is considered a better metric than FID, particularly because it offers a more comprehensive understanding of a website's interactivity and responsiveness across the entirety of a user's session, not just at the beginning, since the INP score is measured when the user leaves the page by aggregating all interactions the user made with the page throughout the page’s lifetime and returning the worst-measured score.

So in order to ensure we're delivering user experiences with good responsiveness and our web app has a good INP score, we have to make sure that the worst measured INP of our page is:

• <=200 milliseconds. Then this means that our page has good responsiveness.
• If our INP is >200 milliseconds and <=500 milliseconds, this means that our page's responsiveness needs improvement.
• If our page's worst INP is >500 milliseconds then we will receive a poor INP score.

Optimising a website for INP would involve streamlining JavaScript execution, via task chunking and prioritising essential scripts to enhance interaction responsiveness. Applying lazy loading for non-critical content and prioritising crucial assets can improve the perception of speed for users. State management is also crucial, e.g. avoiding unnecessary state updates and using caching techniques can help in reducing rerendering cycles and improving response times to user inputs. Last but not least, implementing debouncing or throttling for rapid user interactions such as typing or scrolling, can prevent excessive function calls that might lead to UI jank or delayed responses.

By focusing on these areas, we can enhance the responsiveness of our web app and overall improve its Core Web Vitals scores, including the INP metric, leading to a smoother and more engaging user experience. Regular testing and continuous optimisation should be an essential part of our development cycle to timely address performance issues as our application evolves.