May 17, 2026

Improving Core Web Vitals – The Practical Guide for Better Google Rankings

Understand and optimize LCP, INP, and CLS: Practical measures for better Core Web Vitals, faster load times, and higher Google rankings.

Core Web Vitals are Google's attempt to put "feels fast" into numbers. They have fed into rankings since 2021, and ever since they have been a favourite magic word in proposals. In reality they are three fairly concrete measurements you can understand without being a developer. | Metric | What it measures | Good value | |---|---|---| | LCP | When the largest visible element is done | under 2.5 seconds | | INP | How quickly the page responds to clicks and input | under 200 milliseconds | | CLS | Whether things still shift while loading | under 0.1 | They only become useful once you see what they reveal about your own site.

Measure First, or You Are Optimising Blind

The fastest way in is pagespeed.web.dev. Enter your URL and you get two kinds of data: lab data from a simulated visit, and field data from real visitors. The field data matters more – it comes from the devices and networks your customers actually have, and it is almost always worse than the lab. If you have Search Console set up, you get the same view across the whole site rather than a single page, split by mobile and desktop. And if you want to know why something is slow rather than just that it is: open developer tools, "Performance" tab, reload. There you can see second by second what is being waited for.

LCP: What Holds Up the First Impression

LCP measures when the most important visible content is finished – usually a large image at the top or a headline. It is the value that breaks first on most sites, and the cause is remarkably often the same: an oversized image. A 2 MB photo uploaded straight from a camera can usually be brought under 200 KB without anyone seeing a difference. That means the right format – WebP rather than JPEG – and the right dimensions: a 4000-pixel-wide image inside an 800-pixel-wide area is wasted load time, transferred four times over for nothing. The second pattern is lazy loading in the wrong place. Loading images below the fold later is correct. Loading the topmost image later is exactly the mistake LCP punishes – that one is explicitly meant to come first. Underneath all of it sits the server. If the first response already takes two seconds, no amount of image work will save it. This site answers in roughly 35 milliseconds, because it is generated in advance and assembles nothing at the moment of the request.

INP: When the Page Is There but Does Not React

INP replaced the old FID value in 2024 and no longer measures only the first interaction, but all of them. That is the more honest value – and the more uncomfortable one. Poor INP almost always comes from JavaScript. Large script bundles block the browser's main thread; while it is busy, a click visibly does nothing. The visitor then clicks again, which makes matters worse. The remedies are unspectacular: load only the code the current page actually needs; break long calculations into smaller pieces so the browser can respond in between; move genuinely heavy work into a background thread. And the single most effective lever: fewer foreign scripts. Every chat widget, every analytics tool, every social embed has a price, and few of them earn it.

CLS: The Jumping Everyone Complains About

You know the feeling: you go to tap a link, a banner loads at the last moment, everything shifts, and you hit something else. That is precisely what CLS measures. The most common cause is images without dimensions. Without width and height – or at least a fixed aspect ratio – the browser does not know how much space to reserve and pushes everything apart when the image arrives. The same happens with fonts that load late and replace the system font, with cookie notices that push into the content, and with embedded videos or maps without a fixed frame. The fix is almost always the same idea: reserve the space before the content arrives.

What the Score Means – and What It Does Not

| Score | Reading | |---|---| | 90–100 | Good. Further work rarely pays off here | | 50–89 | Room to improve. Usually traceable to one or two causes | | 0–49 | Poor. Noticeable to visitors, not just to measuring tools | More important than the number is where it comes from. With WordPress it depends almost entirely on three things: how many extensions are running, the quality of the theme, and the performance of the hosting. A grown site with fifteen extensions often lands between 40 and 60 on mobile – not because WordPress is bad, but because fifteen small things add up to one large one. A pre-generated site without an extension chain reaches the 90s routinely. That is not an achievement; it is a consequence of less happening.

The Thresholds at a Glance

The table at the very top names the good values. The picture is only complete with the two bands below them – and the transition is not gradual: for passing, only the first column counts. | Metric | Good | Needs improvement | Poor | |---|---|---|---| | LCP – largest element visible | up to 2.5 s | up to 4.0 s | over 4.0 s | | INP – response to input | up to 200 ms | up to 500 ms | over 500 ms | | CLS – layout shift | up to 0.1 | up to 0.25 | over 0.25 | What gets assessed is not your average but the 75th percentile: three out of four visitors have to reach the good value. That is why a site feels fast on your machine and still fails – your connection and your phone are not the benchmark.

Lab Data and Field Data Are Not the Same Thing

This is where most reports get misread. Lab data comes from a single run under simulated conditions – throttled network, throttled processing. It is reproducible and useful for comparing two states. What it cannot do: measure INP. That value needs real input from real visitors; in the lab there are only approximations. Field data comes from the Chrome User Experience Report and reflects what visitors actually experienced, over 28 days. Only these numbers count for Google's assessment. They have two catches: they lag reality by weeks, and for low-traffic pages they do not exist at all – the report simply stays empty. In practice: optimise using lab data, because there you see immediately whether a change works. Judge success using field data, but expect the result no sooner than four weeks later.

The Most Common Causes, Sorted by Effort

The causes are described above, under each metric. What is missing there is the order – and the order decides whether an afternoon is enough or it turns into a project. This is how I work through a site: | Order | Measure | Effort | Typical effect | |---|---|---|---| | 1 | Remove lazy loading from the topmost image | minutes | often a full second of LCP | | 2 | Resize images and use the right format | an afternoon | half the payload | | 3 | Fixed dimensions for images, banners, embeds | low | CLS usually solved | | 4 | Self-host and preload fonts | low | calmer rendering, and better for privacy | | 5 | Remove third-party scripts | medium to high | the only real lever for INP | For most sites, points 1 and 2 achieve more than everything that follows. Point 5 is the most demanding, which is why it tends to get quoted first – it only pays off once the four before it are in place.

Where It Stops Being About Technology

Core Web Vitals are an official ranking factor, but they are not a lever for getting past Google. Their real value lies elsewhere: someone waiting too long for content is back in the search results before your page is finished – and you never find out they were there. If you want to know where your site stands and which two or three causes would make the difference, send me the address. You will get an assessment, not a sales pitch. Have your website checked