Core Web Vitals explained: LCP, INP and CLS in plain English

Most people have left a website because it took too long to appear, ignored their taps or jumped around just as they were about to click something. Core Web Vitals are Google's attempt to measure exactly those frustrations in a consistent way.

This guide explains what each of the three metrics means, what scores to aim for, how to check your own site and which fixes usually make the biggest difference. It is written for business owners and marketers as much as developers, so we keep the technical detail to what you need to have a sensible conversation with whoever builds your site.

What are Core Web Vitals?

Core Web Vitals are a set of three metrics, defined by Google, that measure how a page feels to use:

• Largest Contentful Paint (LCP) measures loading: how quickly the main content appears.
• Interaction to Next Paint (INP) measures responsiveness: how quickly the page reacts when someone clicks, taps or types.
• Cumulative Layout Shift (CLS) measures visual stability: how much the content moves around unexpectedly.

They sit within Google's wider "Web Vitals" initiative, which includes other useful measurements such as Time to First Byte. The three Core metrics are the ones Google considers most important for every site and the ones it reports on in Search Console.

A quick history

The metrics were introduced in 2020. The original responsiveness metric, First Input Delay (FID), only measured the delay before the first interaction was handled. In March 2024 Google replaced it with INP, which looks at interactions across the whole visit. That change caught out many sites that had previously passed comfortably.

The thresholds at a glance

Each metric has three bands. These are the figures Google publishes on its web.dev documentation:

Why the 75th percentile matters

Google does not judge your site on its best visit or its average. It looks at the 75th percentile of page loads, split between mobile and desktop. In simple terms, at least three in four visits need to hit the "good" threshold for that metric to pass.

This matters because averages hide problems. If your site is fast on office broadband but slow on a mid-range phone with a patchy 4G signal, a quarter or more of your visitors may be having a poor time, and that is what gets measured.

Largest Contentful Paint (LCP)

LCP records the moment the largest visible element in the viewport finishes rendering. On most pages that is a hero image, a large heading or a block of text near the top. It is a good proxy for "when does this page look ready?"

Common causes of a slow LCP

• A slow server or uncached pages, so the browser waits too long for the first byte of HTML
• A large, uncompressed hero image
• The hero image being discovered late, for example when it is loaded by JavaScript or set as a CSS background
• Render-blocking stylesheets and scripts in the page head
• Web fonts that delay text from showing

How to improve LCP

1. Serve pages from a fast host with caching or a content delivery network, so the first response arrives quickly.
2. Compress images and use modern formats such as WebP or AVIF, sized for the screen they are shown on.
3. Make sure the main image is in the HTML and give it a high fetch priority so the browser loads it early.
4. Do not lazy-load the image at the top of the page. Lazy loading is great for images further down, not for the LCP element.
5. Reduce or defer CSS and JavaScript that is not needed for the first view.

Interaction to Next Paint (INP)

INP measures the time from a user interaction, such as a click, tap or key press, to the moment the browser shows the visual result. It considers interactions throughout the visit and reports one of the slowest, so a single sluggish menu or form can drag the score down.

A page can look fully loaded and still fail INP. This is common on sites with heavy themes, lots of third-party scripts or complex front-end frameworks, where the browser's main thread is busy and cannot respond straight away.

Common causes of a poor INP

• Large JavaScript bundles running long tasks on the main thread
• Third-party scripts: chat widgets, tag managers, ad scripts, heatmaps and social embeds
• Event handlers that do too much work before updating the screen
• Very large pages with thousands of elements, which take longer to update

How to improve INP

1. Audit third-party scripts and remove any you no longer use. This is often the quickest win.
2. Load non-essential scripts after the page becomes interactive, or only when they are needed.
3. Break long tasks into smaller pieces so the browser can respond to input in between.
4. Give immediate visual feedback on interaction (for example, showing a loading state) and do heavier work afterwards.
5. Keep the page structure lean, especially on long listing or product pages.

