Core Web Vitals explained, without the jargon

Site speed is one of the few website improvements with a direct, measurable effect on enquiries. It is also the area where business owners are most often shown a number they do not understand, told it is good, and left none the wiser about whether the site is actually quick.

This is an attempt to demystify it: what the three Core Web Vitals measure, why a green Lighthouse score can coexist with a slow website, and what actually needs changing.

Why speed converts

The mechanism is behavioural rather than technical. Somebody who found you through a search on their phone has no investment in your business yet. They are two taps from a competitor. If your page is blank while they wait, a proportion of them go back — not annoyed, just gone. They never appear in your analytics as a lost enquiry, which is precisely why the problem persists unnoticed for years.

Google's own research put the effect starkly: as page load time goes from one second to three, the probability of a mobile visitor bouncing rises by around 32%. At five seconds it is roughly 90%. The exact figures matter less than the shape of the curve — the first few seconds are where you lose people.

Speed is also a ranking input. Core Web Vitals form part of Google's page experience signals. They will not push thin content up the results, but poor vitals will hold good content back, particularly where competitors are otherwise comparable.

The three metrics

Largest Contentful Paint — "when does it look ready?"

What it measures. The time from the start of navigation until the largest visible element — usually a hero image or a headline — has rendered.

Target. Under 2.5 seconds for 75% of visits. Over 4 seconds is poor.

What it feels like. LCP is your "is this thing working?" moment. Below 2.5 seconds a page feels immediate. Above 4 it feels broken, and people start tapping again or leaving.

Usual causes of a bad score.

An oversized hero image. A photograph exported at 4,000 pixels wide and 3MB, displayed at 800 pixels. The browser has to download all of it before anything appears.

Render-blocking requests. CSS and synchronous JavaScript in the head must be fetched and processed before the browser will paint. A single third-party stylesheet can add a second.

Web fonts. If text waits for a font file, the page is blank until that file arrives.

Slow server response. Time to first byte on cheap shared hosting, or a database-driven page assembled from scratch on every request.

Cumulative Layout Shift — "does it stay still?"

What it measures. How much visible content moves about unexpectedly while the page loads.

Target. Under 0.1. Over 0.25 is poor.

What it feels like. You go to tap a link, an image finishes loading above it, everything jumps, and you tap an advert instead. It is one of the most irritating experiences on the mobile web, and it is entirely preventable.

Usual causes.

Images without dimensions. If the HTML does not say how tall an image will be, the browser cannot reserve space, so everything below moves when it arrives. Setting width and height (or an aspect ratio) fixes this completely.

Content injected after paint. Cookie banners, notification bars, adverts and embeds that push the page down.

Web fonts that change metrics. The fallback font is a different size, so when the real font swaps in every line re-flows.

Elements animated with top or margin rather than transform, which forces layout recalculation.

Interaction to Next Paint — "does it respond?"

What it measures. How long after a tap, click or key press before the page visibly responds. It replaced First Input Delay in March 2024 and is considerably stricter, because it looks at every interaction rather than only the first.

Target. Under 200 milliseconds. Over 500 is poor.

What it feels like. You tap the menu and nothing happens, so you tap again, and then it opens twice. Deeply unsatisfying, and it makes a site feel cheap regardless of how it looks.

Usual causes. Almost always too much JavaScript competing for the browser's main thread. Frequently third-party: tag managers, chat widgets, heat-mapping tools, review badges. Each is code you did not write, running on your visitor's device, on the same thread as your interface.

Why your Lighthouse score can mislead you

Lighthouse in Chrome DevTools gives you a lab result: a single simulated load, on a simulated device, on a simulated connection, from wherever you happen to be sitting. It is genuinely useful for diagnosis and it is not a measure of what your visitors experience.

Two failure modes are common.

A good score, a slow site. You tested on a fast laptop on office broadband, sitting near the server, with a warm cache. Your customers are on mid-range Android phones on rural 4G. Their experience is nothing like yours.

A poor score, a fine site. Lighthouse is aggressive about throttling and penalises things that may not matter for your audience.

