Core Web Vitals in Plain English: What They Measure and How to Fix Them

Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how fast the main content shows up, how quickly the page responds when you tap or click something, and how much it jumps around while loading. They are a minor, confirmed ranking factor, but that undersells why they matter. A page that scores badly on these is also a page that frustrates real visitors, and frustrated visitors leave before they call, buy or fill in a form.

This guide explains each measurement in plain terms, how to check your own site for free, what usually causes a bad score, and how to fix it without hiring a performance specialist for every small change.

The three measurements

• Largest Contentful Paint (LCP) — how long it takes for the largest visible piece of content (usually a hero image or heading) to appear. Google's target is 2.5 seconds or less.
• Interaction to Next Paint (INP) — how long the page takes to visibly respond after someone taps a button, opens a menu or clicks a link. Target is 200 milliseconds or less. This replaced an older metric called First Input Delay in 2024.
• Cumulative Layout Shift (CLS) — how much content unexpectedly moves around while the page loads, for example a button shifting down just as you go to tap it because an image above it finished loading late. Target is 0.1 or less.

How to check your own site for free

You do not need to guess. PageSpeed Insights is Google's own free tool: paste in a URL and it reports your actual Core Web Vitals scores, split into 'lab data' (a simulated test run) and, if the page gets enough traffic, 'field data' (what real visitors on real connections actually experienced over the last 28 days). Field data is the one that matters for search — it is what Google itself uses. Search Console's Core Web Vitals report shows the same field data across your whole site, grouped by which pages have a problem, which is the fastest way to see whether an issue is on one page or site-wide.

What usually causes a slow LCP

• A hero image that is uncompressed, oversized for how it displays, or in an old format (JPEG/PNG instead of WebP or AVIF).
• Slow hosting, or no caching, so every visitor waits on the server to regenerate the page from scratch.
• Render-blocking CSS or JavaScript, and web fonts that load before anything else can appear.
• A third-party script (a chat widget, an ad network, an old analytics tag) that loads early and holds everything up behind it.

What usually causes a bad INP

• A single, large JavaScript bundle that has to finish loading and running before the page can respond to anything, common on sites built with a heavy page-builder or too many plugins.
• Event handlers doing more work than they need to on every click or keystroke — recalculating something expensive instead of only when it actually changes.
• Too many third-party scripts competing for the browser's attention at once (chat widgets, popups, multiple ad networks, several analytics tools).

What usually causes layout shift

• Images and embedded videos with no width and height set in the code, so the browser does not reserve space for them and everything below jumps down once they load.
• Ads, banners or cookie notices that inject themselves into the page after the initial content has already rendered.
• Web fonts that visibly swap in and change the size of the text, shifting everything below it.
• Content injected by JavaScript above things the visitor is already reading or about to click.

Fixes, roughly in order of impact

1. Compress and correctly size every image, and serve modern formats (WebP or AVIF) instead of plain JPEG or PNG. This is usually the single biggest lever for LCP.
2. Set an explicit width and height (or aspect-ratio) on every image and embed, so the browser reserves the right amount of space before it loads.
3. Remove scripts, plugins and trackers you no longer actually use. Every one you keep is bytes the browser has to download and run before it can respond quickly.
4. Load anything non-essential — chat widgets, marketing pixels, secondary fonts — after the main content, not before it.
5. Use caching and, if your visitors are spread across regions, a content delivery network so the server is not rebuilding the same page from scratch for every visitor.
6. Re-test with PageSpeed Insights after each change. Fixing one cause can reveal the next one underneath it.

Do not chase a perfect score

A 100/100 lab score is not the goal, and chasing one can waste time that would matter more spent elsewhere. The actual goal is passing Google's thresholds on field data — the real-world experience — for the pages that matter most: your homepage, your main service or product pages, and whatever page people usually land on from search or ads. A site that comfortably passes on those pages, with an occasional slower internal page, is in good shape.

Where Cloud9 fits

We build every new site with these thresholds in mind from the start — correctly sized images, minimal third-party scripts, fonts and layout that do not shift — rather than trying to fix it after the fact. If your current site is failing Core Web Vitals, we can audit it, tell you exactly which pages and which cause, and fix it. See our web development and SEO services, or start with a free SEO analysis.