---
title: "Core Web Vitals in Plain English (LCP, INP, CLS)"
description: "LCP, INP and CLS explained without the jargon — what each Core Web Vital measures, what counts as a good score, and what to do about yours. For marketers, not developers."
url: https://www.agiledigitalagency.com/blog/core-web-vitals-explained/
date: 2026-06-17
modified: 2026-06-17
author: "Agile Agency"
image: https://www.agiledigitalagency.com/wp-content/uploads/2026/06/core-web-vitals-plain-english.jpg
type: blog
lang: en
---

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

If you’ve seen “Core Web Vitals” flagged in a report or an SEO audit and quietly wondered what LCP, INP and CLS actually mean — without wanting a developer’s lecture — this is for you. They’re simpler than they sound, and you don’t need to fix them yourself. You just need to understand what they measure, what counts as good, and what to ask the people who look after your site.

## What Core Web Vitals are

Core Web Vitals are three metrics Google uses to measure the real-world experience of loading and using a web page: how quickly the main content appears (LCP), how fast the page responds when you interact with it (INP), and how stable the layout stays as it loads (CLS). Together they describe whether a page feels quick and solid, or slow and awkward, to an actual visitor.

Two things make them worth your attention. First, Google uses them as part of how it ranks pages, so they affect how easily people find you. Second — and more importantly — they measure the experience your prospective clients actually have, which is the thing that turns a visit into an enquiry. Let’s take each one in turn.

## LCP — how fast the main content loads

Largest Contentful Paint (LCP) measures how long it takes for the biggest, most important thing on the page — usually the main heading or hero image — to appear. A good LCP is 2.5 seconds or less.

Think of it like walking into a shop and waiting for the lights to come on. If the main display is lit and visible almost immediately, you feel welcome and oriented. If you’re left standing in the dark for four or five seconds, you start to wonder whether anyone’s home — and you might just walk back out. LCP is that first “the page is here” moment, and slow servers or oversized images are the usual reasons it drags.

## INP — how quickly the page responds when you interact

Interaction to Next Paint (INP) measures how quickly the page reacts when a visitor does something — clicks a button, opens a menu, ticks a box. A good INP is 200 milliseconds or less, which is about as fast as the eye perceives as instant.

Picture pressing a lift button. Press it and the light comes on at once, and you relax: the building heard you. Press it and nothing happens for half a second, and you press again, unsure if it registered. A laggy contact form or a menu that hesitates creates exactly that small, corrosive doubt — and it tends to strike at the worst moment, right when someone is trying to act.

One thing worth knowing, because it dates a lot of older advice: INP replaced an earlier metric called FID (First Input Delay) as an official Core Web Vital in March 2024. FID only measured the delay on a visitor’s very first interaction; INP looks at responsiveness across the whole visit, so it’s a truer reflection of how the page feels. If a guide or a tool still talks about FID as current, it’s out of date.

## CLS — whether the layout jumps around as it loads

Cumulative Layout Shift (CLS) measures how much the page moves around unexpectedly while it loads. A good CLS is 0.1 or less — the lower the number, the more stable the page.

You’ve felt bad CLS even if you’ve never named it: you go to tap a link, an image or advert loads in above it, everything jumps down, and you tap the wrong thing. It’s the digital equivalent of someone moving your chair as you sit down. On a professional site it reads as sloppy, and on a form or a call-to-action it can cost you the click you most wanted. Good CLS usually comes down to reserving the right space for images and elements before they load.

## Lab data vs real-user data

There are two ways these metrics get measured, and knowing the difference explains why your monthly report and a quick one-off test often disagree. Lab data is a single test run in controlled conditions — useful for diagnosing problems, but it’s one simulated visit, not real people. Field data is the experience of your actual visitors, collected from real Chrome users over the previous 28 days.

Google judges your Core Web Vitals on field data, and it uses the 75th percentile — meaning roughly three-quarters of real visits need to hit the “good” threshold for the page to pass. That’s why a site can look fast when you test it on a good laptop and a fast connection, yet still fail in the field, where plenty of visitors are on mid-range phones and patchy mobile signal. The honest test is how it performs for them, not for you. (For the bigger picture on measuring a site honestly, see our [complete guide to website performance for B2B firms](/blog/website-performance-b2b-guide/).)

## What to actually do with this

Here’s the reassuring part: you are not meant to fix these yourself. LCP, INP and CLS are technical outcomes of how a site is built and hosted, and the fixes belong with whoever looks after it. Your job is simply to know enough to ask the right questions and recognise a straight answer.

Three questions get you most of the way:

1. **“Are we passing Core Web Vitals on field data, not just a lab test?”** This separates a real pass from a flattering one-off score.
2. **“Which of the three are we failing, and why?”** A good provider can tell you plainly — e.g. slow LCP from heavy images, or poor INP from too much code running.
3. **“What’s the plan to fix it, and will it stay fixed?”** A one-off tune-up fades; you want performance that’s built in and maintained.

Very often the underlying culprit is the same one: a site built on a heavy page builder loads so much extra code that good scores are hard to reach and harder to hold. We’ll unpack that in *→ Cluster 3: why page builders like Elementor and Divi hurt performance (not published yet)*. And if you want the case for why any of this is worth your time, that’s in [what a fast website actually does for your business](/blog/what-a-fast-website-does-for-your-business/).

**[Not sure where your site stands? We’ll check it for you →](/services/premium-web-subscription/)**

## Frequently asked questions
