Someone sent you a report on your website: a red circle, a 38 out of 100 and three acronyms, LCP, INP and CLS. They say your site "failed." You can't tell whether that's serious or just noise.
Of the three, usually only one explains why your website feels slow, and it almost always comes down to the same cause. Here's what each acronym measures, which one it is, how to run the test yourself in two minutes and when a red number actually matters.
What Core Web Vitals are
Core Web Vitals are three measurements of what people go through when they open your page. Google says its ranking systems use them.
They're measured on real visits from people using Chrome. To pass, at least three out of every four visits have to land in the green on each of the three. Phones and computers are scored separately (web.dev).
The three, in terms of what your client goes through
| Acronym | What it measures | Good | Poor |
|---|---|---|---|
| LCP | The wait to see the main content | 2.5 seconds or less | Over 4 seconds |
| INP | The wait after you tap something | 0.2 seconds or less | Over 0.5 seconds |
| CLS | How much the content moves | 0.1 or less | Over 0.25 |
Anything in between "needs improvement." These are the thresholds from web.dev, Google's documentation for people who build websites: LCP, INP and CLS. If your report shows INP in milliseconds, 200 ms is 0.2 seconds.
LCP (Largest Contentful Paint, roughly "when the biggest thing shows up"). You open the site on mobile data and see the menu, a gray box and nothing else. The time it takes for that box to fill with the main photo or headline is the LCP.
INP (Interaction to Next Paint, "from your tap to the screen responding"). You tap "See prices," nothing happens, so you tap again. That wait is the INP. It's tracked across the whole visit and generally reports the worst one.
CLS (Cumulative Layout Shift, "how much the layout slides around"). You go to tap "Call," something loads above it, everything drops and you hit something else. It isn't measured in seconds: it's a score where 0 means nothing moved.
If your report still mentions FID, it's an old template: Google replaced it with INP in March 2024.
The one that usually explains the slowness: LCP
When you say your website is slow, you mean one of two waits: waiting to see it, or waiting for it to react. CLS doesn't measure a wait at all. A site can have a red CLS and still open instantly.
Between the other two, the data points to LCP. The 2025 Web Almanac, HTTP Archive's yearly report on the state of the web, found this on phones, using Chrome data from July 2025:
- Good LCP: 62% of sites.
- Good INP: 77%.
- Good CLS: 81%.
Nearly four in ten sites fail LCP on phones. On desktop, INP is good on 97% of them. If your site feels slow, the odds are it's the wait at the start.
And it almost always has the same cause
On 76% of pages measured on phones, the biggest thing at the top is an image (2025 Web Almanac): the cover photo, the banner, the first slide of the carousel. So LCP is almost always timing that photo.
The surprise is why it's late. Google split LCP into four parts and measured each one, with Chrome data, on sites with poor LCP. The typical values:
| Part | What's happening | Typical time |
|---|---|---|
| Server response | The browser waits for the page | 2.27 s |
| Delay before requesting the photo | The page is here, the photo hasn't been requested | 1.29 s |
| Photo download | The photo comes down | 0.35 s |
| Render | The photo is in, it still has to be shown | 0.36 s |
That's the cause that keeps coming back: the main photo shows up late, and hardly ever because of its file size. It's late because the browser takes too long to be able to ask for it. The two waits before the download add up to roughly three and a half seconds; the download itself takes a third of a second. The study's own conclusion: image download time is almost never the bottleneck.
What's usually behind it, according to Google's guide to optimizing LCP:
- The server is slow to respond. Chained redirects, a platform weighed down by plugins that builds every page from scratch, or a server far from your client (web.dev).
- The browser finds the photo late. This happens when a carousel builds itself after the page loads, when the photo is set as a background, or when it's lazy loaded, which makes an image wait until you scroll near it. The guide is blunt: never lazy load your LCP image. Even so, one in six pages does (2025 Web Almanac).
- The photo is too heavy. In the data that's the exception, but if you uploaded it straight from your phone, yours might be it. We cover that in heavy photos, slow website.
How we measure and fix it ourselves is on our website optimization page.
How to run the test yourself in two minutes
- Go to pagespeed.web.dev, paste the address of the page that matters most to you, such as the one your ads point to, and click Analyze. Stay on Mobile.
- The top section is real users. That's the verdict, based on the last 28 days. Check which of the three isn't green.
- If there's no data for your page up there, it doesn't get enough visits, so Google shows data for your whole site, or none at all. That's normal for a small business. For at least a clue, the automatic review on our homepage measures from the outside how long your server takes to respond, the first part of LCP.
- The bottom section is the lab: the 0 to 100 number inside the circle. It's a single simulated load, on one phone with a fixed connection (Google). It helps you find the cause; the verdict is the part above.
- Look for "LCP breakdown." It tells you which element is your LCP and which part is eating the time. Nearby, "LCP request discovery" flags whether the photo is lazy loaded.
Which numbers are worth chasing, and which one isn't
Worth it: all three green with real users, on mobile, on the pages that bring you clients. If you're going to start with one, make it LCP.
Not worth it: the 100 in the circle. The documentation for Lighthouse, the tool behind that number, says a perfect 100 is extremely hard to reach and not expected. It also moves from one run to the next. And Google warns that chasing a perfect score just for SEO may not be the best use of your time.
When a low score doesn't matter, and when it does
It matters little if the circle is red but real users pass: your clients are already getting a good experience. It doesn't weigh much on a page almost nobody visits, either. And it won't sink you on Google if you're the best answer: Google says it always tries to show the most relevant content, even when the page experience is subpar.
It matters in these cases:
- Red LCP on the page your ads send people to. You've already paid to bring that person in, and they leave before the photo appears.
- You're up against businesses that are just as relevant. That's where, according to Google, a good page experience can help.
- Red CLS next to call, booking or payment buttons. Someone is going to tap the wrong one.
- Red INP on a form or a catalog with filters. The page looks broken even when it isn't.
Three questions for whoever sent you the report
Which of the three fails with real users, on mobile? What's the LCP element, and which part is taking the time? What will you change, and how will we measure it afterwards? If all they talk about is the number in the circle, it's a lab report, and it doesn't yet tell you what your clients go through.
If you got a report you can't make sense of, message us on WhatsApp with your page's link: we'll tell you which of the three is holding it back, why, and what it costs to fix.