Why Most Small Business Websites Fail Google's Core Web Vitals (And How to Fix Yours)

Google scores every website on three speed and usability tests called Core Web Vitals. Most small business sites fail at least one. Here's what that means, why it matters, and how to fix it.

If you've ever searched for your business on Google and wondered why a competitor with a worse website ranks above you, their Core Web Vitals might be part of the answer. Google has been using these scores as a ranking factor since 2021, and most small business owners have never heard of them.

The good news: you can check yours for free in about 30 seconds. The bad news: there's a decent chance you'll fail.

What are Core Web Vitals?

Core Web Vitals are three tests Google runs on websites to measure how fast and stable they feel for real visitors. They don't care how pretty your site looks. They care how it behaves.

1. LCP — Largest Contentful Paint

In plain English: How long does it take for the biggest thing on the page to show up? That's usually your main image or headline text.

Google wants this under 2.5 seconds. If it takes longer, visitors are staring at a blank or half-loaded page, and many of them will leave before it finishes.

2. INP — Interaction to Next Paint

In plain English: When someone taps a button or clicks a link on your site, how long before something visibly happens? INP replaced the older FID (First Input Delay) metric in March 2024.

Google wants this under 200 milliseconds. If there's a noticeable lag between clicking and seeing a response, your site feels broken — even if it's technically working.

3. CLS — Cumulative Layout Shift

In plain English: Does stuff jump around on the page while it loads? You know when you're about to tap a button and an advert or image suddenly pushes everything down the page? That's layout shift, and it's infuriating.

Google wants this score under 0.1. Higher means things are moving around too much.

Why does Google care about this?

Google's entire business depends on sending people to good websites. If Google keeps sending users to slow, glitchy sites, people stop trusting Google's results and switch to something else.

So Google rewards fast, stable sites with better rankings, and penalises slow, jumpy ones. It's not the only ranking factor — good content and backlinks still matter enormously — but when two sites are otherwise equal, the faster one wins.

What happens if your site fails?

You won't vanish from Google overnight. Core Web Vitals are a tiebreaker, not an on/off switch. But here's what actually happens in practice:

• You lose mobile rankings first. Mobile is where Google applies page experience signals most aggressively, and mobile is where most people search.
• Your bounce rate goes up. Even if Google still shows your site, visitors leave when pages load slowly. Studies consistently show that every extra second of load time increases the chance someone hits the back button.
• Your competitors pull ahead. If they fix their Core Web Vitals and you don't, the gap between your rankings widens over time.

The 5 most common reasons small business sites fail

1. Oversized images

This is the single biggest problem I see. Someone uploads a photo straight from their phone or camera — a 4MB, 4000-pixel-wide image — and uses it as a banner. The browser has to download all 4MB before it can display the page properly, and your LCP score goes through the floor.

How to fix it:

• Resize images to the actual size they'll display at. If your banner is 1200 pixels wide on screen, the image file shouldn't be 4000 pixels wide.
• Convert images to WebP format. It produces files roughly 30% smaller than JPEG with no visible quality loss. Most image editors and online converters support it now.
• Aim for under 200KB per image. Hero images can be a bit larger, but anything over 500KB should set off alarm bells.
• Use lazy loading on images that aren't visible when the page first loads. This tells the browser "don't bother downloading this until the user scrolls down to it."

2. Cheap shared hosting

Budget hosting (the kind that costs a few pounds a month) puts hundreds of websites on the same server. When another site on your server gets busy, your site slows down. The server itself might take over a second just to start responding, before it even sends any of your website's files.

This delay is called TTFB (Time to First Byte) — how long the server takes to begin sending data back to the browser. If your TTFB is over 800 milliseconds, you're already behind before anything else even loads.

How to fix it:

• Move to a better hosting provider. You don't need anything expensive — decent managed WordPress hosting starts around £10-20/month and makes a noticeable difference.
• Consider a VPS (Virtual Private Server) if your site gets reasonable traffic. Your site gets its own dedicated slice of a server instead of sharing everything.
• At minimum, make sure your hosting has servers in the UK if your customers are in the UK. A server in America adds 100-200ms of delay to every single request from a British visitor.

