Core Web Vitals explained for people who do not write code

Google has told every website owner exactly what it wants for years now. Fast pages. Stable layouts. Quick responses. It packaged those three requirements into a set of numbers called Core Web Vitals, and most business owners have never actually looked at their own score. That is worth fixing, because these numbers sit inside Google's ranking systems and directly affect whether a visitor stays on your site or leaves before reading a word.

The three numbers Google actually measures

Core Web Vitals is not one score, it is three separate metrics, and each one measures a different kind of frustration a visitor can hit on your site.

INP is the newest of the three. Google retired the older First Input Delay metric in March 2024 and replaced it with INP, because FID only measured the delay before a visitor's very first click or tap. INP tracks every interaction across the whole visit. A page that felt fast on the first click but sluggish after that used to pass FID easily. It will not pass INP.

Why this matters beyond your Google ranking

Core Web Vitals started life as an SEO signal, but the ranking impact is the smaller half of the story. A slow or jumpy page is not quietly losing you rankings in the background, it is losing you the visitor who is on the page right now, before your pitch even loads.

What usually causes a bad score

• Unoptimised images loading at full camera resolution instead of the size the page actually displays
• Third-party scripts, like chat widgets, ad tags and tracking pixels, that block the page while they load
• Web fonts that swap in late and shove the text down the page
• Images, ads or embeds with no set width and height, so the layout jumps once they load
• Cheap or oversold hosting that queues requests during busy periods

That last point about hosting deserves its own mention. We wrote about the real cost of cheap hosting recently, and it comes up in nearly every Core Web Vitals audit we run for a client. You can compress every image on a page and still fail LCP if the server itself takes two seconds just to respond to the request.

How to check your own scores

Two free tools give you the real numbers, not a guess. PageSpeed Insights shows a lab test plus, if the site gets enough traffic, real visitor data pulled from the Chrome User Experience Report. Search Console's own Core Web Vitals report groups your actual pages into Good, Needs Improvement and Poor, using the same real-visitor data Google uses when it ranks you. Run both. The lab test tells you what is technically wrong. The field data tells you whether it is actually costing you visitors.

Fixing it without a full rebuild

Most sites do not need a rebuild to move from Poor to Good. Compressing and correctly sizing images fixes LCP more often than anything else we touch on a technical audit. Setting explicit width and height on every image and embed fixes CLS in an afternoon, not a sprint. INP is the hardest of the three because it usually means auditing which scripts are running on the page and deferring anything that is not needed in the first few seconds, but even removing one bloated chat widget can pull a page from Poor into Needs Improvement overnight.

We build structured data and Google Business Profile fixes into the same technical pass as Core Web Vitals work, because they come from the same audit and none of them are worth doing in isolation. If your SEO work is not backed by a fast, stable site, you are asking Google to rank a page that its own algorithm is already marking down.