Aim for a Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. If your site misses those Core Web Vitals marks, start with image optimisation, then run PageSpeed Insights on your main conversion page to see where you actually stand.
TL;DR:
- Most small business websites fail to meet Google’s Core Web Vitals, with only 3% passing speed benchmarks and the majority sitting above the “good” range.
- Fixing image delivery, enabling caching, and deploying a content delivery network can significantly improve load times and drop your site’s Cumulative Layout Shift below 0.1.
- Testing your site’s speed on mobile first with tools like PageSpeed Insights and Google Search Console is essential, as mobile speeds are almost always worse than desktop.
- Common causes of slow performance include oversized images, slow hosting, third-party scripts, unminified code, and lack of caching or a CDN.
- When improvements plateau despite fixes, it often indicates deeper hosting or architecture issues that may require professional diagnostics.
Table of Contents
- Why small business website speed affects your bottom line
- How do you measure your website’s speed?
- What usually causes a slow small business website?
- What should you fix first this week?
- When should you bring in a professional?
- Practical rules I follow when fixing client sites
- Get your site’s speed sorted without the guesswork
- Sources
Why small business website speed affects your bottom line
Slow pages cost you enquiries before a visitor even reads your headline, and you can learn how to boost SEO and conversions with faster website speed. Every extra second of load time chips away at the number of people who stick around long enough to call, book, or buy.
A scan of small business sites found that only 3% pass Google’s Core Web Vitals thresholds, with most sitting well above the “good” range on speed benchmarks. That’s not a niche problem. It’s the norm, which means most of your competitors are probably just as slow, and fixing your site is a genuine way to pull ahead.
Statistic Callout: Nearly all small business sites tested failed to meet Google’s own speed benchmark, according to that same independent scan.
Trust matters more when you’re small. A big retailer can survive a clunky checkout because shoppers already know the brand. You can’t. A visitor bouncing off a slow page has no loyalty pulling them back, so speed becomes part of your first impression, whether you like it or not. Google also treats Core Web Vitals as a ranking signal, measured from real user field data rather than a one-off lab test, so a slow site quietly loses ground in search over time too.
How do you measure your website’s speed?
Skip the guesswork. Run these tools against your actual site before touching anything:
- PageSpeed Insights gives you both lab data (a simulated test) and field data (real visitor experience) for the same URL, and it’s the tool Google itself points to for performance measurement.
- Lighthouse (built into Chrome DevTools) breaks down exactly which resources are slowing your page and by how much.
- WebPageTest lets you test from different locations and connection speeds, useful if your customers aren’t all on fast city broadband.
- Pingdom adds ongoing monitoring so you catch regressions between manual checks, not just at a single point in time, via its speed test tool.
- Google Search Console shows your Core Web Vitals field data across your whole site, aggregated at the 75th percentile, which is what actually influences rankings.
In plain terms: LCP is how long the biggest visible element (usually a hero image or headline) takes to load. INP measures how fast the page responds when someone taps a button or fills a form. CLS tracks whether content jumps around as the page loads, the thing that makes you misclick a menu on your phone. TTFB is how quickly your server sends back the first byte of data, a decent proxy for hosting quality.
For a quick test routine, pick your homepage plus your two highest-traffic landing pages, run each through PageSpeed Insights on both mobile and desktop, and write the numbers down somewhere you’ll actually check again.
Pro Tip: Always test mobile first. Most small business traffic skews mobile, and mobile results are almost always worse than desktop, sometimes dramatically so.
What usually causes a slow small business website?
Most speed problems trace back to a handful of repeat offenders. Once you know what to look for, diagnosis gets a lot faster.
- Oversized images with no responsive sizing (
srcset) or modern formats like WebP or AVIF, often the single biggest culprit behind a slow LCP. - Budget or shared hosting with high Time to First Byte, sometimes made worse by a DNS provider that’s slow to resolve.
- Third-party scripts, chat widgets, tracking pixels, and heavy plugins that block the browser from rendering the page.
- No caching configured and no content delivery network, so every visitor pulls resources from a single, possibly distant, server.
- Render-blocking CSS and JavaScript, unminified code, and redirect chains that add extra round trips before the page even starts loading.
Most sites don’t have just one of these. They have three or four stacked on top of each other, which is why a single fix sometimes barely moves the needle.
What should you fix first this week?
Work through these in order. Each one builds on the last, and doing them out of sequence tends to waste effort.
- Fix your images first. Resize them to the dimensions they’re actually displayed at, compress them, and convert to WebP or AVIF. Tools like TinyPNG routinely cut file size by 60 to 85% with no visible quality loss. Never lazy-load your LCP image. It needs to load immediately, not after the browser decides it’s worth fetching.
- Turn on caching and a CDN. Set proper cache headers so returning visitors aren’t re-downloading everything, and put your site behind an edge network. Cloudflare connects through more than 335 cities globally and offers meaningful performance gains even on its free tier.
- Audit your scripts and plugins. List every third-party tag running on your site, remove anything you don’t actually use, and defer the rest so they load after the main content.
- Check your hosting. If your TTFB is consistently high, that’s a hosting problem, not a code problem. Managed hosting with server-side caching and Brotli compression often fixes this without touching a single line of your site.
- Measure, document, repeat. Run the same tests before and after each change, and keep a simple changelog. Without that, you’re guessing whether anything actually worked.
Statistic Callout: Image compression alone can reduce page weight enough to meaningfully shift your LCP score, since images remain the highest-leverage quick win for most small business sites.
For many small operators, fixing image delivery and switching on a CDN delivers a faster return than a full code rewrite, because it takes hours rather than weeks and doesn’t touch anything fragile in your existing build.
When should you bring in a professional?
DIY fixes solve most speed problems. Some don’t budge no matter what you try, and that’s your signal to call someone.
Watch for these specific warning signs:
- Your LCP or TTFB stays high after image and caching fixes, which usually points to a deeper hosting or architecture issue.
- You’re running complex integrations (booking systems, custom checkouts, membership plugins) that a generic fix might break.
- The same performance problem keeps coming back after you’ve “fixed” it once, a classic sign of an unresolved root cause.
A proper engagement should include full diagnostics across lab and field data, a prioritised list of fixes ranked by impact, a rollback plan before anything goes live, and measurement at the 75th percentile once work is done, not just a screenshot of one good test run. Ask any provider how they’ll measure success and what happens if a change breaks something. If they can’t answer either question, or they talk in vague promises without numbers, that’s a red flag.
Pro Tip: Ask a potential provider to show you a before-and-after Core Web Vitals report from a past client. If they can’t produce one, they probably haven’t been tracking outcomes properly.
Techbug approaches this as managed IT services covering hosting, CDN setup, security, and ongoing monitoring, backed by prior website builds where performance was part of the brief from day one.
Practical rules I follow when fixing client sites
Impact-first, always: images, then caching, then hosting, then scripts, then code. Skipping ahead to a code rewrite before fixing images is the most common wasted effort I see. Most small business sites see a genuine, visible improvement within two to three weeks of focused work, not months. Judge ROI by re-testing at the same three pages you started with, at the same time of day, and only call a fix successful once the field data confirms it, not just the lab test.
— Ru
Get your site’s speed sorted without the guesswork
Techbug is the practical alternative to piecing together speed fixes yourself: instead of juggling plugins, cache settings, and hosting tickets across three different logins, you get one team that handles hosting, CDN configuration, and image and script cleanup as a single job.
That matters because most of the small business sites we’ve assessed fail Core Web Vitals for reasons stacked on top of each other, not one isolated bug, and untangling that takes someone who’s done it before. Techbug’s managed IT services cover the hosting and monitoring side of this permanently, so speed doesn’t quietly slide backwards six months after a fix. If you’re tired of chasing scores in PageSpeed Insights with no lasting change, get in touch for a diagnostic review of your site and a plain-English list of what’s actually slowing you down.