Core Web Vitals Explained: LCP, INP & CLS

You’ve heard Google cares about Core Web Vitals. But what are LCP, INP, and CLS actually measuring — and do they really affect your rankings? This guide explains all three Core Web Vitals in plain English: what each metric measures, how to check your scores with free tools, the common fixes for each, and which targets are honestly worth chasing for a small or mid-sized business.

Quick answer: Core Web Vitals are three Google metrics that measure real-world user experience: LCP (Largest Contentful Paint) for loading speed — good under 2.5 seconds; INP (Interaction to Next Paint) for responsiveness — good under 200 milliseconds; and CLS (Cumulative Layout Shift) for visual stability — good under 0.1. They act as a ranking tiebreaker and a conversion driver, measured from real Chrome users at the 75th percentile.

The three vitals, one at a time

LCP Largest Contentful Paint — loading speed

What it measures: how long the largest visible element — usually a hero image, headline block, or video — takes to finish loading. In plain terms: how long until the page looks loaded.

Google’s targets: good under 2.5 seconds; needs improvement 2.5–4 seconds; poor over 4 seconds.

Why it matters: LCP is first-impression speed. A slow hero makes even a great business look sloppy, and bounce rates climb as load time rises. On many sites, fixing images alone moves LCP from poor to good.

Common causes: oversized, uncompressed hero images (the #1 culprit); slow server response on cheap shared hosting; render-blocking JavaScript and CSS; background videos or sliders loading before main content; no caching.

Typical fixes: compress images and serve modern formats like WebP or AVIF, preload the hero image, never lazy-load the hero, move to faster hosting or add caching, and defer non-essential scripts.

INP Interaction to Next Paint — responsiveness

What it measures: how quickly the page visibly responds when a visitor clicks, taps, or types — the delay between interaction and the next visual update. In plain terms: does the site feel responsive, or frozen?

Google’s targets: good under 200 milliseconds; needs improvement 200–500 ms; poor over 500 ms.

Why it matters: INP is the “this site feels broken” metric. A page can load fast and still feel terrible if every click takes half a second to register. It hits conversion hardest on interactive elements — quote calculators, booking widgets, checkout buttons, mobile menus. INP replaced the older FID metric in 2024 because it measures the full interaction experience, not just the first click.

Common causes: heavy JavaScript doing too much per interaction; third-party scripts (chat widgets, trackers, ad pixels) competing for processing time; long tasks blocking the browser; bloated page builders loading far more code than needed.

Typical fixes: reduce and defer third-party scripts, break up long JavaScript tasks, remove unused plugins and code, and be selective about heavy widgets.

CLS Cumulative Layout Shift — visual stability

What it measures: how much the layout unexpectedly shifts while loading. In plain terms: does content jump around after it appears?

Google’s targets: good under 0.1; needs improvement 0.1–0.25; poor over 0.25.

Why it matters: layout shift causes one of the web’s most infuriating experiences — you’re about to tap a button, the page shifts, and you tap an ad instead. It destroys trust instantly. Visitors assume the site is broken or spammy.

Common causes: images and videos without defined dimensions; ads or embeds that load late and push content down; web fonts swapping in after the fallback, reflowing text; popups or cookie banners appearing after load.

Typical fixes: always set width/height (or aspect-ratio) on images and videos, reserve space for ads and embeds before they load, preload key fonts, and make banners overlay content rather than pushing it down. CLS is often the easiest vital to fix — mostly a discipline problem, not a performance problem.

How to check your scores (free tools)

PageSpeed Insights — enter any URL for LCP, INP, and CLS on mobile and desktop, from real user data when available, plus prioritized fix recommendations. Start here.
Search Console → Core Web Vitals report — shows which pages pass or fail site-wide, grouped by issue. This is how you learn whether a problem affects five pages or five hundred.
Chrome DevTools / Lighthouse — for developers diagnosing specific issues. These are simulated “lab data” numbers, so use them for diagnosis, not as your official score.

Test your most important pages first: homepage, top service pages, key landing pages. And expect field data to take about 28 days to reflect fixes — it’s a rolling average of real visits, so don’t panic if scores don’t move the day after a fix.

Realistic targets and priorities

Here’s the honest version most agencies won’t give you:

Perfect scores everywhere aren’t the goal. Chasing 100/100 on every page has diminishing returns. “Good” thresholds on your money pages is the target that moves rankings and revenue.
Fix in order of business impact. Homepage and top-converting pages first. A template-level fix (image handling, font loading) often improves dozens of pages at once — start there.
Mobile first, always. If mobile is poor and desktop is fine, fix mobile. That’s where your visitors — and Google’s judgment — live.
Speed compounds with conversion. Faster pages don’t just rank slightly better; they convert better. Fixing LCP and INP on key pages regularly lifts form completions too.
Re-test quarterly. Scores drift as you add content, plugins, and third-party tools. A site passing in January can fail by July because of three new scripts nobody tracked.

If scores are poor across the board despite fixes, the problem is usually structural — heavy theme, overloaded page builder, or slow hosting — and that’s a web design and development conversation. And remember speed is one piece of a larger picture: great vitals won’t save thin content, and great content can rank with merely decent vitals. See our SEO services for how the pieces fit together.

Frequently asked questions

Do Core Web Vitals really affect rankings?

Yes, but as a tiebreaker, not a primary factor. Among pages with similar relevance and authority, better vitals win. Their bigger impact is usually on conversions — visitors behave measurably better on fast, stable pages, so the revenue case for fixing them is stronger than the rankings case.

Why do my scores differ between tools?

PageSpeed Insights shows real-user field data (a 28-day rolling average) alongside a simulated lab test, and the two often disagree. Trust field data for your official standing; use lab data to diagnose fixes. Always compare like with like — same page, same device type.

Search Console disagrees with my developer. Who’s right?

Search Console, almost always. Developers typically test on fast machines with lab tools, which flatters the numbers. Search Console reflects your actual visitors on actual phones — that’s the data Google uses to judge you.

What’s the most common cause of poor Core Web Vitals?

Oversized hero images are the single most common LCP killer — often lazy-loaded by the theme, which makes it worse. Removing lazy-loading from the hero, compressing it, and adding page caching fixes most LCP problems. For INP it’s usually third-party scripts; for CLS it’s images without dimensions.

How long until fixes show up in my scores?

Field data is a 28-day rolling average of real visits, so expect about four weeks before Search Console reflects a fix. Lab tools like Lighthouse will show the improvement immediately, which is useful for confirming a fix worked — but Google judges you on the field data.