Website Speed: Why Slow Sites Lose UK Customers (and the Fixes That Actually Matter)

Quick answer

Speed is a revenue setting, not a technical nicety: the probability a visitor abandons rises steeply with every second of load time, and Google folds speed signals (Core Web Vitals) into ranking. The good news for small business sites is that speed problems are boringly consistent — oversized images, cheap overloaded hosting, and plugin bloat account for most of the slowness on most sites — and fixing those three gets a typical site from sluggish to solid without a rebuild.

What slow actually costs

Industry studies have shown the same shape for years: as mobile load time goes from 1 to 3 seconds, bounce probability rises by roughly a third; by 5 seconds it has nearly doubled. Translate that to a trade or service business: if 200 people a month reach your site and a slow load loses an extra 20% of them before the page even appears, that’s 40 evaporated visitors — several quotes’ worth — every month, silently. Speed is also a trust cue: a site that grinds tells the visitor something about how the business runs, fairly or not. It’s one of the failure patterns we covered in why your website is losing you customers.

The 80/20 of speed fixes

Images first, always. The classic SME pattern is a 4,000-pixel phone photo (4MB+) squeezed into a 400-pixel space — ten of those on a homepage is 40MB of needless download. Resize to the displayed size, convert to WebP, compress at 80% quality: the visual difference is invisible, the speed difference is dramatic.

Hosting second. If the server takes over a second to send the first byte, nothing downstream can save you. £3/month shared hosting stacks hundreds of sites per server; the £10–£30/month tier fixes more speed problems than most optimisation plugins — the honest breakdown is in what UK hosting should cost.

Plugins third. Every active plugin potentially adds scripts, styles and database queries to every page load. The audit rule from our WordPress maintenance guide applies: if you can’t say what it does, deactivate it; if nothing breaks in a month, delete it.

How to test properly (free, five minutes)

1. PageSpeed Insights (Google’s tester) on your homepage and your most-visited service page — mobile scores matter most, since that’s both most of your traffic and Google’s index.
2. Read the “Opportunities” list, not just the score: it names the actual offending images and scripts. Fix the top three; retest.
3. Feel it on 4G: load your site on your phone off wifi, somewhere with mediocre signal — your customers’ reality, not your office fibre.
4. Don’t chase 100/100. A mobile score in the 70s–90s with green Core Web Vitals is a healthy business site; the last ten points cost more than they return.

When it’s not worth optimising

If the site is slow because of what it is — a decade of page-builder layers, a nulled theme, sixty plugins doing three jobs — optimisation is bailing a leaking boat. The honest threshold: if the top PageSpeed offenders are all theme and builder framework files rather than your content, you’re in refresh-vs-rebuild territory, and the money is better spent there. For everyone else: images, hosting, plugins, cache — in that order, this month. Keeping it that way is exactly the sort of thing a management and hosting plan exists for.

The thresholds Google actually measures

“Fast” is not a feeling in the Core Web Vitals system, it is three specific measurements with published pass marks, and knowing them stops you chasing the wrong thing. Largest Contentful Paint — how long until the main content appears — should be under 2.5 seconds. Interaction to Next Paint, which measures how quickly the page responds when someone taps, should be under 200 milliseconds. Cumulative Layout Shift, the amount the page jumps about while loading, should be under 0.1.

Those three fail for different reasons, which is why a single “score” is a poor diagnostic:

Layout shift is the one owners never think about and customers hate most: the tap that lands on the wrong button because a cookie banner appeared is a lost enquiry that no analytics report will ever attribute to speed. It is also entirely free to fix.

The third-party tax

Most SME sites are not slow because of their own code. They are slow because of what has been bolted on: a live chat widget, a review carousel, a booking embed, a heat-mapping script, two analytics tools, a social feed and a font service. Each is a request to somebody else’s server, and your page waits for all of them.

• Chat widgets are commonly the single heaviest thing on a small business site. Load them on click rather than on page load, or use a simple call and WhatsApp button instead.
• Embedded review carousels often cost more in load time than the trust they buy. Pull the reviews in as plain text and link out to the profile.
• Self-hosted fonts beat externally hosted ones on both speed and privacy, and limiting yourself to two weights instead of six typically saves several hundred kilobytes.
• Video backgrounds in the hero area are the most expensive design decision available. If the site must have one, use a poster image and load the video afterwards.
• Duplicate tracking accumulates quietly — audit your tags annually and delete the ones from agencies you no longer work with.

A useful rule of thumb: if a third-party feature would have to earn one enquiry a month to justify itself, and you cannot say whether it ever has, it is a candidate for removal. Which features actually pull their weight is a measurement question, and the small set of figures worth watching is covered in website analytics for beginners.

What the fixes cost in the UK

The first four rows together typically cost less than £1,000 through a developer and resolve the majority of speed complaints on a standard WordPress brochure site. Spending £4,000 on a rebuild before trying them is the commonest way to overpay, and the honest comparison of what a build should cost either way is in what a website costs in the UK. Where a monthly plan already includes hosting, updates and optimisation, that work should be inside the fee rather than a surprise invoice — the model behind our website subscription, and a fair question to ask any provider charging a monthly retainer.

Mistakes that make sites slower

1. Installing three optimisation plugins. They fight each other, and the resulting minified-and-deferred mess breaks layouts. One caching and optimisation plugin, configured carefully, is the ceiling.
2. Testing while logged in. Admin bars, editors and cache exclusions mean your logged-in experience is not the customer’s. Test in a private window.
3. Optimising the homepage only. Most search traffic lands on service and blog pages, and those are frequently the heaviest.
4. Deactivating plugins instead of deleting them. Deactivated plugins add no speed cost but keep every security hole they shipped with, which is the point made at length in WordPress security for small businesses.
5. Uploading images straight from a phone or a stock library. The 4,000-pixel original never needed to be on the server, and no plugin fully undoes it.
6. Chasing a 100 score. The last stretch usually means removing things customers use. Green vitals on real-user data is the finish line.

What to ask before you pay for “speed optimisation”

Ask for before-and-after figures on the three vitals for three named pages, not a screenshot of a score. Ask which changes are configuration and which are code, because configuration survives a theme update and hasty code edits often do not. Ask what happens at the next major plugin update — a site made fast by disabling half its functionality tends to un-fix itself within a quarter. Ask whether field data, the real-visitor measurements Google collects, is being used rather than only lab tests, since a site can score well in a lab test and still be slow on a phone on rural 4G. And get the maintenance arrangement in writing, because speed is a state a site drifts out of, not a job you finish once.

Sources & Further Reading

• Core Web Vitals — web.dev
• PageSpeed Insights — Google
• Page Experience in Search — Google