Core Web Vitals for Business Owners: What LCP, INP and CLS Mean

Core Web Vitals get discussed as an SEO topic, but they're really a plain measure of whether visitors have a smooth or frustrating experience on your site. Google's own documentation defines three specific metrics — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — each measuring a different kind of frustration a slow or unstable page causes. This guide explains each one in plain language, without assuming any technical background.

What Core Web Vitals actually measure

Core Web Vitals are a set of metrics Google publishes to measure real-world page experience — specifically loading speed, responsiveness to interaction, and visual stability. According to Google's current documentation on web.dev, all three metrics should be evaluated at the 75th percentile of page loads, measured separately for mobile and desktop, meaning a page is considered to meet the "good" threshold only if at least 75% of real visits meet that target — not just your best-case load on a fast connection.

Each metric is scored into one of three bands — good, needs improvement, or poor — with specific thresholds published by Google for each. This banding matters because it changes how you should interpret a borderline result: a page sitting just inside "needs improvement" is a meaningfully different problem from one deep in "poor" territory, even though both technically fail the "good" bar, and prioritising fixes accordingly (address the worst offenders first) is usually more productive than chasing a marginal improvement on a page that's already close to passing.

LCP — Largest Contentful Paint: how fast the page feels to load

LCP measures how long it takes for the largest visible content element on the screen — usually a hero image, a large heading, or a banner — to fully render after a visitor starts loading the page. Google's published "good" threshold is that LCP should occur within 2.5 seconds. This matters because LCP correlates closely with a visitor's subjective sense of "has this page loaded yet," even if smaller elements are still loading in the background.

Common causes of poor LCP on small business sites: large, uncompressed hero images, slow server response time, and render-blocking scripts loading before the main content. Compressing images and choosing efficient hosting are usually the highest-impact, lowest-effort fixes.

Modern image formats deserve specific mention here: WebP and the newer AVIF format both typically produce meaningfully smaller file sizes than JPEG or PNG at equivalent visual quality, and are now supported by all major modern browsers, which makes them a low-risk, high-value swap for hero images and other large visual elements specifically. Beyond format, using the HTML <img> element's responsive srcset attribute to serve an appropriately sized image for each device, rather than shipping the same large desktop-sized image to a small mobile screen, is one of the more overlooked LCP fixes on small business sites that were originally built desktop-first.

Want your Core Web Vitals actually measured and fixed, not just explained?

INP — Interaction to Next Paint: how responsive the page feels

INP measures the time between a visitor interacting with the page — clicking a button, tapping a menu, typing in a field — and the page visibly responding to that interaction. Google's published "good" threshold is an INP of 200 milliseconds or less. INP replaced an earlier metric called First Input Delay (FID) as the official interactivity metric, because it captures responsiveness across the entire page visit rather than just the very first interaction.

Poor INP is often caused by heavy JavaScript execution blocking the browser's main thread — commonly from third-party scripts like chat widgets, analytics tags, or ad trackers all loading and running simultaneously. Auditing and reducing unnecessary third-party scripts is frequently the most effective fix.

Because INP is measured across the entire page visit rather than a single moment, it's a genuinely different kind of metric to diagnose than LCP — a page can load quickly and still deliver a poor INP score if, for example, a heavy script keeps running in the background and makes the browser sluggish to respond several seconds after the page first appeared to finish loading. Chrome DevTools' Performance panel can record a real interaction and show exactly which script or task is responsible for a slow response, which is usually more actionable than a synthetic score alone when trying to diagnose a specific INP problem.

CLS — Cumulative Layout Shift: how visually stable the page feels

CLS measures unexpected movement of content on the page as it loads — a button that shifts position just as a visitor is about to tap it, for example, or text that jumps as an image loads in above it. Google's published "good" threshold is a CLS score of 0.1 or less. This is a particularly damaging issue in practice: a shifting layout doesn't just annoy visitors, it causes genuine mis-clicks, including on calls to action or navigation links.

Common causes: images and embedded content (like ads or videos) loading without reserved space, causing surrounding content to jump once they render, and web fonts loading late and causing a visible text reflow.

