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

What Core Web Vitals are

Core Web Vitals are part of Google's Web Vitals initiative, which aims to provide unified indicators of user experience quality. At the time of writing there are three:

Metric	What it measures	Good	Needs improvement	Poor
LCP: Largest Contentful Paint	Loading: when the largest content element visible on screen is rendered.	≤ 2.5 s	2.5–4 s	> 4 s
INP: Interaction to Next Paint	Interactivity: how long the page takes to respond visually to user interactions.	≤ 200 ms	200–500 ms	> 500 ms
CLS: Cumulative Layout Shift	Visual stability: how much elements move unexpectedly while the page is in use.	≤ 0.1	0.1–0.25	> 0.25

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was handled; INP takes into account practically every interaction during the visit (clicks, taps and key presses) and measures the full response until the browser paints the next frame. It is a considerably more demanding metric, and many sites that passed on FID do not pass on INP.

How they are assessed: the 75th percentile of real users

To decide whether a page or site "passes", Google does not use a single measurement but data from real Chrome users collected in the Chrome User Experience Report (CrUX). The rule is:

• Take the 75th percentile of the measurements for each metric, separately for mobile and desktop. In other words, the value that at least three out of four visits achieve.
• A page (or group of similar pages) is considered "good" on Core Web Vitals if all three metrics are within the "good" threshold at that percentile.
• CrUX data is aggregated over the previous 28 days, so any improvement takes weeks to be fully reflected.

If a URL does not have enough traffic for its own data, tools may show data aggregated across a group of similar pages or the whole origin. Small sites may have no field data at all; in that case you are left with lab testing or installing your own measurement.

The 75th percentile explains why your site can feel lightning-fast on your own computer and still fail: what counts is real users, many of them on mid-range phones and patchy connections.

Field data versus lab data

This is the most important distinction if you do not want to waste time:

	Field data (RUM)	Lab data
Source	Real visits (CrUX, or your own measurement with the web-vitals library).	A simulated load under controlled conditions (Lighthouse).
What it is for	Knowing what the real experience is like and whether you pass.	Diagnosing causes and testing changes before you release them.
INP	Measured.	Cannot be measured without real interaction; Lighthouse uses Total Blocking Time (TBT) as a proxy.
Limitation	A 28-day lag in CrUX; little detail on causes.	May not resemble your users' experience.

The right workflow: use field data to decide what to fix and on which templates, use the lab to understand why and validate the fix, then go back to field data to confirm the effect.

Tools for measuring

• Search Console's Core Web Vitals report: groups similar URLs by status and metric; ideal for spotting problem templates across the whole site.
• PageSpeed Insights: shows CrUX field data for the URL and the origin at the top, and a Lighthouse lab analysis with recommendations below.
• Lighthouse and Chrome DevTools: the Performance panel lets you record loads and interactions, and see long tasks, the LCP element and layout shifts.
• CrUX via its API, dashboard or BigQuery: history and comparison with competitors, provided they have enough traffic.
• Your own measurement (RUM): the web-vitals JavaScript library sending data to GA4 or another platform. It lets you segment by page, device or country and, above all, identify which elements and interactions are causing problems.

Setting up your own field measurement

If CrUX does not have enough data for your pages, or you need to know why a template fails, your own measurement is worth the effort. A minimal set-up:

1. Load the web-vitals library and send each metric to your analytics platform as an event, including its value and rating.
2. Use the library's attribution build to record the LCP element, the slowest interaction's target and the shifting element.
3. Add the page template and device type as parameters so you can aggregate by template.
4. Report the 75th percentile, not the average, so your figures are comparable with CrUX.

How to improve LCP

The LCP element is usually the main (hero) image, a large block of text or a header video. Its time can be broken down into four parts, and you should know which one dominates before acting:

1. TTFB (time to first byte): how long the server takes to start responding.
2. Resource load delay: how long the browser takes to start downloading the LCP resource after the HTML arrives.
3. Resource load duration: how long the download takes.
4. Element render delay: the time between the resource finishing downloading and being painted.

Typical fixes

• Server: full-page caching, a CDN, less back-end work, hosting close to your users.
• Early discovery: the LCP image should be in the initial HTML (not injected by JavaScript or set as a late-loading CSS background), with fetchpriority="high" and, if needed, <link rel="preload">.
• Never lazy-load the LCP image. It is one of the most common mistakes: loading="lazy" on the hero image delays exactly what matters most.
• Weight: modern formats (AVIF, WebP), appropriate sizes with srcset and sensible compression.
• Render-blocking resources: critical CSS inlined and the rest deferred; non-essential scripts with defer or async; optimised web fonts.
• Do not hide content behind A/B tests or animations that wait for JavaScript before showing it.

