Honestly: nobody wakes up in the morning thinking about their LCP. Your visitors certainly don’t. They think: Why can’t I see anything yet? Why doesn’t this button react? Why did the text jump away the exact moment I tried to tap it?
That is precisely what these acronyms measure. Each one answers a question a visitor actually asks. There is nothing more to it. Let’s walk through them, in plain language.
Five acronyms, five questions
TTFB: is anything happening at all?
Time to First Byte. The time from the request to the first byte your server sends back. Until then, the browser does: nothing. A bad TTFB drags everything else down, because the browser cannot render what it has not received. As a rule of thumb: up to 800 ms counts as good.
FCP: when do I finally see something?
First Contentful Paint. The moment the browser paints content for the first time. A piece of text, a logo, anything. Before that, the page is simply blank. FCP is your page’s first sign of life. Good means: up to 1.8 s.
LCP: when do I see the thing I came for?
Largest Contentful Paint. The moment the biggest visible element has finished rendering: the hero image, the video poster, the big headline. From this point on, the page feels “there”. Google’s thresholds: up to 2.5 s is good, above 4.0 s is poor. A lot of everyday reality sits in between.
INP: why is this button janky?
Interaction to Next Paint. The worst-case delay between a tap or click and the next visible frame. When visitors click twice because “nothing happened”: that is INP. Up to 200 ms is good, above 500 ms is poor. INP replaced FID as a Core Web Vital in March 2024.
CLS: why does everything jump around?
Cumulative Layout Shift. It scores how much visible content moves unexpectedly. The classic: a banner loads late, the text slides down, you hit the wrong link. CLS is not a time, it is a score: up to 0.1 is good, above 0.25 is poor.
Note: Strictly speaking, only three of these are Core Web Vitals: LCP, INP and CLS. FCP and TTFB are diagnostic metrics. They explain why the big three look the way they do.
Lighthouse says 95. People still complain.
Both can be true at the same time, and that confuses everyone at first.
Lighthouse is a lab test: a simulated device, one location, ideal conditions, fully reproducible. That is exactly what it is good at. Because the conditions never change, it catches regressions before they go live. But the test knows nothing about the three-year-old Android on a cellular connection that is opening your page right now.
Field data measures exactly that: every real page view, on real devices, on real networks. That is what Real User Monitoring, RUM for short, means. Noisier than the lab, yes. But real.
And because field data scatters, you don’t look at the average. You look at the 75th percentile, p75 for short. p75 means: 75% of your visitors were at least this fast. The average flatters you. p75 shows you the experience of the people who suffer.
One more detail: INP is a field-only metric. A lab test does not click like a human, so INP comes from the field, not from the lab.
Why Google takes this seriously
Google ranks by the real Core Web Vitals of Chrome users, collected in the Chrome UX Report (CrUX). Not by your Lighthouse score. Your lab can say 95 and your field can say something entirely different, and for your ranking, the field wins.
The logic is simple: Google wants to link to results that feel good, on the devices people actually use. You can call that strict. Unfair it is not.
What to do with all this
Don’t start with the score, start with the questions. Do your visitors see something quickly? Does the page react to the first click? Does the layout stay put? To answer those, you need numbers from real visitors, judged at the p75 instead of the average.
That is exactly what fastmon does: the Core Web Vitals from every real visit, at the p75 against Google’s thresholds. If you want to see what that looks like: More about Real User Monitoring.
From now on, these are not buzzwords anymore. Promise.