The fix for most CLS problems is straightforward once identified: explicitly declaring width and height attributes (or an equivalent aspect-ratio in CSS) on every image and embedded element reserves the correct amount of space before the content actually loads, so nothing needs to shift once it arrives. For web fonts specifically, using the CSS font-display: swap property (or an equivalent font-loading strategy) shows a fallback font immediately rather than leaving text invisible, while also minimising the visible size difference when the intended font finally swaps in — a small technical detail, but one that meaningfully reduces the jarring reflow visitors notice on text-heavy pages.

How to check your own site's Core Web Vitals scores

Google provides a free tool, PageSpeed Insights, that reports both lab data (a simulated test) and, where enough real traffic exists, field data drawn from the Chrome User Experience Report reflecting actual visitor experiences. Google Search Console also includes a Core Web Vitals report showing how your indexed pages perform across your whole site, grouped by issue type, which is often more useful than testing individual pages one at a time.

It's worth understanding the distinction between lab and field data clearly, since they can genuinely disagree, and that disagreement is itself informative. Lab data comes from a single simulated test run under controlled, consistent conditions, which makes it excellent for reliably testing whether a specific fix actually helped before and after a change. Field data, by contrast, reflects real visitors on real devices and real network conditions, aggregated over the trailing 28 days, which is what search engines actually use for the "good/needs improvement/poor" assessment tied to page experience. A site with strong lab scores but weaker field data usually points to a real-world condition the lab test doesn't capture — a large share of visitors on older phones or slower mobile connections, for instance — which is worth investigating rather than trusting the lab score alone.

Do Core Web Vitals actually affect search rankings?

Page experience, including Core Web Vitals, is one of many ranking factors Google has stated it considers, but it is not the dominant one — strong, relevant content on a technically poor-performing page will generally still outrank thin content on a fast page. The more reliable framing is that Core Web Vitals affect user experience directly and measurably, and can be a meaningful tiebreaker or a genuine drag on rankings at the margin, rather than a guaranteed ranking boost on their own.

Realistic, prioritised fixes for a typical small business site

1. Compress and properly size images before uploading — this is usually the single highest-impact fix for LCP.
2. Audit third-party scripts — chat widgets, tracking pixels, embedded social feeds — and remove anything not delivering clear value, since these are common INP culprits.
3. Reserve space for images and embeds in your page layout so they don't cause a layout shift when they load.
4. Choose hosting with genuinely fast server response times, since slow server response contributes directly to poor LCP regardless of how optimised the page itself is.

Not sure where your site actually stands on Core Web Vitals? We'll test it and show you exactly what to fix.

Frequently Asked Questions

What are Core Web Vitals?

Core Web Vitals are three metrics Google publishes to measure real-world page experience: Largest Contentful Paint (loading speed), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). Each measures a different type of frustration a slow or unstable page can cause visitors.

What is a good LCP score?

According to Google's published documentation, a good Largest Contentful Paint score is 2.5 seconds or less, measured at the 75th percentile of page loads. This means at least 75% of real visits should meet this threshold, not just a best-case test on a fast connection.

What replaced First Input Delay (FID) as a Core Web Vital?

Interaction to Next Paint (INP) replaced First Input Delay as the official interactivity Core Web Vital, because INP measures responsiveness across an entire page visit rather than only the very first interaction, giving a more complete picture of how responsive a page feels throughout use.

Do Core Web Vitals directly determine my Google ranking?

They are one of many factors Google has stated it considers as part of page experience, but not the dominant one. Strong, relevant content on a technically weaker page will generally still outrank thin content on a technically excellent page. Core Web Vitals matter most as a genuine user experience factor and a potential tiebreaker at the margin, and pairing them with clean structured data supports the same underlying goal of a technically sound, machine-legible site.

What's the easiest way to check my site's Core Web Vitals?

Google's free PageSpeed Insights tool reports both simulated and, where available, real-world field data for any URL. Google Search Console also provides a Core Web Vitals report covering your whole indexed site, grouped by issue type, which is useful for spotting site-wide patterns rather than testing pages individually. Fast checkout pages specifically deserve their own attention, since they often carry heavier scripts than the pages a general audit focuses on — see our guide to checkout UX friction points for the ecommerce-specific detail.