Core Web Vitals Explained in Plain English (LCP, INP and CLS)

If you've ever run your website through Google's PageSpeed Insights, you've probably seen a wall of acronyms, a few red or orange numbers and the words "Core Web Vitals assessment: Failed". It's not obvious what any of it means, whether it matters, or what to do next.

This guide explains the three Core Web Vitals in plain English, what "good" looks like for each, how to check your own site, and which fixes usually make the biggest difference. No marketing fluff, and no promises that a green score will put you at the top of Google.

What Core Web Vitals are (and aren't)

Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor:

1. Loading: how long until the main content shows up.
2. Responsiveness: how quickly the page reacts when someone taps or clicks.
3. Visual stability: how much the page jumps around while it loads.

They're measured from real Chrome users visiting your site, not from a lab test, and Google publishes the targets on web.dev.

What they aren't is a magic ranking lever. Google says plainly that Core Web Vitals are used by its ranking systems, but also that good scores don't guarantee top rankings and that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." In practice, speed helps most when you and your competitors are otherwise similarly useful, and it helps conversions regardless of search: people who wait, mis-tap or lose their place leave.

The three metrics at a glance

Two details matter when you read these numbers:

• Google looks at the 75th percentile. To "pass", three out of four visits need to hit the target. A fast result on your office Wi-Fi doesn't count for much if a quarter of your visitors are on a phone with patchy 4G.
• Mobile and desktop are assessed separately. Most small-business sites do fine on desktop and fail on mobile, which is usually where most of their visitors are.

LCP: "has the page shown up yet?"

Largest Contentful Paint measures when the largest visible element finishes rendering. On most sites that's the hero photo, a banner image, a video poster or the main heading. Google's LCP guide lists the elements that count.

Plain English: it's the moment a visitor feels the page has loaded.

Common causes of a slow LCP:

• A huge hero image (a 4 MB photo straight off a camera or stock site).
• The hero image being lazy-loaded, so the browser deliberately waits to fetch it.
• Slow hosting or no caching, so the server takes a second or more just to start responding.
• Render-blocking scripts and stylesheets from plugins, chat widgets and trackers loaded before anything else.

The fixes are usually unglamorous. Resize and compress the image, serve a modern format such as WebP or AVIF, and tell the browser it's important:

<!-- The hero image: load it eagerly and at high priority -->
<img
  src="/images/hero-1600.webp"
  srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  fetchpriority="high"
  alt="Our workshop on the Central Coast">

Keep loading="lazy" for images further down the page, not the one at the top. Lazy-loading the LCP image is a common self-inflicted slowdown, and some themes and page builders do it to every image by default.

INP: "did my tap do anything?"

Interaction to Next Paint replaced the older First Input Delay metric as a Core Web Vital on 12 March 2024. FID only measured the delay before the first interaction started being handled. INP looks at the interactions across the whole visit and reports one of the slowest, measured all the way until the screen actually updates. It's a much tougher and more honest test. See Google's INP guide for the full definition.

Plain English: when someone taps "Menu", "Add to cart" or a form field, does the page react straight away, or does it freeze for a moment?

Poor INP is almost always a JavaScript problem. The browser can only do one thing at a time on its main thread, so if a script is busy, your visitor's tap waits in the queue. Typical culprits:

• Heavy page builders and sliders that run a lot of code on every interaction.
• Third-party scripts: chat widgets, heatmaps, multiple analytics and ad tags, review carousels.
• Large single-page apps that re-render big chunks of the page on every click.

If you have your own code, the general fix is to do less work per interaction and break long tasks up so the browser can paint in between. For example, show the response first and defer the non-urgent work:

button.addEventListener("click", async () => {
  // 1. Do the visible part immediately
  showSpinner();

  // 2. Let the browser paint before doing heavier work
  await new Promise((resolve) => setTimeout(resolve, 0));

  // 3. Then do the expensive, non-visual work (analytics, recalculations, etc.)
  sendAnalytics();
  recalculateTotals();
});

Newer versions of Chrome also support scheduler.yield() for the same purpose, but setTimeout works everywhere. On a WordPress or builder site, the bigger win is usually removing or delaying scripts you don't need.

CLS: "stop moving!"

Cumulative Layout Shift measures how much visible content moves unexpectedly. You've felt this when you go to tap a link and an ad or banner pushes it down, so you tap the wrong thing. CLS is a unitless score rather than seconds. Google's CLS guide explains how it's calculated: shifts are grouped into bursts, and your score is the worst burst.

Common causes, all of which Google lists:

• Images and videos without a width and height, so the browser can't reserve space.
• Ads, embeds and widgets that resize themselves after loading.
• Cookie banners or promo bars injected at the top of the page, pushing everything down.
• Web fonts that render at a noticeably different size from the fallback font.

Fixes:

<!-- Always give media dimensions (or an aspect ratio) -->
<img src="/team.webp" width="1200" height="800" alt="The team">

/* Reserve space for an embed that loads later */
.map-embed { aspect-ratio: 16 / 9; }

/* Overlay banners instead of pushing content down */
.cookie-banner { position: fixed; bottom: 0; left: 0; right: 0; }

Shifts that happen within half a second of a visitor's own click (opening an accordion, for example) don't count against you, because they're expected.

How to check your own site (free)

You don't need paid tools to find out where you stand.

1. PageSpeed Insights. Paste in your URL. The top section ("Discover what your real users are experiencing") is real-visitor field data from the past 28 days. The section below it is a one-off lab test from Lighthouse. Google's pass/fail is based on the field data, not the lab score.
2. Google Search Console. If you've verified your site, the Core Web Vitals report groups your pages into Good, Needs improvement and Poor, for mobile and desktop.
3. Chrome DevTools. For developers, the Performance panel shows live LCP, INP and CLS as you click around your own site.

A few things that trip people up:

• "No data" in the field section is common for small sites. Field data comes from the Chrome User Experience Report, which only includes pages and sites with enough Chrome traffic. If you see no field data, use the lab results as a guide and focus on the fixes above.
• The 0–100 Lighthouse score is not Core Web Vitals. It's a lab score that blends several metrics. Lighthouse also can't measure INP because nobody is clicking; it uses Total Blocking Time as a stand-in. A green field assessment with a 70 lab score is fine. The reverse is the one to worry about.
• Changes take time to show. Because field data is a rolling 28 days, a fix you make today will take a few weeks to fully show up.

What to fix first

If your site is failing, this is the order we'd usually work through, from most to least bang for buck:

1. Images. Resize, compress and convert to WebP or AVIF, add width and height, and stop lazy-loading the hero. This alone fixes a lot of LCP and CLS failures.
2. Third-party scripts. List every script your site loads. Remove the ones nobody looks at (old pixels, abandoned heatmaps), and load the rest after the page has rendered.
3. Hosting and caching. Cheap shared hosting with no page caching or CDN often adds a second before anything happens. A static or edge-cached site removes most of that.
4. Fonts. Use one or two font files, self-host them and preload the main one, and consider font-display: swap with a size-matched fallback.
5. Theme or rebuild. If a heavy theme or page builder is the root cause, there's a point where patching costs more than rebuilding on something lighter. We covered the cost side of that in what a website costs in Australia.

Does it really matter for a small business?

For most local service businesses, the honest answer is: it matters, but not for the reason SEO forums suggest. Relevance, good content and a solid Google Business Profile will move your rankings more than shaving 300 ms off LCP. Where Core Web Vitals matter is the visitor who did find you: if your site takes five seconds to show anything on their phone, or the "Call now" button jumps as they tap it, a fair share of them will hit back and call the next result instead.

So treat the targets as a checklist for a site that doesn't get in the way, not as a score to chase. Pass all three on mobile, then spend the rest of your effort on content and calls to action.

If you'd like a second pair of eyes, our Tech Audit includes a performance and Core Web Vitals review with a written report ranked by impact, and our website services cover fixes or a rebuild if that turns out to be the better option. Happy to take a look; just get in touch.