In the first blog post of this series on Core Web Vitals, we discussed what Core Web Vitals are and which metrics to use. In this blog post, we deep dive into how to define concrete numbers to each metrics.

As initial word of caution, this series treats desktop, tablet and mobile as equal formats. It is fair to say that mobile to taking over more real estate over the year. The latency you have with mobile devices especially on 4G or 5G does force website owners to mindfully craft their sites and infrastructure (backend, databases, frontend as well as hyperscalers).

LCP (Largest Contentful Paint)

LCP is about the loading time and the customer experience. It is measured in seconds. In this section, we discuss quality (i.e. the metrics you define for your business) and achievability (i.e. the range and maximum threshold that is acceptable for your business) with concrete metrics numbers for your website or Ecommerce platform.

Nailing LCP is key for a good customer experience but also conversion. In a 2019 survey by Unbounce, 70% of consumers say that page speed impacts their willingness to buy from an online retailer.

More importantly, website conversion drops by an average of 2.11% with each additional second of loading time (Portent study).

Quality

The amount of time a user will wait before losing focus on a task is a range, from roughly 0.3 to 3 seconds. Your page loading time maximum threshold or Largest Contentful Paint (LCP) "Good" threshold, shall be 3 seconds.
A Portent study goes up to 4 seconds but be aware of the conversion drop that could dramatically reduce your revenues.

Achievability

Data from the Chrome User Experience Report (CrUX) is used to determine the percentage of origins on the web that meet the candidate LCP "Good" thresholds. The 1 second threshold is not met by at least 10% of origins, but all other thresholds from 1.5 to 3 seconds meet this requirement.

In addition, the performance of top-performing sites is analyzed to determine which thresholds are consistently achievable at the 75th percentile. The 1.5 and 2 second thresholds are not consistently achievable, while the 2.5 second threshold is consistently achievable.

Based on the above, it is wise to stick to the 3 second threshold for dynamic pages.

However, it is recommended to make a difference between static and dynamic pages. Static pages such as content pages can be served on the edge through static site generators for example that significantly reduces the LCP. Furthermore, they can be cached quite easily.
For this reason, it is wise to achieve the 0.5 to 2 second threshold for static pages.

First Input Delay

First Input Delay or FID is the interactivity between your website and the device. In layman’s terms, this is the time it takes for a website to be ready for user interaction such as clicks, keyboard input or scrolls. It is measured in milliseconds.

Quality

Research suggests that delays in visual feedback of up to around 100ms are perceived as being caused by an associated source, such as a user input.

This implies that a 100ms First Input Delay "Good" threshold is appropriate as a minimum bar because if the delay for processing input exceeds 100ms, there is no time for other processing and rendering steps to complete.

Based on the fact that nearly 50% of the global Internet traffic is mobile as of November 2022 (source https://www.oberlo.com/statistics/mobile-internet-traffic), it is advised to target 100ms FID for your dynamic and static pages.
Note that you can use lazy loading for some elements below the fold of your page to avoid loading the entire assets in one go without affecting your FID. More on the technical elements of improving FID in the third blog post of this series.

Achievability

Based on data from the Chrome User Experience Report (CrUX), the majority of origins on the web meet the 100ms First Input Delay (FID) "Good" threshold at the 75th percentile.

Top sites consistently meet this threshold at the 75th percentile (and often meet it at the 95th percentile). Therefore, 100ms is determined to be a reasonable "Good" threshold for FID.

Again with mobile is mind, setting ambition metrics levels for FID will increasingly help you address conversion drops and increase customer experience. For this reason, set a 100ms First Input Delay "Good" threshold and do not compromise on it.

Cumulative Layout Shift

Cumulative Layout Shift or CLS is the visual stability of your website or Ecommerce platform. In layman’s terms, this is the sum of unforeseen visual page content layout change. It is measured by a number using the impact of layout changes. Read how to calculate CLS on the Web.dev website.

Quality

Cumulative Layout Shift (CLS) is a metric that measures how much the visible content of a page shifts. Since there is no research available to directly inform the thresholds for this metric, real-world pages with different amounts of layout shift are evaluated to determine the maximum amount of shift that is acceptable before causing significant disruptions when consuming page content.

Commonly agreed threshold is 0.1. Testing found that shifts from 0.15 and above were consistently perceived as disruptive, while shifts of 0.1 and below were noticeable but not excessively disruptive.

Therefore, values up to 0.1 are considered candidate "Good" CLS thresholds, although zero layout shift is ideal.

Achievability

Based on data from the Chrome User Experience Report (CrUX), nearly 50% of origins have a Cumulative Layout Shift (CLS) of 0.05 or below, which suggests that 0.05 might be a reasonable CLS "Good" threshold.

However, some use cases, such as third-party embedded content, can lead to layout shifts greater than 0.05. Therefore, the CLS threshold of 0.1 is considered a better balance between quality of experience and achievability, although the web ecosystem is encouraged to address layout shifts caused by third party embeds in the future to allow for amore stringent CLS "good" threshold of 0.05 or 0.

In the 3rd part of this blog series, we will discuss which tools to use for measuring Core Web Vitals.

Summary: