Core Web Vitals Without the Jargon: What LCP, CLS and INP Cost You

Why this matters, honestly

Two claims get made about site speed and only one of them holds up well.

As a ranking factor, it is real but small. Google has said Core Web Vitals are a ranking signal and has also said content relevance matters far more. A slow page with the best answer still outranks a fast page with a worse one. If you are hoping speed work will move you from page two to page one on its own, it usually will not.

As a conversion factor, it is large. This is the reason to care. A visitor who waits four seconds on a phone with an ordinary connection frequently does not wait. They leave before your page has said anything at all, and they never appear in any funnel report as a lost lead, because from your analytics' point of view they were never really there.

Speed rarely wins you a ranking. It regularly loses you the visitor who already found you.

The three metrics in plain words

LCP — Largest Contentful Paint

How long until the biggest thing on screen appears. Usually your hero image or headline. It is a proxy for “when did this page start being useful?”

Good: under 2.5 seconds. Poor: over 4. The usual culprits are an enormous unoptimised hero image, a slow server response, or render-blocking fonts and stylesheets queued ahead of the content.

CLS — Cumulative Layout Shift

How much the page jumps around while it loads. You start reading, an image finishes loading above the text, everything shoves down, and you lose your place — or worse, you tap the wrong thing because a button moved under your thumb.

Good: under 0.1. Poor: over 0.25. Nearly always caused by images and embeds without declared dimensions, ads or banners injected above existing content, or web fonts swapping in at a different size.

INP — Interaction to Next Paint

How quickly the page responds when somebody taps or clicks. It replaced First Input Delay in 2024 and it is stricter, because it measures every interaction throughout the visit rather than only the first.

Good: under 200 milliseconds. Poor: over 500. The cause is almost always too much JavaScript occupying the browser — frequently third-party scripts rather than anything you wrote.

Why two tools give you different numbers

You run PageSpeed Insights, get 94, feel pleased. You run it again the next day and get 61. Neither is wrong; they are different measurements.

Lab data is a simulated load on a simulated device with a simulated connection, run once. It is reproducible, diagnostic and useful for finding what to fix. It is not what your visitors experienced, and it varies between runs.

Field data is real Core Web Vitals collected from actual Chrome users on your site over the previous 28 days. It is what Google uses for ranking, it is the truth about your visitors, and it needs enough traffic to exist at all — smaller sites frequently have none.

The practical rule: use field data to decide whether there is a problem, and lab data to work out what is causing it. And when you have no field data, treat lab scores as a rough direction rather than a grade.

Fixes that need no developer

1. Compress your images (usually the whole problem)

The single largest cause of poor LCP on the sites I look at, and it is routinely a 4 MB hero photograph exported straight from a camera. Resize to the dimensions actually displayed, compress, and serve WebP where you can. This one change fixes more LCP failures than everything else combined.

2. Declare image dimensions

Width and height attributes, or a CSS aspect ratio, so the browser reserves the space before the image arrives. This is the CLS fix, it is trivial, and most page builders have a setting for it.

3. Audit your third-party scripts

Open your site and count the tracking pixels, chat widgets, popup tools, review embeds, heatmap recorders and A/B testing snippets. Each one is JavaScript competing for the same browser thread that has to respond when somebody taps. Remove the ones nobody has looked at in six months — there are usually two or three.

4. Lazy-load anything below the fold

Images and iframes further down the page should not compete with the content somebody can actually see. Most platforms do this by default now; check that yours has not been switched off by a plugin.

5. Limit your web fonts

Two families, two or three weights. Each additional font file is another request blocking text from appearing, and a font that swaps in at a different size causes layout shift on its way in.

6. Check your hosting

If the server takes 800 milliseconds to respond before sending a single byte, no front-end optimisation recovers that. Cheap shared hosting is a real and common ceiling on what any of the above can achieve.

Where slow pages hurt most

Paid traffic landing pages

You are paying for each arrival. Every visitor lost to a slow load is money spent on somebody who never saw the offer — and it compounds, because platforms measure landing page experience and price you accordingly.

Mobile visitors on ordinary connections

Your site is fast on your laptop on office wifi. That is not the test. A large share of Indian small-business traffic arrives on mid-range phones on mobile data, where a 4 MB hero image is a genuinely different experience.

Ecommerce product pages

The moment of highest intent, and typically the heaviest page on the site — gallery, reviews widget, recommendation carousel, chat, analytics. It is worth measuring these separately from your homepage.

Anything with a form near the top

Layout shift is at its most expensive here. A form field that moves as somebody starts typing, or a submit button that jumps under a thumb, does not merely annoy — it loses the submission entirely.

Why scan speed alongside everything else

PageSpeed Insights is excellent and you should use it. It answers one question thoroughly: how fast is this page? What it cannot tell you is whether speed is the thing costing you enquiries, because it never looks at whether the page asks for anything.

The page performance checker scans five categories together — experience, performance, SEO, conversion readiness and trust signals — and returns a score out of 100 with the specific opportunities ranked. Performance data comes from Google's own PageSpeed Insights, layered on after the rest of the scan so a slow Lighthouse run degrades that one detail rather than blocking the whole report.

The reason to look at them together is that speed work is frequently the wrong first move. A page loading in 1.9 seconds with no call to action and no phone number does not have a performance problem, and a week spent shaving 300 milliseconds off it will produce precisely nothing. Seeing all five categories at once is what stops that.

It is free, takes about thirty seconds, and needs no signup. If you want the full list of what it checks, the 41-point audit is written up here, and this comparison covers what the various free audit tools each measure and where they stop.

FAQ