Core Web Vitals explained for small business owners

Open your website on your phone, on a normal mobile connection, and watch it the way a customer would. Does the main content appear quickly, or do you stare at a blank screen? When you tap the menu, does it open at once or after a pause? And does anything jump around while the page loads, moving the button you were about to tap? Those three experiences are exactly what Core Web Vitals measure.

Google introduced Core Web Vitals as a shared language for page experience: three numbers that describe how a page feels to real people. They are not the whole of SEO — good content and relevance matter far more — but they are the part of SEO you can measure precisely and fix systematically. This guide explains each metric in plain English, shows you the thresholds Google publishes, and walks through the fixes in the order that works.

What are Core Web Vitals?

Core Web Vitals are a small set of metrics Google considers essential to a good experience on the web. There are three of them, and together they cover loading, responsiveness and visual stability. Google measures them from real visitors using the Chrome User Experience Report, which collects anonymised timing data from Chrome users who visit your pages. That matters, because it means your score reflects your customers' phones and connections, not your developer's fast office internet.

Each metric is graded at the 75th percentile of page loads, separately for mobile and desktop. In plain terms, at least three out of four visits need to be good before a page counts as good. A page that loads fast for you and slowly for most of your customers will fail, and that is the point: the metric is designed to catch the experience most people actually have.

“Speed is not a technical detail. It is the first thing a customer feels about your business, and it happens before they read a single word.” — Shamim, founder of SerpAstra

The three metrics: LCP, INP and CLS

Largest Contentful Paint (LCP) measures loading. It marks the moment the largest visible element — usually a hero image or a big block of text — has rendered on screen. If your homepage shows a large photo at the top, the LCP is roughly when that photo appears. A slow LCP feels like a blank or half-drawn page.

Interaction to Next Paint (INP) measures responsiveness. It looks at the delay between a tap, click or key press and the next visual update on the page, across the whole visit, and reports a value that most interactions stayed below. A slow INP feels like a button that ignores you: you tap, nothing happens, you tap again, and then everything happens twice.

Cumulative Layout Shift (CLS) measures visual stability. It scores how much visible content moves unexpectedly while the page loads or while you use it. A high CLS is the page that shifts its text down just as you tap a link, sending you somewhere you did not intend to go. It is the most annoying of the three, and often the easiest to fix.

One note for anyone reading older guides: INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID measured only the first interaction; INP measures responsiveness across the whole visit. If a guide still talks about FID as a current metric, it is out of date.

What good scores look like

Google publishes the same thresholds for every site, and they are the same on mobile and desktop. A page is good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. It is poor when LCP is over 4 seconds, INP is over 500 milliseconds, or CLS is over 0.25. Anything in between needs improvement.

To pass Core Web Vitals overall, a page needs all three metrics in the good range at the 75th percentile. Failing one metric means the page fails, even if the other two are excellent. That is why the fix order matters: there is no point polishing CLS on a page whose LCP is five seconds. The thresholds below are taken from Google's own web.dev documentation, which explains how they were chosen and why the 75th percentile is the bar.

How to measure them free

Start with PageSpeed Insights at pagespeed.web.dev. Paste a page URL and you get two kinds of numbers. The field data at the top shows what real visitors experienced over the last 28 days, where your page has enough traffic. The lab data below is a simulated test on a mid-range phone, useful for diagnosis but not the score Google uses.

Then open Google Search Console and look at the Core Web Vitals report. It groups your pages by template and device, and lists the groups that need improvement or are poor. That grouping is the useful part: it tells you whether the problem is one page or a whole type of page. A failing blog template is one fix applied to a hundred pages. A failing single page is a different job.

Two warnings about reading the numbers. First, field data is a rolling 28-day average, so a fix you made yesterday will not show up tomorrow. Second, a lab tool cannot measure INP, because nobody taps anything during a simulated load. Lighthouse reports Total Blocking Time instead, which is a rough proxy for INP, not the metric itself. Judge INP on field data, and use lab data to find what is blocking the page. If you want to watch scores alongside rankings over time, our comparison of the best rank tracking tools for 2026 explains the paid options and what each one measures.

Why your scores differ by page

It is normal for one page to pass and another to fail on the same site. The homepage often has a large hero image and a video, so its LCP is slow. A service page with a booking widget may have a worse INP because the widget loads heavy scripts. A blog post with ads that load late may have the worst CLS of all.

