Web performance and Core Web Vitals

1History

Google first announced site speed as a ranking signal for desktop search in April 2010, noting that it affected a small share of queries [23]. In January 2018 the “Speed Update” extended page speed as a ranking factor to mobile search, aimed at the slowest pages [24].

In May 2020 Google introduced the Web Vitals initiative to give site owners a small, stable set of metrics that reflect real user experience, naming LCP, First Input Delay (FID) and CLS as the first Core Web Vitals [2]. The same month, Google Search announced it would combine Core Web Vitals with existing signals such as mobile-friendliness and HTTPS into a page experience signal [3].

The definition of CLS was revised in 2021 to measure the largest burst of layout shifts rather than their total across the page’s lifetime, which had penalised long-lived pages [10]. On 12 March 2024, INP replaced FID as the responsiveness metric [8].

2The three Core Web Vitals

Largest Contentful Paint

LCP reports the render time of the largest image, video poster, background image or block of text visible in the viewport, relative to when the page started loading [6]. The browser stops reporting new candidates once the user interacts with the page, so the value reflects the initial load [6].

Interaction to Next Paint

INP observes the latency of every click, tap and key press during a visit and reports a value close to the slowest, ignoring one outlier for every 50 interactions on busy pages [7]. Each interaction’s latency is the sum of input delay, processing time and presentation delay until the next frame is painted [7][21].

Cumulative Layout Shift

CLS scores unexpected movement of visible content. Each layout shift is scored as the impact fraction multiplied by the distance fraction, and the reported value is the largest session window: a burst of shifts less than one second apart, capped at five seconds [9][10]. Shifts within 500 ms of a user input are excluded, because users expect the page to react [9].

3Supporting metrics

Several other metrics help diagnose Core Web Vitals without being part of them.

• Time to First Byte (TTFB) measures how long the server takes to begin responding. web.dev suggests 0.8 s or less as a rough guide, since it delays every later metric [11].
• First Contentful Paint (FCP) marks when any text or image is first rendered; 1.8 s or less is considered good [12].
• Total Blocking Time (TBT) is a lab metric that sums how long the main thread was blocked; Lighthouse uses it as a proxy for responsiveness because lab runs have no real user interactions [16].

4How performance is measured

Field data

Field data, also called real-user monitoring, comes from actual visits. Google’s source is the Chrome UX Report (CrUX), which aggregates measurements from Chrome users who have opted in, over a rolling 28-day period, at both page and origin level [13].

Core Web Vitals are assessed at the 75th percentile of those visits, separately for mobile and desktop, so that a page passes only if most users have a good experience [1]. Search Console’s Core Web Vitals report uses the same data and groups similar URLs together [14].

Lab data

Lab data comes from a controlled test on a single device and network profile, typically Lighthouse. It is reproducible and detailed, which makes it useful for finding causes, but it can differ considerably from field data [15][16].

PageSpeed Insights shows both: CrUX field data when enough traffic exists, and a Lighthouse lab run for diagnosis [15].

5Role in Google Search ranking

Google states that Core Web Vitals are used by its ranking systems and recommends that site owners achieve good scores [5]. Its documentation also describes page experience as a set of considerations, Core Web Vitals, HTTPS, mobile usability, absence of intrusive interstitials, rather than a single ranking signal [4].

Google is explicit that good page experience does not override relevance: a page with better content can rank above a faster one [4][5]. In practice, performance acts as one factor among many and matters most when competing pages are otherwise similar.

6Improving LCP

web.dev divides LCP into four sub-parts: time to first byte, resource load delay, resource load duration and element render delay. Most slow LCPs are dominated by one of them [17].

• Reduce server response time with caching and a CDN, since TTFB delays everything after it [11][17].
• Make the LCP image discoverable in the initial HTML rather than injected by JavaScript or CSS [17].
• Give the LCP image priority with fetchpriority="high"[18].
• Never lazy-load the LCP image; loading="lazy" is for images below the fold [19].
• Serve appropriately sized, compressed images in modern formats [17].

7Improving INP

Poor INP is almost always caused by JavaScript occupying the main thread when the user interacts. A task longer than 50 milliseconds is considered a long task, because it can delay input handling perceptibly [20].

• Break long tasks into smaller ones and yield to the main thread between them [20].
• Load less JavaScript up front, and defer non-critical and third-party scripts [21].
• Keep event handlers short and move expensive work out of the path of the next paint [21].
• Avoid very large DOM trees, which make each rendering update slower [21].

8Improving CLS

• Always set width and height (or CSS aspect-ratio) on images and video so the browser reserves space [22].
• Reserve space for ads, embeds and banners before they load; avoid inserting content above what the user is reading [22].
• Use font-display and matched fallback fonts to limit shifts when web fonts swap in [25].
• Animate with CSS transform rather than properties that change layout, such as top or height[22].

9Common misconceptions