Fewer than half of mobile websites pass Google’s Core Web Vitals. The 2025 Web Almanac, which analysed real-visitor data from millions of sites, found that 48% of mobile sites and 56% of desktop sites cleared all three thresholds (HTTP Archive, Web Almanac 2025: Performance, CrUX data from July 2025). Accessibility is measured differently, but the numbers aren’t any better: WebAIM’s 2026 scan of the top one million homepages found detectable WCAG failures on 95.9% of them (WebAIM Million 2026).
If you run a small business, “Core Web Vitals” probably sounds like something for your developer. It isn’t really. Underneath the acronyms is a plain business question: when someone you’ve paid to attract lands on your site, does it load quickly, respond when they tap, stay still while they read, and work for them if they have a disability?
Most guides answer half of that. The technical ones cover speed and ignore accessibility; the accessibility ones ignore speed. This guide covers the whole picture in plain language, sized for a business owner rather than a developer. Each section links to a full walkthrough when you want more depth.
Key Takeaways
- Core Web Vitals are three numbers: LCP (how fast the main content loads), INP (how quickly the page responds to a tap or click) and CLS (how much the layout jumps around). “Good” means LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, for at least 75% of real visits.
- Only 48% of mobile websites pass all three, and loading speed (LCP) is the one most sites fail.
- Google uses Core Web Vitals in ranking, but its own documentation says good scores don’t guarantee top rankings and relevant content still wins. The bigger payoff is visitors who stay and convert.
- Speed, mobile usability, accessibility and security overlap. Google’s own page experience checklist puts Core Web Vitals, secure delivery and mobile display side by side.
- Start with a free five-minute test, fix whichever metric is furthest from “good”, and run the accessibility check in the same tool while you’re there.
What Core Web Vitals measure
Core Web Vitals are three measurements Google uses to judge how a page feels to a real visitor: how fast it loads, how quickly it responds, and how stable it stays while loading. Each has a published “good” threshold, and Google judges them on real visits rather than a single test run.
LCP (Largest Contentful Paint): does the page load fast?
LCP measures how long it takes for the biggest thing on screen to appear. That’s usually your hero image, a large heading or a banner. It’s the moment a visitor feels the page has “arrived”. A slow LCP is what people mean when they say a site is slow.
INP (Interaction to Next Paint): does it respond when I tap?
INP measures the gap between a visitor doing something (tapping a menu, clicking “Add to basket”, ticking a form box) and the page visibly reacting. A poor INP is the frustrating moment when you tap a button and nothing seems to happen, so you tap it again. INP replaced an older metric, First Input Delay, in March 2024. Older guides that still mention FID are out of date.
CLS (Cumulative Layout Shift): does it stay still?
CLS measures how much the page jumps around while it loads. You’ve met this one: you go to tap a link, an advert or image loads above it, and the whole page shifts down so you tap the wrong thing. CLS is a score rather than a time. Lower is better.
The thresholds
Google publishes three bands for each metric (web.dev, “Web Vitals”, retrieved 2026-09-26):
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading | 2.5 seconds or less | 2.5 to 4 seconds | Over 4 seconds |
| INP | Responsiveness | 200 milliseconds or less | 200 to 500 milliseconds | Over 500 milliseconds |
| CLS | Visual stability | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Google judges each metric at the 75th percentile of real page loads, measured separately on mobile and desktop. To be rated “good”, at least three out of four real visits need to clear the threshold, not just your own visit on fast office Wi-Fi. A site that feels quick on your laptop can still fail because customers are opening it on older phones with a weak signal.
Each of the three matches something a visitor notices (waiting, tapping and hoping, losing their place), not a technical measure only a developer would see.
How most websites score
Most websites fail at least one Core Web Vital, and loading speed is the usual culprit. If your site fails, you’re in the majority, and the fixes are well understood.
The 2025 Web Almanac, HTTP Archive’s annual analysis of Chrome’s real-user data, gives the clearest picture (Web Almanac 2025: Performance, CrUX data from July 2025):
- 48% of mobile sites and 56% of desktop sites pass all three Core Web Vitals.
- On mobile, 62% of sites have good LCP, 77% have good INP and 81% have good CLS.
- Homepages do worse than other pages: 45% of mobile homepages pass, against 56% of secondary pages on mobile.
Fix loading first. LCP has the lowest pass rate of the three by a clear margin, so if you only have time or budget for one thing, it’s likely the thing holding you back. In our experience building small business sites, that usually comes down to a heavy hero image or slow hosting.
Test your homepage specifically. It’s the page most likely to fail and often the first page a new visitor sees. Big sliders, autoplay video, chat widgets and tracking scripts tend to pile up there, and every one of them competes for the same few seconds.
Why this matters beyond your Google ranking
Core Web Vitals matter mainly because slow, jumpy or unresponsive pages lose visitors and sales. The ranking effect is real, but it’s the smaller part of the story.
Google’s research on mobile landing pages found that as page load time goes from one second to ten, the probability of a visitor bouncing rises by 123% (Google/SOASTA Research via Think with Google, 2017, archived). The effect also runs the other way. A Deloitte study commissioned by Google, covering more than 30 million user sessions, found that a 0.1-second improvement in mobile site speed lifted retail conversion rates by 8.4% (Deloitte/Google, “Milliseconds Make Millions”, 2020).
You pay for every visitor in some way: advertising, SEO work, time spent on social media, printed leaflets with your web address on them. A slow or awkward site throws part of that spend away before anyone reads a word, and none of it shows up as a complaint, because people just leave.
Speed and accessibility are also the same kind of problem. Both come down to whether you’re making visitors work harder than they need to. A layout that jumps as it loads is annoying for most people, but for someone using a screen magnifier, or someone with a tremor aiming at a small button, it can make a page unusable. And for a visitor on a patchy rural connection, a page that takes ten seconds to load doesn’t work at all.
How to check your own scores
You can check all three Core Web Vitals for free in about five minutes using Google’s PageSpeed Insights. Enter your homepage address and read the results for mobile first.
The full step-by-step process is in our guide on how to run a free 5-minute test. Three things on the results page are easy to misread.
1. There are two kinds of data on the results page. The top section, when it appears, shows field data: real visits from Chrome users over the past 28 days. That’s what Google uses. The lower section shows lab data: a single simulated test. Lab data is useful for diagnosing problems, but it isn’t your Core Web Vitals assessment.
2. Small sites often don’t have field data. If your site doesn’t get enough Chrome traffic, PageSpeed Insights will say there’s not enough real-user data and show only the lab test. That’s normal for a lot of small businesses. In that case, treat the lab results as a guide to what’s slow, not a pass or fail grade.
3. The big coloured score isn’t the verdict. The 0 to 100 performance score is a summary of the lab test. It isn’t the same thing as passing Core Web Vitals. A site can score 70 and pass on real visits, or score 90 in the lab and fail with real visitors. Look at the three metrics, not the dial.
It’s also worth running the test on your two or three most important pages, not just the homepage. That usually means your main service page and your contact or booking page, because that’s where a slow load costs you actual enquiries.
The most common fixes (and where mobile fits in)
Five causes account for most slow small business pages: oversized images, weak hosting, too many plugins or add-ons, scripts that block the page from loading, and no caching. Add one common cause of layout jumps, content loading without reserved space, and you have the full list. Each one mostly affects a particular Core Web Vital, which helps you work out where to start.
| Common cause | Metric it mostly hurts | Typical fix | DIY or developer? |
|---|---|---|---|
| Oversized images | LCP | Resize, compress, use WebP or AVIF | Usually DIY |
| Slow or overcrowded hosting | LCP | Move to hosting built for your platform | Depends on platform |
| Too many plugins, apps or scripts | INP and LCP | Remove unused ones, combine overlapping tools | Often DIY |
| Render-blocking scripts and CSS | LCP | Defer non-essential scripts | Developer |
| Images and adverts without reserved space | CLS | Set image dimensions, reserve space for embeds | Developer, usually quick |
| No caching or CDN | LCP | Turn on page caching and a CDN | Usually a setting |
We cover each of these in detail, with a quick way to confirm which one is yours, in the most common causes, cause by cause.
Most CLS problems come from a few specific habits. These include images uploaded without width and height set, cookie banners or promo bars that push content down after it appears, embedded maps or social feeds with no space reserved, and web fonts that swap in late and reflow text. Each one is usually a small fix once it’s identified. Two rows in the table above are developer jobs. If you don’t have a developer yet, read up on how to choose a web design agency before you hire.
Third-party scripts are a common cause of slow responses. Chat widgets, marketing pixels, review carousels and booking tools all run code in the visitor’s browser. Each one seems cheap to add. Together, they’re one of the most common reasons a page feels sluggish when someone taps it.
Where mobile fits in
Mobile matters because Google scores mobile and desktop separately, and mobile is where most sites fail. Mobile pass rates trail desktop by eight percentage points (48% against 56%), and the gap comes from the same causes on less powerful hardware and slower connections.
In the UK, traffic is close to an even split. StatCounter’s August 2026 figures put desktop at 49.2% of UK web traffic, mobile at 46.1% and tablet at 4.7% (StatCounter Global Stats, UK desktop vs mobile vs tablet, retrieved 2026-09-26). Across the sites StatCounter tracks, about half of UK page views come from phones and tablets. Your own mix may be very different. A restaurant, salon or trades business often sees far more mobile traffic than a B2B consultancy, so check your analytics before deciding which matters most.
Headline mobile figures also vary a lot between sources and months depending on what’s measured (page views, sessions or users) and how automated traffic is filtered. Treat any single national percentage as a rough guide. Your own analytics are the number that counts.
On mobile, check that tap targets are big enough, text is readable without zooming, and forms work with a phone keyboard. Our mobile-first design guide covers designing for how most visitors actually arrive.
You might worry that fixing all this means a plainer, duller site. It doesn’t have to: most speed problems come from how design elements are built and loaded, not from the design itself.
Accessibility and security are part of the same picture
A fast site can still shut out disabled visitors, and a site without basic security gives people a reason not to trust it. Speed, accessibility and security are all part of whether your website works for the people who visit it.
Google’s own guidance treats them as related. Its page experience documentation asks site owners six questions, including “Do your pages have good Core Web Vitals?”, “Are your pages served in a secure fashion?” and “Does your content display well on mobile devices?” (Google Search Central, “Understanding page experience”, retrieved 2026-09-26). Performance, security and mobile usability sit on the same checklist.
Why accessibility belongs in the same check
In the UK, 16.7 million people (25% of the population) reported a disability in the 2024/25 Family Resources Survey (DWP, Family Resources Survey 2024/25). The Click-Away Pound Survey found that 69% of disabled internet users have left a website after hitting an accessibility barrier, and only 8% ever tell the site owner (Click-Away Pound Survey, 2019, via AbilityNet). Like a slow page, an inaccessible one loses customers silently.
The most common problems are also the most fixable. WebAIM’s 2026 scan found an average of 56.1 detectable errors per homepage. The top issues were low-contrast text (83.9% of pages), images missing alternative text (53.1%) and form fields without labels (51%) (WebAIM Million 2026).
PageSpeed Insights also runs an automated accessibility check alongside the performance test, and shows a separate Accessibility score further down the same results page. It’s easy to close the tab after reading the speed numbers, so scroll down next time. It won’t catch everything, because automated tools can only detect some accessibility problems and a human check is still needed, but it will flag contrast, missing alt text and unlabelled form fields in the same five minutes.
For the wider business case, see why accessibility is a business question. UK service providers also have duties under the Equality Act 2010. Our guide to WCAG compliance for UK small businesses covers what you’re actually required to do.
Security: the minimum every site needs
Security is the third leg. At minimum, your whole site should load over HTTPS (the padlock in the browser bar). Browsers mark plain HTTP pages as “Not secure”, which is enough to stop many visitors filling in a contact form. Beyond that, keeping your platform, theme and plugins updated is both a security measure and, often, a performance one, because outdated plugins tend to be the bloated ones. Our SSL and security checklist covers the security side of the same picture in full.
Do Core Web Vitals affect your rankings?
Yes, but not as much as many agencies imply. Core Web Vitals are a genuine ranking signal, but they work more like a tie-breaker between similarly useful pages than a way to leapfrog better content.
Google’s own wording is careful. Its documentation confirms that “Core Web Vitals are used by our ranking systems”, but also says that “Google Search always seeks to show the most relevant content, even if the page experience is sub-par” (Google Search Central, “Understanding page experience”, retrieved 2026-09-26). It adds that good results in Core Web Vitals reports don’t guarantee your pages will rank at the top.
In practice, that means:
- A genuinely useful page with average Core Web Vitals will usually outrank a thin page with perfect scores.
- Between two pages that are similarly relevant and useful, page experience can be what separates them. For local businesses competing with near-identical service pages, that can matter.
- Chasing a perfect 100 lab score for SEO is rarely worth the money. Clearing the “good” thresholds is what counts.
The same documentation says Google’s core ranking systems “generally evaluate content on a page-specific basis, including when understanding aspects related to page experience” (Google Search Central, retrieved 2026-09-26). In other words, each important page needs to hold up on its own. Don’t rely on a fast homepage to carry a slow service page.
A full guide to what this actually does to your rankings, with the evidence, covers this in depth.
The bottom line on Core Web Vitals
Core Web Vitals come down to three numbers: how fast your main content loads, how quickly the page responds, and how still it stays. Together, they test whether your website works for the people visiting it, on the phones and connections they use. Speed, mobile usability, accessibility and security all feed into that, so it makes sense to check them together.
You don’t need a perfect score. You need to clear the “good” thresholds on your most important pages, fix the metric that’s furthest off first (usually loading), and not ignore the accessibility score sitting further down the same report.
Start with the free test. Then work through whichever guide below matches what you find. If you’d rather have someone audit performance and accessibility together and tell you what’s worth fixing, get in touch with us. And if the results suggest the problems run deeper than a few fixes, it may be one of the signs your website needs a redesign, and it’s worth checking what a new website costs in the UK before you decide.
Every guide in this series
Check and diagnose
- How to test your website’s page speed for free
- Why is my website slow? 5 common causes and how to fix them
- How Core Web Vitals affect your Google rankings
Design for real visitors
Accessibility and trust
Frequently asked questions
What are Core Web Vitals in simple terms?
They're three measurements of how a web page feels to use: how quickly the main content appears (LCP), how quickly the page responds when you tap or click (INP), and how much the layout jumps around while loading (CLS). Google measures them from real visits and uses them as one of its ranking signals.
Do I need to fix all three Core Web Vitals, or just some?
Start with whichever is furthest from "good", because a page needs to pass all three to be assessed as good overall. For many sites, that's LCP (loading speed), which has the lowest pass rate of the three on mobile according to the 2025 Web Almanac.
Is a perfect 100 PageSpeed score necessary?
No. The 0 to 100 score summarises a single lab test. What Google uses is whether real visits clear the three thresholds. "Good" on all three for your most important pages matters far more than a perfect lab score, and the last few points are often expensive to chase.
Does fixing Core Web Vitals also help accessibility?
Partly. Reducing layout shift and making pages respond quickly helps everyone, especially people using magnifiers or with limited motor control. But most accessibility problems, like low contrast, missing alt text and unlabelled forms, don't affect Core Web Vitals at all, so they need their own check. The Accessibility score in PageSpeed Insights is a good free starting point.
How long does it take to see results after fixing these?
Conversion and bounce improvements can show up as soon as the changes are live, because visitors feel the difference immediately. Core Web Vitals field data in PageSpeed Insights is based on the previous 28 days of visits, so allow about four weeks for it to fully reflect your changes. Any ranking effect is slower and harder to isolate, because Core Web Vitals are only one of many signals.
Where do I start if I've never checked any of this before?
Start by running your homepage and your main service page through PageSpeed Insights, reading the mobile results first. Our guide on how to test your website's page speed for free walks through it step by step and explains what each number means.