How to improve INP

INP measures interaction latency, and the value reported for a visit is, roughly speaking, that of one of its worst interactions. Each interaction has three phases: input delay (the main thread is busy with something else when the user taps), processing time (how long your event handlers take) and presentation delay (how long the browser takes to recalculate styles, lay out and paint).

Typical fixes

• Reduce JavaScript: remove unused code and third-party scripts, and load the rest only when needed. Chat widgets, maps, video players and marketing tags are the usual suspects.
• Break up long tasks: tasks longer than 50 ms block the main thread. Split the work and yield control to the browser between chunks (for example with setTimeout or, where available, scheduler.yield()).
• Give immediate visual feedback: update the interface first (open the menu, highlight the button) and do the heavy work afterwards.
• Avoid expensive recalculations: very large DOMs, style changes that force the whole page to be recalculated, interleaved layout reads and writes.
• Review your tag manager: every tag added in Tag Manager runs on the same main thread as your website.

How to improve CLS

CLS adds up the magnitude of unexpected shifts of visible elements. It does not count the whole visit: shifts are grouped into "session windows" (bursts of up to 5 seconds with less than 1 second between shifts) and the worst window is taken. Shifts that happen right after a user interaction do not count.

Typical fixes

• Dimensions on images and videos: width and height attributes or CSS aspect-ratio, so the browser reserves the space.
• Reserved space for ads, iframes and embeds (maps, reviews, social media), with a minimum height.
• Do not insert content above existing content: cookie banners, notices or promotions that push the page down. Overlay them or give them reserved space instead.
• Web fonts: an appropriate font-display value, preloading critical fonts and metric overrides (size-adjust) so the fallback font takes up the same space.
• Animate with transform rather than properties that affect layout (top, height and so on).
• Back/forward cache (bfcache): making the page eligible improves the experience when users go back and avoids shifts on those navigations.

Typical problems by type of website

Causes tend to repeat depending on how the site is built. It is not a fixed rule, but it tells you where to look first:

Type of website	Usual suspects
CMS with many plugins (e.g. WordPress)	Heavy themes and page builders, plugins loading scripts on every page, slow shared hosting (TTFB), header sliders.
Hosted e-commerce platforms	Third-party apps injecting JavaScript (reviews, chat, upsells), product images without dimensions, promotional banners that push content down.
JavaScript applications (SPAs)	Content rendered only on the client (late LCP), large JavaScript bundles, hydration that blocks interactions (INP).
Media sites and portals	Ads without reserved space (CLS), many third-party tags (INP), large unoptimised images.
Property and tourism sites	Embedded galleries and maps, search tools with heavy filters, header videos.

In every case the decisive step is the same: identify from the data which element is the LCP, which interaction is slow and which element shifts, and fix exactly that.

Core Web Vitals and SEO: how much they really matter

Google includes Core Web Vitals among the page experience signals its ranking systems use, but it has also made clear that relevance and content quality carry more weight: a page with better content can outrank a faster one. Put another way, passing Core Web Vitals will not make you rank if your content is not up to scratch, and failing them is rarely the sole cause of poor rankings.

That does not make them irrelevant. In competitive markets, where several pages have comparable content, experience can make a difference. And the business impact is direct: a page that is slow to appear, or that moves the button just as you go to tap it, loses users whether or not it shows up in rankings. That is why we treat them as part of our web development and CRO work, not just as an SEO checkbox.

How to prioritise

1. Start with the Search Console report and group by template (homepage, category, product page, article).
2. Prioritise mobile and the templates with the most organic traffic and conversions.
3. Tackle the failing metric with the fix that matches its cause, not with a generic list of "optimisations".
4. Validate in the lab, release, and confirm with field data after a few weeks.
5. Set a performance budget so improvements are not lost with the next plugin or tag.

Common mistakes

• Chasing the Lighthouse score instead of field metrics. A lab score of 100 does not guarantee passing with real users, and vice versa.
• Installing an "optimisation" plugin that lazy-loads everything, including the LCP image.
• Measuring only the homepage, when organic traffic mostly lands on product pages, categories and articles.
• Forgetting third-party scripts, which are often the main cause of poor INP.
• Redesigning without a performance budget and discovering the problem after a migration.
• Expecting immediate results: CrUX data takes up to 28 days to reflect a change.

Conclusion

LCP, INP and CLS measure three things every user notices: whether the page appears quickly, whether it responds when you tap it and whether it stays still while you read. Measure them with real-user data at the 75th percentile, diagnose in the lab and fix the specific cause behind each metric. If your site is failing and you do not know where to start, our technical audit identifies the templates and resources responsible and prioritises the fixes. More terms in our SEO glossary.