Core Web Vitals are Google's three measures of how a page loads, responds and holds still, and they matter to a business because a slow page loses enquiries before anyone reads a word.
The usual advice treats them as a ranking checklist. That undersells them. Think of a plumber's customer standing in a car park with two bars of signal, looking for a number to ring. If your page takes six seconds to show anything, they tap the next result.
This article explains the three measures in plain terms, what the evidence says about speed and sales, how to test your site the way a customer meets it, and what usually fixes the problem. It belongs to our wider guide to UK web design agencies, which covers speed alongside the other things a build should get right.
What are Core Web Vitals?
Core Web Vitals are three measurements of real visitors' experience: how fast the main content appears, how quickly the page reacts to a tap, and how much the layout jumps around.
Google's documentation names them and sets targets. The first is Largest Contentful Paint (LCP), which measures loading, and Google says good performance means the main content appears within 2.5 seconds. The second is Interaction to Next Paint (INP), which measures responsiveness, with a target under 200 milliseconds.
The third is Cumulative Layout Shift (CLS), which measures visual stability, with a target under 0.1.
LCP is the one most people feel. It is the moment the main headline, image or block of text finishes appearing. INP is the delay between tapping a menu and seeing it open. CLS is the annoying jump when a button moves just as you press it.
Google measures these on real visitors' phones and desktops, not on a developer's fast laptop. The standard is set at the 75th percentile: according to web.dev, a page should meet the target for at least three in four visits, segmented across mobile and desktop.
Do Core Web Vitals affect rankings?
They are part of what Google calls page experience, and Google says it highly recommends good scores for success in Search, but it does not say how much weight they carry.
Google's guidance says the vitals fit with what its core ranking systems aim to reward, alongside other page experience factors. It does not describe them as a deciding factor. In practice, content relevance and links outweigh speed for most queries, and a fast page with weak content will not beat a good page that is slightly slow.
Speed still matters at the margin, and it matters more for what happens after the click. A page that ranks well and loads badly wastes the ranking.
What does a slow page cost in enquiries?
Evidence from a large Google-commissioned study suggests that even tenths of a second change how many people buy or enquire.
Deloitte and 55 studied 37 brands across more than 30 million sessions. A 0.1 second improvement in mobile load time raised retail conversion rates by 8.4% and travel conversion by 10.1%, and shoppers spent 9.2% more in retail. On lead generation sites, 21.6% more users reached the form step.
Two cautions apply. The brands were large and mostly well funded, and the study ran in late 2019, so your site may see smaller or larger changes. And a tenth of a second is a small step, which means most small business sites with multi-second delays have far more to gain than the study's headline figures suggest.
For a service business, the effect shows up as fewer calls and form fills from mobile search. We treat it as a sales number for that reason, and it sits alongside the other items in nine things that make a service website convert.
How fast are most websites?
Barely more than half of websites load their main content fast enough on mobile.
The 2025 Web Almanac from the HTTP Archive found that 54% of sites achieved a good LCP on mobile. The rate varied sharply by platform.
xychart-beta
title "Share of mobile sites with a good LCP, 2025 Web Almanac (%)"
x-axis ["Weebly", "WordPress", "All sites", "Wix", "Duda"]
y-axis "Percent good" 0 --> 100
bar [52, 53, 54, 81, 94]
Platform is not destiny. A carefully built WordPress site can score well, and a heavy site on any platform can score badly. The chart shows what typically happens, which is that sites built from many components and plugins end up slower. We cover the platform trade-offs in why we build on Next.js, and when we do not.
How do you test your site the way a customer meets it?
Test on a mid-range phone, on mobile data, away from your office wifi, and look at real-user data before lab scores.
Start with the data Google already holds. Search Console has a Core Web Vitals report that groups your pages as good, needs improvement or poor, based on real visits. Small sites sometimes do not have enough traffic to appear, in which case a lab test is all you get.
Then run a lab test with Google's PageSpeed Insights, which reports field data where it exists and a simulated test otherwise. Treat the lab number as a guide to what to fix, since it describes one simulated visit.
Finally, do the car park test. Switch off wifi, load your homepage on your phone over 4G, and time how long it takes before you can read the headline and press the call button. Try a service page too. Those are the moments a customer decides. If you wince, the numbers will agree.
What usually makes a site slow?
Oversized images, too much script and cheap hosting account for most slow small business sites.
Images. A photo straight from a camera can weigh 4MB. Resize to the display size, use modern formats such as WebP or AVIF, and do not lazy-load the main image at the top of the page, because that delays LCP.
Scripts. Chat widgets, tracking pixels, review badges, social feeds and animation libraries each load code. Remove any you cannot justify, and load the rest after the main content.
Fonts. Custom fonts can hold up the text. Limit yourself to one or two families and load them in a way that shows text straight away.
Hosting. A shared host that takes a second to respond leaves your page behind before anything else happens. Servers close to your visitors, and caching, make a real difference.
Layout jumps. Images without set dimensions, ads and banners inserted late all push content around. Reserve the space for them in advance.
What is INP, and why did it replace the old measure?
INP replaced First Input Delay in 2024 because it judges every tap and click during a visit, not only the first one.
The older measure only looked at the delay before the first interaction, so a site could pass while feeling sluggish afterwards. INP records the slowest typical response across the visit. A page that freezes for half a second when someone opens a menu, picks a date in a booking widget or taps "add to basket" fails the 200 millisecond target even if it loaded quickly.
The usual cause is too much JavaScript running on the main thread at once. Heavy sliders, tag managers loaded with a dozen tags, chat widgets and complex page builders are the common offenders. Cutting scripts you do not use is the cheapest fix and often the only one needed.
How should you read the Search Console report?
Read it by group, not by page: Search Console clusters similar pages, so the fix usually applies to a template, and fixing one template improves dozens of URLs at once.
The report shows pages as good, needs improvement or poor, separately for mobile and desktop, using real-visitor data gathered over roughly the previous month. That delay matters. After you ship a fix, the report takes weeks to move, so judge your work with a lab test first and the field data later.
A service site with fifteen pages typically has two or three templates: the homepage, service pages and articles. If the service template fails on LCP because of an oversized banner image, fixing that one image fixes the group.
Check the three or four pages that bring in enquiries before anything else, because a pass on the contact page is worth more than a pass on an old news post.
How often should you recheck?
Recheck after every significant change to the site and once a quarter in between.
Speed drifts. A new plugin, a fresh tracking tag, a bigger hero image from the marketing team or a theme update can each add weight, and nobody notices until enquiries dip. Put the three-page test in the diary and compare it with the last result.
If you pay for maintenance, ask for the result as part of the report, which links with what we say about hosting, security and maintenance.
What should you ask your web agency about speed?
Ask which numbers they will test, on which devices, and whether you can see the results before launch.
A good answer names LCP, INP and CLS, mentions mobile and gives a target, such as "LCP under 2.5 seconds on the key pages". A poor answer says the site will be "optimised".
Put the target in the brief and check it at handover. For ecommerce brands and retailers, where each lost second shows in basket numbers, set it as an acceptance test.
If you are weighing a rebuild partly for speed, remember that launch is the riskiest moment for search traffic, and our article on why redesigns lose traffic explains how to avoid the dip.
Get your own numbers
Run Search Console, PageSpeed Insights and the car park test on your three most important pages, and note the results.
If the numbers are poor and you want help with the fixes, our website design service covers speed as part of the build, and you can contact us with your results.