The number that actually counts is field data: the Chrome User Experience Report, which aggregates real Chrome users' measurements. You can see it free in PageSpeed Insights (the top section, "Discover what your real users are experiencing") and in Search Console's Core Web Vitals report.

The sensible workflow is: field data tells you whether you have a problem and for whom; lab tools tell you what is causing it.

What to actually change

In rough order of how often it is the answer.

Fix the images

Images are the largest single cause of slow small business websites, and the cheapest to put right.

• Resize before upload. Nothing on a normal page needs to be wider than about 2,000 pixels, and most things need far less.
• Use modern formats. AVIF and WebP are typically 30–60% smaller than JPEG at equivalent quality. Serve them with a JPEG fallback.
• Serve responsive sizes. A phone should download a phone-sized image, not a desktop one scaled down by CSS. This is what srcset and sizes are for, and what image components in modern frameworks do automatically.
• Always set dimensions, to eliminate layout shift.
• Lazy-load below the fold, but never the LCP image — that one should be prioritised, not deferred.

For most sites this single area accounts for the majority of available improvement.

Sort out the fonts

• Self-host rather than requesting from a third-party origin, which removes a DNS lookup, a connection and a dependency
• Subset to the characters you use — a full Cyrillic and Greek character set is dead weight on an English-language site
• Preload the one file needed for the first paint
• Set font-display: swap so text is visible immediately in a fallback
• Match fallback metrics so the swap does not shift the layout
• Use fewer weights. Two is usually plenty; four is usually vanity.

Audit the third parties

List every third-party script on your site and, for each one, ask what it earns. Measure the cost in milliseconds — Chrome DevTools' Performance panel will attribute main-thread time by origin.

A chat widget producing enquiries may well justify 300 milliseconds. A review badge nobody clicks, a heat-mapping tool from a trial you forgot to cancel, and two analytics platforms doing the same job do not. This is the most common source of poor INP, and removal is free.

Reduce the JavaScript

Most brochure websites ship several times the JavaScript they use: a framework for one carousel, a date picker on a page with no dates, three animation libraries. Audit, remove, and defer whatever can wait.

The structural version of this argument is to serve static HTML and add interactivity only where there is something to interact with, which is how we build sites. A page that is genuinely just content should not need a JavaScript runtime to display it.

Get the delivery right

• Compression enabled (Brotli, ideally)
• Long-lived immutable caching for static assets
• Sensible cache headers on HTML
• Content served from an edge location near the visitor rather than a single origin
• HTTP/2 or HTTP/3

On a modern host most of this is default. On older shared hosting, much of it is not.

Make it stick

Performance decays. Six months after the work, someone uploads an uncompressed photograph, marketing adds a tracking pixel, and the gains quietly evaporate.

So finish the job with defences:

• Performance budgets — agreed limits for page weight, image size and script count
• Monitoring — track vitals over time so drift is visible before it is severe
• An automated image pipeline so oversized uploads are handled without anybody remembering
• A short editor's guide — one page, plain English, for whoever adds content

For clients on a managed plan we monitor this continuously and deal with drift as part of the monthly work.

A 30-minute self-assessment

1. Run your home page and two key pages through PageSpeed Insights. Read the field data at the top first, and only then the lab section.
2. Check Search Console → Core Web Vitals to see how many URLs are classed as poor, and on which metric.
3. In Chrome DevTools, open the Network panel, throttle to "Slow 4G", reload, and sort by size. Anything over about 200KB deserves an explanation.
4. Watch the page load at that throttled speed and note what moves. That is your CLS, visible.
5. Tap or click around while it is still loading. If interactions feel sticky, you have an INP problem, and the Performance panel will tell you which script is responsible.

That half-hour will usually identify the two or three changes worth making, and you will know whether you need help or a compressed photograph.

Where we come in

We offer performance optimisation as a standalone piece of work: measure, diagnose, fix in order of measured impact, then leave you with budgets and monitoring so it stays fast. Every site we build is measured on real devices before launch as a matter of course, and none of it involves stripping out things you need in order to chase a number.

If you would like to know why your site feels slow — and whether it can be fixed without a rebuild — send us the address or call 01420 446331. We will run the numbers and tell you where the time is going.