Blog · 5 November 2026 · 7 min read

Core Web Vitals in plain English: LCP, INP and CLS

Google rates how your website feels with three numbers. You don't need to be a developer to understand them – or to know what to ask your developer to fix. This article explains each one with examples from a typical business website.

Where these three numbers come from

Core Web Vitals are measurements that Google collects from real Chrome browsers of people visiting your site. They aren't opinions; they are times and distances measured on the phones and laptops of actual visitors. Google shows them in PageSpeed Insights and in the Search Console "Core Web Vitals" report.

Why care? Two reasons. First, since 2021 the vitals have been one of Google's ranking signals. On its own it is a weak one – good content still beats a fast empty page – but when competitors have similar content, it tips the balance. Second, and more important: the things that hurt the vitals hurt sales. A page that takes six seconds to load on a phone loses a large share of visitors before they see anything.

The three metrics, one sentence each

Between "good" and "poor" sits a "needs improvement" zone. Google looks at the 75th percentile: a page passes if at least three quarters of visits land in the green. One slow visit from a train doesn't hurt; a consistently slow experience on an average customer's phone does.

LCP – "how long until I see something"

LCP is the moment the largest visible element appears. On a business site it is almost always the big image at the top or the hero background. Typical causes of poor LCP:

• A heavy hero image. A 4000 × 3000 px photo straight from the camera, 3 MB, shown in a 400 px wide viewport on a phone. It should weigh 100–200 KB, in WebP or AVIF, in several sizes (srcset).
• A slow server. If the first byte arrives after 1.5 s (TTFB), nothing can appear before 2.5 s. The cheapest shared hosting, no page cache in WordPress, no CDN – this is usually where it hides.
• Render-blocking scripts and styles. The browser paints nothing until it has downloaded every CSS file in the head and every script without defer. Themes and plugins can add dozens.
• A lazy-loaded hero image. A paradox: loading="lazy" is great for images further down, but on the main image it delays it by hundreds of milliseconds.

What to ask for: compress and resize images (Squoosh, plugins like ShortPixel), enable page cache and a CDN, mark the main image fetchpriority="high", remove loading="lazy" from anything above the fold.

INP – "does the page react when I tap"

INP replaced the older FID metric in 2024 and is stricter: it measures not just the first click but the whole visit, and it takes the worst response. If nothing happens for half a second after tapping "Add to cart", the user taps again and your INP goes red.

The cause is almost always the same: too much JavaScript. Specifically:

• Page builders and "all-in-one" themes that load the code for every feature, including the ones you don't use.
• Third-party scripts: chat, maps, ad pixels, session recording, several analytics tools at once. Each of them occupies the browser's main thread – there is only one, and it also handles your taps.
• Sliders and background animations running on every page.

What to ask for: a review of plugins and scripts – disable unused ones, load the rest with defer or after the first interaction; drop duplicates (two analytics tools, two chat widgets). On a mid-range phone the effect is many times larger than on a developer's laptop, which is why INP must be judged on field data, not on your own machine.

CLS – "why did I click the wrong thing"

CLS has no time unit because it measures movement: how much of the screen, and how far, content moved after it had already appeared. You know the feeling: you're reading a paragraph, a banner loads above it and the text drops by 300 pixels. Or you aim at "Send", a cookie bar appears at the last moment and you hit an ad instead.

Typical causes:

• Images without dimensions. The browser doesn't know how much space to reserve, so it lays out the text first and then pushes the image in. The fix is trivial: width and height attributes on every <img>.
• Late-loading embeds – ads, maps, videos, review widgets – with no space reserved.
• Web fonts that swap the text to a different typeface with a different width once downloaded, so everything shifts.
• Bars and notices sliding in from the top (cookie consent, promotions) that push the rest of the page down instead of overlaying it.

What to ask for: dimensions on images and embeds, font-display: swap with a matched fallback font (or simply a system font), notice bars as an overlay rather than part of the document flow.

How to check it yourself in 2 minutes

1. Go to pagespeed.web.dev, enter your address, pick the "Mobile" tab.
2. The top section, "Discover what your real users are experiencing", is field data. If it's missing, your site has too little traffic for Google to have a sample – then only the lower part, the lab measurement, counts.
3. The lower part ("Diagnose performance issues") is a simulation on a slower phone and a slower network. The numbers are harsher than in the field, but they point at specific causes and files.

If you have Search Console, open the "Core Web Vitals" report – it shows which groups of pages fail, not just the homepage. Very often the homepage is fine and every blog post fails, because they all share the same heavy template.

Where to start when everything is red

The order that gives the most for the least work in practice:

1. Images – compression, proper sizes, dimensions in HTML. One afternoon's work, improves LCP and CLS at once.
2. Cache and hosting – a cache plugin (WordPress) or a hosting change, plus a CDN. Improves LCP on every page.
3. Script clean-up – removing unused plugins and duplicate tools. Improves INP and often LCP.
4. Fonts and bars – the last tenths of CLS.

What not to do: don't install three "optimisation" plugins at once hoping one of them helps. Each adds its own code, and conflicts between them are the classic way to make a site stop working on phones on a Friday evening.