Core Web Vitals explained: what LCP, INP and CLS mean for your business

Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors. Largest Contentful Paint (LCP) is how quickly the main content appears; Interaction to Next Paint (INP) is how quickly the page reacts when someone taps or clicks; Cumulative Layout Shift (CLS) is how much the layout jumps while loading. The “good” targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, met by at least 75 % of real visits. They are a modest ranking signal, but a big customer signal: slow, laggy, jumpy pages lose enquiries and sales long before Google notices.

This guide explains each metric without jargon, how to check yours properly, what usually causes a fail, what fixing it costs, and when it is cheaper to rebuild.

The three metrics at a glance

The thresholds are published by Google on web.dev. A page passes when the 75th percentile of visits meets the “good” threshold for all three, with mobile and desktop assessed separately. Put simply, three out of four visitors must get a good experience, including people on older phones and patchy signal.

Largest Contentful Paint: has it loaded?

LCP records when the largest image or text block in the visible area finishes rendering. On most business sites that is the hero photo, or the main headline on a text-led page. Google breaks LCP into four parts, which is useful when diagnosing it:

• Time to first byte: how long the server takes to start responding. Slow hosting and no caching show up here.
• Resource load delay: how long before the browser even starts fetching the hero image. Lazy-loading the hero, or setting it as a CSS background, makes this worse.
• Resource load duration: how long the image takes to download. A 3 MB JPEG straight from a camera is the usual culprit.
• Render delay: time spent waiting for CSS, fonts and JavaScript before the element can be painted.

Interaction to Next Paint: does it respond?

INP replaced First Input Delay as a Core Web Vital in March 2024. It looks at every tap, click and key press during a visit and reports one of the slowest. A poor INP is the menu that takes a beat to open, or the “Add to basket” button that seems to ignore you, so people tap it twice. The delay is almost always JavaScript: the browser is too busy running scripts to respond.

Cumulative Layout Shift: does it stay still?

CLS measures unexpected movement. You have felt it when you go to tap a link and an image or banner loads above it, pushing everything down so you tap the wrong thing. It is a score rather than a time, and lower is better. Movement caused directly by the user, such as opening an accordion, does not count.

Why they matter to a business

Search

Core Web Vitals are part of Google’s page experience signals. Google is clear that relevant, helpful content matters more and that great vitals will not lift a weak page. In practice they act as a tie-breaker where competing pages are similarly relevant, which is common in crowded local and service searches: emergency plumbers in Manchester, accountants in Leeds, dentists in Bristol.

Customers

The bigger effect is on people. Ofcom’s research has shown for years that smartphones are the device UK adults use most to go online, and a lot of that browsing happens in poor conditions: on a train between Birmingham and London, in a shop with one bar of signal, on a three-year-old Android. Core Web Vitals field data is collected from exactly those visits, which is why a site that feels quick on your office broadband can still fail.

How to check your Core Web Vitals properly

PageSpeed Insights

Paste a page address into Google’s PageSpeed Insights. The top section is field data: real Chrome users over the previous 28 days, from the Chrome UX Report, shown for that URL if it has enough traffic and for the whole origin (your domain) otherwise. Below it is a Lighthouse lab test on a simulated mid-range phone, with a score out of 100 and a list of diagnostics.

Google Search Console

The Core Web Vitals report groups your URLs into good, needs improvement and poor, using field data. It is the best way to see patterns across a site, for example every product page failing CLS because of one template.

Field data versus lab data

Two practical points follow. A Lighthouse score of 95 does not guarantee passing field data, though it makes it much more likely. And after you fix something, the field numbers take up to four weeks to reflect it, so don’t panic when Search Console still shows red the next day.

A typical audit, worked through

Here is the pattern we see most often on a five-year-old WordPress brochure site built with a page builder. The figures are representative of what we find, not a specific client.

The fixes: resize the hero to around 1,600 px wide and serve it as WebP or AVIF, stop lazy-loading it and preload it; switch on page caching and put the site behind Cloudflare; remove the slider; delay the chat widget until the visitor interacts; move tags behind consent; overlay the cookie banner; set width and height on every image; preload the main font. That is roughly 8 to 12 hours of work on a site like this. Results vary, and some sites need deeper work, but this is the common case.

What usually causes a fail, and the fix

For WordPress specifically, our guide to speeding up WordPress walks through twelve fixes in detail. Cookie banners are a frequent CLS and INP offender; see our UK cookie banner guide for how to get one that is compliant and light.

Why some sites never pass

The underlying problem is usually weight. Page-builder themes load large amounts of CSS and JavaScript on every page whether it is used or not, and each plugin adds its own scripts on top. You can optimise around that for a while, but at some point you are spending more on workarounds than a lean rebuild would cost.

That is why we hand-build classic WordPress themes without page builders and target Lighthouse 95+ and WCAG 2.2 AA on every template. Speed designed in from the start is cheaper than speed rescued later. Core Web Vitals sit alongside accessibility, structured data and content quality in our list of what a business website needs in 2026.

What it costs to fix

The bank prices include our volume discounts: 10 hours is £500 − 5 % = £475, 20 hours is £1,000 − 15 % = £850, both before 20 % VAT, and hours never expire. You can book hours online. If a rebuild makes more sense, compare our fixed-price packages: the Pro Website at £750 + VAT covers ten pages with a CMS, which is often less than chasing a heavy theme for 20 hours. Hosting, caching and CDN set-up fall under our DevOps services, and new builds under web development.

Your Core Web Vitals checklist

• Check field data for your key templates (home, service, product, contact) in PageSpeed Insights, on mobile first.
• Open the Core Web Vitals report in Search Console and look for templates that fail together.
• Resize and preload the hero image; never lazy-load it.
• Set width and height on all images, videos and embeds.
• List every third-party script and remove or delay anything not earning its place.
• Overlay cookie banners and notices rather than pushing content down.
• Turn on page caching and a CDN.
• Re-test in the lab straight away, then check field data again after 28 days.

Our team is based in St Albans and works with businesses across the UK. If your scores are in the red, send us the address and we will tell you honestly whether it is a few hours of fixes or time for a leaner site.

Photo: Drew Beamer via Unsplash