Core Web Vitals 2026: what Google actually measures

Core Web Vitals are three metrics Google collects from real visitors to your website: not in a lab, but on their phones and connections. That's exactly why results from testing tools often differ from what you see in Search Console.

Here's what each of the three means, what most often breaks it and in what order it pays to fix them.

LCP: how fast the main content appears

LCP measures when the largest element in the visible part of the page appears, usually the header image or a large headline. The threshold for a good score is 2.5 seconds.

The culprit is almost always an image. Too large in dimensions, in an old format, without a set size, or loaded only after everything else. Fixes in order of impact: resize the image to the size it is actually displayed at, save it as WebP or AVIF, give the main image fetchpriority="high" and never give it loading="lazy".

The second common cause is a server that takes too long to respond. If the first byte arrives after more than half a second, images won't fix anything; the problem is lower down, in the hosting or in plugins that build the page on every visit.

INP: how fast the page responds to a tap

INP replaced the older FID and measures how much time passes between a click and a visible response. The threshold is 200 milliseconds.

The cause is practically always JavaScript. Every plugin, every tracking script and every embedded widget adds work the browser has to do before it can even respond to a tap. On a WordPress site with twenty plugins, INP drops on its own, without anyone doing anything wrong.

What helps: remove plugins you don't use, load scripts that aren't needed for the first render with defer, and load embedded maps and videos only on click.

CLS: how much the content jumps around

CLS measures content shifting during loading: when you want to tap a link, it moves under your finger and you hit an ad. The threshold is 0.1.

Three usual culprits: images without a set width and height, fonts without a fallback setting (the text reflows when the real font loads), and cookie or ad banners that push in above the content.

All three are quick to fix. Add width and height to images, font-display: swap with a fallback font of similar width to fonts, and put banners in a layer above the content, not in the page flow.

In what order to fix them

LCP first. For most websites that's where you gain the most for the least work, because it comes down to images and hosting.

Then CLS. The fixes are small and the effect is immediate.

INP last. It takes the most work, because it means removing or deferring code, and it often raises the question of whether the website needs that many plugins at all.

Where to check the result

In Google Search Console, in the Core Web Vitals report. Important: the data is a 28-day rolling average of real visitors. A fix you made today only shows in the report after a few weeks, and the full effect after 28 days.

So don't fix one element and wait. Fix the whole list at once, then measure.

PageSpeed Insights meanwhile shows you a lab measurement, which is useful for finding causes but isn't what Google uses for the score. Don't confuse the two.

What this means for rankings

Core Web Vitals are one signal, not the deciding one. Good content with poor metrics will still rank above poor content with excellent ones. But between two comparable pages, the faster one wins, and that is the position most small businesses in Slovenia are in.

The other, less mentioned effect is direct: a slow website loses some visitors before it even loads. That loss happens regardless of where you rank.

If you want to know where your website stands and what is worth fixing first, we look at it as part of SEO. Tell us which website to look at.

Sources

Found this useful? Add GudWeb as a preferred source on Google