Core Web Vitals sound like a developer concern. They are actually a description of whether your website is unpleasant to use, expressed as three numbers — and Google collects them from your real visitors rather than from a test.
The three measurements
Largest Contentful Paint: how long until something useful appears
LCP measures the time until the biggest visible element — usually the hero image or headline — has rendered. It is the closest thing to "how long before this page looks like a page".
Good is under 2.5 seconds. Over four seconds and a meaningful share of visitors have already left.
Interaction to Next Paint: how long until it responds
INP measures the delay between someone tapping something and the page visibly reacting. It replaced the older First Input Delay because that only measured the first interaction, which flattered pages that got slower as you used them.
Good is under 200 milliseconds. Poor INP is the sensation of tapping a menu and wondering whether it registered.
Cumulative Layout Shift: how much it jumps
CLS measures unexpected movement while the page loads. It is the reason you tap the wrong link, because an image finished loading above what you were aiming at and pushed everything down.
Good is under 0.1. This is the most irritating of the three and frequently the easiest to fix.
Why they matter commercially
The ranking effect is real and modest — Google has been clear that relevance outweighs speed. Two pages that answer a question equally well will be separated by page experience; a fast irrelevant page will not outrank a slow relevant one.
The larger effect is on behaviour. Visitors abandon slow pages, and they abandon them before they have read anything. On a site taking orders or enquiries, that is measurable revenue rather than an abstract score.
Treat Core Web Vitals as a conversion metric that happens to also be a ranking signal. That framing produces better decisions about what to fix.
Where to look
Google Search Console has a Core Web Vitals report drawn from real visitors over the previous 28 days. This is the data Google actually uses, and it groups pages by type so you can see whether the problem is your product pages or your blog.
PageSpeed Insights tests a single page and gives both the real-world figures and a laboratory run with specific recommendations. Use it to diagnose, not to score — the lab result is a simulation and will differ from what your visitors experience.
Do not chase a perfect one hundred. Getting from red to green matters; getting from 92 to 97 rarely does.
The fixes that actually move the numbers
Images, first and always
The single biggest cause of poor LCP on business websites is a hero image uploaded at camera resolution. A 4MB photograph scaled to fit by the browser still downloads all 4MB.
Three things to do: resize to the dimensions actually displayed, serve modern formats such as WebP or AVIF, and always declare width and height so the browser reserves the space. That last one is the main CLS fix as well.
Fonts
Custom fonts commonly cause both a delay and a shift — text appears in a fallback, then swaps when the real font arrives. Loading fonts from your own domain, preloading the critical one, and limiting yourself to the weights you actually use addresses most of it.
Third-party scripts
Chat widgets, analytics, heatmaps, advertising pixels, cookie banners, review widgets. Each is code from someone else's server, running on your visitor's phone, and INP is usually where the damage shows.
Audit what is loading. Most sites carry at least one script for a tool nobody uses any more. Removing it is free and immediate.
Advertising and embeds
Anything injected after load — an advert, a video embed, a cookie notice — will shift the layout unless space is reserved for it. Reserve the space.
Hosting
Server response time sets the floor for everything else. If the server takes 800 milliseconds to begin responding, no amount of image optimisation reaches a good LCP. Cheap shared hosting is often the invisible constraint, which we cover in choosing hosting for a UK business.
A sensible order of work
- Read the Search Console report and find which page types fail, not which individual pages.
- Fix images across the site — biggest gain, lowest risk.
- Remove third-party scripts nobody uses.
- Reserve space for anything that loads late.
- Check server response time and address hosting if it is the floor.
- Re-measure after 28 days, because the report is a rolling window.
That last point catches people out. Fixes do not show up immediately, because the report reflects a month of real visits. Do the work, then wait.
If your site is failing and you would rather have someone diagnose it properly, our web development team works on performance for UK businesses. Ask us to look at your pages and we will tell you what is actually costing you the time.