3. Too many plugins (WordPress sites)

Every WordPress plugin adds extra code. Some add JavaScript files. Some add CSS files. Some add both, on every single page, even pages where that plugin does nothing. I've audited WordPress sites loading 40+ separate CSS and JavaScript files before the actual content even starts appearing.

How to fix it:

• Audit ruthlessly. Go to your plugins list. If you don't know what a plugin does or can't remember the last time you used it, deactivate it and delete it.
• Replace heavy plugins with lighter alternatives. A contact form doesn't need a plugin that loads 300KB of JavaScript. Simple solutions exist for most common tasks.
• Watch out for page builders. Elementor, Divi, WPBakery and similar tools add massive amounts of code to every page. They make building easy, but the performance cost is real.
• Aim for under 15 plugins total. Some well-built sites run on 5-8.

4. Render-blocking scripts and stylesheets

When your browser loads a web page, it reads the code from top to bottom. If it hits a JavaScript or CSS file, it stops everything, downloads that file, processes it, and only then continues loading the rest of the page. These are called "render-blocking resources" because they literally block the page from appearing.

Many small business sites load Google Fonts, analytics scripts, chat widgets, social media buttons, and tracking pixels all in the head of the page. The browser has to fetch and process every single one before showing the visitor anything at all.

How to fix it:

• Move non-essential JavaScript to the bottom of the page, or add the defer attribute so it loads in the background without blocking the page.
• If you use Google Fonts, add display=swap to the font URL so text shows immediately in a system font while the custom font downloads.
• Delay third-party scripts (chat widgets, social buttons, analytics) until after the page has loaded. Most of these have an "async" or "deferred" loading option.
• Inline your critical CSS — the styles needed for what the visitor sees first — directly in the HTML, so the browser doesn't have to wait for a separate file.

5. No caching

Caching means telling the browser "you've already downloaded this file, use the copy you saved last time instead of downloading it again." Without caching, every single page visit forces the browser to re-download every image, every stylesheet, every script. Every time.

Many small business sites have no caching headers set at all. That means even a returning visitor gets the same slow experience as their first visit.

How to fix it:

• Set browser cache headers on your server. For static files like images, CSS, and JavaScript, a cache duration of 1 year is standard. This is usually a few lines in your server configuration or .htaccess file.
• If you're on WordPress, install a caching plugin like WP Super Cache or W3 Total Cache. These generate static HTML versions of your pages so the server doesn't have to rebuild them from scratch for every visitor.
• Use a CDN (Content Delivery Network). Services like Cloudflare have free tiers and store copies of your site on servers around the world, so visitors get files from a server near them instead of one possibly on another continent.

Quick wins: the fastest fixes

If you want the biggest improvements for the least effort, do these three things first:

1. Compress your images. Run every image on your site through Squoosh (free, from Google). Convert to WebP, resize to actual display dimensions. This alone fixes most LCP failures.
2. Sign up for Cloudflare's free tier. It adds caching, a CDN, and basic performance improvements with minimal setup. It won't fix everything, but it helps immediately.
3. Remove plugins and scripts you don't need. Every one you remove is code your visitors no longer have to download.

How to test properly

When you run Google PageSpeed Insights, pay attention to two sections:

• Field data (top section) — This is real data from actual Chrome users who visited your site. If your site doesn't get enough traffic, this section might be empty. That's normal for smaller sites.
• Lab data (lower section) — This is a simulated test run on the spot. It's useful for diagnosing problems, but the field data is what Google actually uses for rankings.

Always test your mobile score, not just desktop. Mobile is where most of your visitors are, and mobile scores are almost always worse than desktop because phones have less processing power and often slower connections.

Test your homepage, but also test your most important landing pages. A fast homepage doesn't help if your services page takes 8 seconds to load.