The name makes Core Web Vitals sound like engineering territory, but what they measure is the experience a visitor actually has on screen. Each of the three translates into a single sentence.
What each sentence points at
LCP is when the main thing appears — usually the hero image or the big heading. Treat it as the moment a visitor feels the page has arrived. A white screen with the star of the show turning up late reads as “still loading”.
CLS is how much the page jumps while you read it. You start reading, an image above finally loads and shoves the text down; you reach for a button and a banner slides in so you tap the wrong thing. It is the most reliable way to irritate a visitor.
INP is whether it responds when tapped: the pause after you touch the menu and nothing happens. The screen looks finished, so the visitor taps again, and now the state is worse than it was.
Field data and lab tests disagree, and that is fine
This trips up reporting constantly. A speed testing tool says one thing while the report in Search Console says another. They measure different things, so disagreeing is the expected behaviour.
When reporting, state which figure you are quoting first. Lab tests answer immediately when you want to know whether a change helped; field data confirms over time whether real people felt it. Reading both side by side is correct — neither one is the wrong number.
Turning a metric into a request
You do not need to touch the code, but naming the failing metric narrows the request enormously. The three tend to have distinct families of cause, so the metric name alone cuts the search space.
Poor LCP means the main element arrives late, so the ask is to load what the first screen needs before anything else. Poor CLS means something inserts itself after the fact, so the ask is to reserve the space in advance. Poor INP means something is standing between the tap and the response, so the ask is to defer scripts the first screen does not need. Diagnosis belongs to the engineer; those three sentences carry the direction perfectly well.
And do not make the score the goal. The reason to fix these is the same reason you fix a stiff shop door, not the number itself. Chase the score alone and you end up with work that improves the metric while the experience stays exactly as it was.
Causes and remedies per metric continue in the performance archive, and if you would rather hand over measure-fix-remeasure as one job, before-and-after measurement is built into our optimization program.
Next part
With the principles in hand, the remaining task is turning them into a request that moves. Next: how to write one — starting with why “please do some SEO” changes nothing.