Scores also differ by device. Mobile is almost always worse than desktop: slower connections, weaker processors, smaller screens. Google judges mobile and desktop separately, and for most local businesses mobile is the score that matters, because most customers arrive on a phone. Test mobile first, fix mobile first, and treat a good desktop score as a bonus rather than the goal.

Fixing slow LCP: the loading problem

Most slow LCP comes down to three things: a slow server, a large hero image, or a page that waits for scripts before it shows anything. Start with the server: if it takes more than a second to answer, every page on the site is slow and no image fix will save it. Good hosting and caching are the foundation.

Next, look at the largest element on the page. If it is an image, compress it, serve it in a modern format, and size it to the space it fills — a 4000-pixel photo displayed at 800 pixels is wasted weight. Preload that image so the browser fetches it first, and remove anything that delays it, such as a slider that loads five images before showing one. If the largest element is text, the problem is usually a web font that blocks rendering, so use a system font for headings or make sure the font loads without blocking the text.

Fixing INP: the interaction problem

Slow INP is usually caused by JavaScript: too much of it, or scripts that run long tasks when a visitor taps something. Chat widgets, booking tools, tracking scripts and social feeds all add JavaScript, and each one competes for the same processor on a visitor's phone.

The fix is subtraction before optimisation. Remove widgets nobody uses, and delay the ones that are not needed immediately — a chat widget does not need to load before the page content does. Then ask your developer to break up long tasks so the browser can respond to taps between them. Test on a real mid-range phone afterwards, because a fast laptop hides exactly the problem your customers feel.

Fixing CLS: the layout shift problem

Layout shift happens when the browser draws content and then moves it because something arrived late: an image without dimensions, an ad slot that expands, or a font that swaps in and reflows the text. The fix is to reserve the space in advance.

Give every image and video its width and height so the browser knows how much room to leave. Reserve space for ads and embeds instead of letting them push content down when they load. And choose fonts carefully: a font swap that changes line heights will shift the whole page. CLS is often the quickest win of the three metrics, because it is usually a handful of missing dimensions rather than a deep performance problem.

Do Core Web Vitals affect rankings?

Yes, but modestly. Google has said page experience signals, including Core Web Vitals, are used by its ranking systems, while also saying that relevant, high-quality content matters more. In practice, that means a fast page will not outrank a better answer, and a slow page will not disappear overnight. But when two pages answer a question equally well, the faster, more stable one has the edge — and, more importantly, it keeps the visitors it wins.

The honest way to think about it is as a tiebreaker and a conversion tool, not a ranking trick. The business case for fixing Core Web Vitals is that visitors stay, read and book on a fast site, and leave a slow one. Rankings are the bonus. If you want the wider picture, our technical SEO audit checklist puts speed in context with the other 24 checks that matter, and our guide to how to track your Google ranking shows how to watch the effect over time.

A simple fix order that works

Work in this order and stop when the scores pass. First, fix the server response and hosting, because it lifts every page. Second, fix LCP by optimising the hero image and removing render-blocking delays on your most visited templates. Third, fix INP by removing or delaying third-party scripts. Fourth, fix CLS by adding dimensions to images and reserving space for ads and embeds.

Then wait. Field data updates over a rolling 28 days, so a fix made today shows up gradually, not overnight. Retest after a month, and then check monthly. Scores drift as new content, images and scripts are added, so a site that passes today can fail in six months without anyone noticing. A monthly five-minute check in Search Console is enough to catch that drift early, and if the report shows problems you cannot fix in-house, a one-time SEO audit from SerpAstra — $349 — will map the fixes in priority order. For the bigger question of how long all of this takes to show in rankings, see how long SEO takes to rank.

Sources we checked

1. web.dev — How the Core Web Vitals metrics thresholds were defined: the thresholds, the 75th percentile rule, and how the numbers were chosen.
2. web.dev — Web Vitals overview: definitions of LCP, INP and CLS and the good, needs improvement and poor bands.
3. Google Search Console Help — Core Web Vitals report: how pages are grouped by template and device.
4. PageSpeed Insights (Google) — field data from the Chrome User Experience Report and lab diagnostics.
5. Google Search Central — SEO Starter Guide: page experience in the wider context of ranking.