Core Web Vitals: what LCP, INP and CLS measure and how to improve them

What Core Web Vitals are

They are the subset of performance metrics Google considers essential for every page. Each has three bands:

A page "passes" when 75% of its visits, measured separately on mobile and desktop, fall in the good band. INP replaced FID (First Input Delay) as a Core Web Vital in March 2024; if a guide still talks about FID, it is out of date.

How much they affect rankings

Google is plain about it in its page experience documentation: Core Web Vitals are used by its ranking systems, but Search always seeks to show the most relevant content, even when the page experience is sub-par. And good results in Search Console or other tools do not guarantee top rankings.

In practice: between two equally useful pages, the faster one has an edge. A fast page that does not answer what people are looking for has none. Speed also affects conversion, whatever Google does.

Field data and lab data: why they disagree

• Field data comes from the Chrome User Experience Report (CrUX): real visits by Chrome users, over a rolling 28-day window. It is what Google uses, and you see it in Search Console's Core Web Vitals report and at the top of PageSpeed Insights.
• Lab data comes from Lighthouse loading the page once under simulated conditions (a mid-range phone on a throttled connection). It is for finding causes; its 0–100 score is not what Google measures.

A new or low-traffic site has no field data, because CrUX needs a minimum volume of visits. Until then, go by the lab. Note too that INP cannot be measured in the lab, since it needs real interactions; Lighthouse uses Total Blocking Time (TBT) as a stand-in.

LCP: how long the main content takes to appear

The LCP element is usually the main image or the page headline. Google splits its time into four sub-parts: time to first byte (TTFB), the delay before the resource starts loading, how long it takes to load, and the delay before it is rendered. The usual causes, most common first:

1. Render-blocking resources. Stylesheets and web fonts the browser must download before painting anything. Fonts served from another domain add extra connections. Fix: inline critical CSS, self-host and preload fonts, and use font-display: swap.
2. A heavy main image, or one discovered late. Fix: compress it, serve WebP or AVIF at the size it is displayed, add fetchpriority="high", and never give it loading="lazy": Google warns that lazy-loading the LCP image always makes the metric worse.
3. A slow server. If TTFB is above 0.8 s, the problem is upstream of the browser: hosting, no caching, or an application that builds every page from scratch. Fix: caching and a CDN.
4. Content that depends on JavaScript. If the headline is built in the browser, or hidden until a script reveals it with an animation, LCP waits for the JavaScript to download and run. Fix: render on the server and show the content from the start; if you want animations, do not let them hide the main content.

An example from our own site: the logo in the header was a 1,024 × 1,024 pixel PNG weighing 133 KB, displayed at 40 pixels. We replaced it with a 160-pixel version that weighs 11 KB: a small change, and 122 KB less to download on a first visit to any page.

INP: how long the page takes to respond

INP records the latency of interactions throughout the visit (clicks, taps, key presses) and reports one of the worst. The culprit is almost always the browser's main thread busy running JavaScript when the user tries to do something.

• Long tasks. Any JavaScript task longer than 50 ms blocks the response. Split the work and yield to the browser between the parts.
• Third-party scripts. Chat widgets, tag managers, A/B testing tools and ad pixels tend to weigh the most. Load them after the interaction or the consent, and remove the ones nobody looks at.
• Too much JavaScript. Split code by page, and do not load on the home page what only the admin panel uses.
• A huge DOM, and updates that recalculate the layout of the whole page again and again.

CLS: how much the content moves

That moment when you are about to tap a link and the text jumps because a banner loaded above it. Causes and fixes:

• Images, videos and iframes without dimensions. Declare width and height, or an aspect-ratio, so the browser reserves the space.
• Ads, embeds and notices that push the content, such as a cookie notice inserted at the top of the page. Reserve their space or show them as an overlay.
• Web fonts that change the size of the text as they load. Use font-display and adjust the metrics of the fallback font.
• Content inserted above what people are already reading. Add it below, or in response to something the user does.

How to measure them

• PageSpeed Insights: field data at the top and lab diagnostics below, with every opportunity and its estimated saving.
• Search Console's Core Web Vitals report: groups your URLs by status and alerts you when a group gets worse.
• Chrome DevTools, Performance panel: shows LCP, INP and CLS live as you use your own site.
• The web-vitals library, if you want to send the metrics from your real visits to your analytics.

Where to start

1. Open Search Console's Core Web Vitals report and start with the group of mobile URLs rated "poor".
2. Run a URL from that group through PageSpeed Insights and see which metric fails.
3. If it is LCP, find the LCP element Lighthouse points at and work through the list above.
4. If it is INP, look for long tasks and third-party scripts.
5. If it is CLS, look for images without dimensions and elements inserted late.
6. After shipping the change, wait: field data takes up to 28 days to reflect it fully.

Sources

• web.dev: Web Vitals
• web.dev: Optimize Largest Contentful Paint
• web.dev: Interaction to Next Paint (INP)
• web.dev: Cumulative Layout Shift (CLS)
• Google Search Central: Understanding page experience in Google Search results
• Search Console Help: Core Web Vitals report
• Chrome for Developers: Chrome UX Report (CrUX)