Cumulative Layout Shift (CLS)

CLS adds up unexpected movements of visible content during a visit. If you have ever gone to tap a link and hit an advert that suddenly loaded above it, you have experienced layout shift. Movement that happens straight after a user action, such as opening an accordion, does not count against you.

Common causes of a high CLS

• Images and videos without width and height set, so the browser does not reserve space
• Ads, embeds and iframes that load in and push content down
• Cookie banners or promotional bars injected at the top of the page
• Web fonts that swap in at a different size from the fallback font

How to improve CLS

1. Always set dimensions or an aspect ratio on images, videos and embeds.
2. Reserve a fixed space for adverts and dynamic content, even before they load.
3. Show banners as overlays rather than inserting them above existing content.
4. Choose fallback fonts with similar sizing and preload key fonts.
5. Avoid adding content above what the user is already looking at, unless they asked for it.

How to measure Core Web Vitals

There are two kinds of data, and knowing the difference saves a lot of confusion.

Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report (CrUX). This is what Google uses when assessing page experience. It reflects real devices and connections, and it is reported over a rolling 28-day period, so improvements take a few weeks to show.

Lab data comes from a simulated test on a set device and connection. It is repeatable and great for diagnosing problems, but it is not what your visitors actually experience. Lighthouse cannot measure INP directly because there is no real user interacting, so it reports Total Blocking Time as a stand-in.

Smaller sites may see "not enough data" in PageSpeed Insights or Search Console, because CrUX needs a certain amount of traffic. In that case, rely on lab tests and consider a lightweight real user monitoring script.

Do Core Web Vitals affect SEO?

Yes, but less than many people think. Google uses Core Web Vitals as part of its page experience signals, and its own guidance is clear that relevance and quality of content come first. A brilliant, slightly slow page will usually outrank a fast but unhelpful one.

Where they make a difference is in close contests, when several pages answer the query equally well. They also matter for reasons beyond rankings: faster, more stable pages tend to keep visitors engaged and make it easier for them to enquire or buy. If you pay for traffic through ads, a slow landing page wastes some of that spend.

A practical plan for small businesses

You do not need to chase perfect scores. Aim for "good" on all three metrics for your most important templates.

1. Check Search Console. Open the Core Web Vitals report and note which groups of URLs fail and on which metric.
2. Test one example of each template. Home page, service page, blog post, product page. Problems usually come from the template, not individual pages.
3. Fix the cheap wins first. Compress images, set dimensions, remove unused plugins and scripts.
4. Tackle the structural issues. Hosting, caching, theme bloat and JavaScript. This is where a developer earns their keep.
5. Validate and monitor. Use the "Validate fix" option in Search Console and recheck monthly, especially after adding new plugins or tracking codes.

If your site is built on a heavy theme with layers of plugins, there is a limit to how much tuning can achieve. Sometimes a well-built rebuild is the faster route, which is something our website development team handles regularly.

FAQs

What are the three Core Web Vitals?

Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). Google publishes "good" thresholds of 2.5 seconds, 200 milliseconds and 0.1 respectively.

Why does PageSpeed Insights show different results each time?

The lab test runs on simulated conditions that vary slightly between runs, and server response times change too. The field data section is far more stable because it summarises 28 days of real visits.

How long does it take for Core Web Vitals improvements to show?

Field data is based on a rolling 28-day window, so expect up to four weeks before the full effect of a fix appears in PageSpeed Insights and Search Console.

Do Core Web Vitals matter on desktop as well as mobile?

Yes. Google assesses them separately for mobile and desktop. Mobile is usually harder to pass because of slower devices and connections, so start there.

Is INP the same as page speed?

Not quite. Page speed usually refers to loading. INP measures how fast the page responds once someone starts using it, which can be poor even on a page that loads quickly.

If you would like to know where your site stands, request a free audit and we will check your Core Web Vitals and explain the fixes in plain terms, or book a call to talk it through.