Core Web Vitals explained for business owners, not developers

Every business owner has been sent a page speed report by somebody trying to sell them something. Most of those reports are technically accurate and practically useless, because they list forty items without saying which three matter.

These are the three that matter, in language you can use in a conversation with a developer.

LCP — does the main thing appear quickly?

Largest Contentful Paint. Target: under 2.5 seconds.

This measures how long until the biggest visible element finishes loading — usually your main headline or hero image. It is the closest thing to "how long before the page looks like it has arrived".

What usually breaks it:

• An enormous hero image. A photograph straight off a phone can be four megabytes. On mobile data that alone is several seconds.
• Fonts loaded from another domain. If your site fetches fonts from a third-party server, the browser has to open connections to extra origins before any text can paint.
• Slow hosting. If the server takes 800 milliseconds to answer, you have spent a third of your budget before anything downloads.

What to ask for: "Compress and resize the hero image, serve it as WebP, and self-host the fonts."

INP — does it respond when someone taps?

Interaction to Next Paint. Target: under 200 milliseconds.

This replaced the older First Input Delay measurement. It measures the delay between someone tapping something and the screen visibly changing. Every tap on the page counts, not just the first one, which makes it a much more honest measure of how a site actually feels.

What usually breaks it:

• Too much JavaScript. Chat widgets, popup tools, analytics stacks, review carousels, cookie banners. Each is small. Six of them together are not.
• Heavy page builders. Some WordPress builders ship large scripts for effects nobody notices.
• Third-party tags fighting each other during load.

What to ask for: "List every third-party script on the site and tell me what each one is for." The usual outcome is that two or three have not been used in a year and can be deleted outright.

CLS — does the page jump around?

Cumulative Layout Shift. Target: under 0.1.

This is the one everyone recognises but nobody can name. You go to tap a button, an advert or an image loads above it, everything moves, and you tap the wrong thing.

What usually breaks it:

• Images without width and height set. The browser does not know how much room to reserve, so everything below jumps once the image arrives.
• Content injected after load. A banner, a notification bar, or anything that appears once a script has run.
• Fonts swapping from a fallback to the real one at a noticeably different size.

We caused this ourselves on this very site during a build. A portfolio list rendered four entries, then added two more once a lookup completed — pushing everything below it down. It measured 0.10 to 0.16 across three testing tools. The fix was to render all six slots up front so the number of rows never changed.

What to ask for: "Set explicit dimensions on every image, and reserve space for anything that loads after the page."

How much does this actually affect rankings?

Honestly: less than the people selling speed audits imply, and more than sceptics claim.

Core Web Vitals are a confirmed ranking signal, but they behave as a tie-breaker. A fast page with weak content will not outrank a slow page that answers the question better. Where they bite is between two comparable results — and in conversion, which is where the real money is. A site that takes five seconds on mobile loses people before Google gets a vote.

What a good report should tell you

If someone sends you a speed report, judge it by whether it answers three questions:

1. Which of the three metrics is failing, and by how much? "Your site is slow" is not a finding.
2. What specifically is causing it? Naming the file, the script or the image.
3. What will change, and what will the number be afterwards? An estimate is fine. Silence is not.

A report that lists forty warnings without ranking them is a tool's output pasted into a document. The value is in the judgement of which three matter for your site, and that is the part you are actually paying for.

Two numbers, and only one of them counts

This confuses almost everybody. PageSpeed Insights shows two sections:

• "Discover what your real users are experiencing" — actual visitor data collected by Chrome. This is what Google uses. It needs roughly 28 days of traffic before it appears, so a new site shows nothing here, which is normal rather than a fault.
• "Diagnose performance issues" — a simulated lab test run on Google's hardware. Useful for finding problems, but it is not what ranks you.

A site can score 100 in the lab and still fail on real user data, usually because real visitors are on worse connections and older phones than the simulation assumes.

Test it properly

1. Run your homepage through PageSpeed Insights and read the mobile tab, not desktop. Google ranks on mobile.
2. Check Core Web Vitals in Search Console after a few weeks. That is real visitor data across your whole site.
3. Open the site on your own phone, on mobile data, with wifi off. Numbers are useful; the feeling is the point.

The realistic priority list

1. Compress the images. This alone fixes most LCP problems on most small business sites.
2. Delete unused scripts. Free, and usually the biggest INP win available.
3. Set image dimensions. Fixes most CLS.
4. Self-host fonts. Removes two external connections from the critical path.
5. Then consider hosting, if the server response time is genuinely slow.

If someone quotes you a large sum for "speed optimisation", ask which of those five they are doing. The answer tells you whether you are buying work or a report.