Why website speed costs you customers (and how to fix it)

Almost every slow website I look at is slow for the same four reasons: photographs uploaded straight off a phone at 4 MB each, a pile of JavaScript from plugins and a page builder, web fonts holding up the first paint, and hosting that takes most of a second to answer. None of it is exotic. Most of it you can fix yourself in an afternoon without paying anybody.

Fixing it matters because slow pages lose you work. Somebody taps your listing, waits, sees white, and goes back to the results to try the next business in the list. You paid for that visit whether it arrived from Google, from an ad or off the side of your van. Below is what the delay actually costs, the three numbers Google measures, and the five fixes in the order I would do them.

What a slow site costs you

Start with the money rather than the metrics. Someone arriving from a search result has your page and four competitors half-open in their head. If nothing has appeared by about three seconds, a real share of them tap back. Nobody rings a plumber whose website they never saw.

The ranking damage works more simply than most SEO writing suggests. Google is not sitting there with a stopwatch deciding you deserve position seven. It watches behaviour: people arrive, leave quickly, click a different result and stay there. Repeat that a few thousand times and the other page starts to look like the better answer.

Core Web Vitals are a confirmed ranking signal, but a light one. Relevance still wins. Speed is the tie-breaker between two pages that are otherwise equally useful, which in local search describes most pages. Don't expect a rebuild to lift you from page three to page one on speed alone. If you are nowhere at all, that is a different problem with a different set of causes.

The conversion effect is better evidenced than the ranking effect. Google and Deloitte's 2020 study of large retail and travel brands found that a 0.1 second improvement in mobile load time lifted retail conversions by roughly 8% and travel by roughly 10%. Those were enormous sites with enormous samples. A six-page site for a Kent electrician will not behave like a national retailer, so treat the direction as real and the magnitude as unknown.

Paid traffic is where it stings most, because you can put a price on it. Say you spend £600 a month on Google Ads at £2.50 a click. That is 240 clicks. If your page takes five seconds on mobile and a quarter of those people leave before it renders, you have spent about £150 that month on nothing at all. Google also feeds landing page experience into Quality Score, so a slow page tends to raise your cost per click as well. It doesn't publish the multiplier and I am not going to invent one.

Core Web Vitals in plain English

Google reduces speed to three measurements. Underneath the acronyms they ask three ordinary questions: did the main thing appear, does it respond when I tap it, and does it stay still?

All three are judged at the 75th percentile of real visits, so a quarter of your visitors can be having a worse time than the number suggests. That matters if half your audience is standing outside on one bar of signal.

LCP is the one you will fail. It marks the moment the largest element in view finishes rendering, which on a small-business site is nearly always the hero image, or the headline sitting on top of it. A typical page-builder site over mobile data lands somewhere between 3.5 and 6 seconds. Hand-built pages with properly sized images come in under 1.5.

INP is about responsiveness. It replaced the old first-input-delay measure in March 2024 and records how long the page takes to react when you tap something. Most brochure sites pass this without trying, because there is nothing much to interact with. When it fails, the cause is JavaScript: a chat widget, a booking script or a slider hogging the main thread while somebody jabs at your menu.

CLS is the sneaky one. It scores how much the layout shuffles about while loading, and small-business sites fail it constantly. Images with no width and height, a cookie banner that shoves everything down, a review widget that arrives late and moves the button you were about to press.

Layout shift is the reason people tap the wrong thing and leave annoyed. It costs you enquiries without ever registering as slowness.

The five fixes that account for most of the gain

Roughly in order of gain per hour spent. If you only ever do the first two, you will get most of the way there.

1. Images

Stop uploading phone photos. A current phone produces a 4032 × 3024 JPEG somewhere between 3 and 6 MB, and your page displays it 800 pixels wide. On a mid-range Android with a weak signal that one file can take five or six seconds by itself, and because it is usually the LCP element, your whole score hangs off it.

The fix is boring and it is nearly total. Resize to about twice the display width (1600 px covers most heroes), export as WebP at quality 75 to 80, and a 4 MB photo becomes roughly 150 KB with no visible difference on a phone. Squoosh does it free in a browser tab. On WordPress, one plugin handling conversion and resizing beats three doing overlapping jobs.

Then add loading="lazy" to everything below the fold, and leave it off the hero. This is the bit people get wrong: lazy-loading your LCP image delays the exact thing you are being measured on. Set width and height attributes while you are in there, which fixes half your layout shift for free.

2. Too much JavaScript

Second biggest, harder to fix, and the reason page-builder sites plateau. Every plugin tends to add its own script and stylesheet to every page, whether that page uses the feature or not. A contact-form plugin loads on your about page. A slider loads where there is no slider.

Audit it honestly. Go through the list and ask what each one earns you. Live chat is the usual offender: an embed commonly pulls 300 to 600 KB of JavaScript, and if nobody answers it after five o'clock it is slowing your site down in order to do nothing. Tag Manager containers are the other one, quietly holding twelve tags for tools you stopped using two years ago.

Heat maps, two analytics platforms, three ad pixels, an exit-intent popup, a review carousel. Each is defensible alone. Together they are why your homepage makes a phone warm.

3. Fonts

A smaller win, but visible. Two families maximum, one for headings and one for body text, and no more than four weights between them. Every extra weight is another file the browser has to fetch before your text can appear in the right typeface.

If you load from Google Fonts, add preconnect hints for fonts.googleapis.com and fonts.gstatic.com so the connection opens early. Self-hosting the woff2 files on your own domain is faster again and removes a third-party dependency. Either way set font-display: swap so text renders in a fallback immediately instead of sitting invisible, and choose a fallback with similar proportions so the swap doesn't jolt the layout.

4. Hosting and caching

This is the one you cannot fix with better habits, and the one place where cheap is genuinely false economy. On £3-a-month shared hosting I regularly see a time-to-first-byte of 800 ms to 1.5 seconds, which is dead time before a single pixel of your page can be drawn. Decent hosting answers in 100 to 200 ms.

For WordPress, moving to a host at £15 to £25 a month that does proper server-side caching and puts a real CDN in front of you is the best-value upgrade on this list. For a brochure site, static hosting on Netlify or Cloudflare Pages costs nothing and beats anything you can buy, because there is no database to query and the page already exists. Add page caching either way, and check it hasn't been silently switched off, which happens more often than you would think after a theme update.

5. Layout stability

Cheap, quick, and almost always skipped. Width and height attributes on every image and video, so the browser reserves the space before the file arrives. Fixed aspect-ratio containers for anything embedded: maps, YouTube, review widgets, booking iframes.

Load the cookie banner as an overlay rather than something that pushes the page down, and test what your consent tool does on a slow connection. Most layout shift on a small site comes from three or four elements. An hour of work usually clears the lot.

How to measure without fooling yourself

PageSpeed Insights gives you two things and most people read the wrong one. The big score at the top is a lab test: a simulated mid-range Android on a throttled connection, run once, in a data centre somewhere. It is useful for diagnosis. It is not what your customers experienced.

Scroll down instead. If your site gets enough traffic, the field data section reports what real Chrome users on your pages actually got over the previous 28 days. That is the data Google uses. Search Console's Core Web Vitals report shows the same thing grouped by page type, which is the faster way to find the one broken template rather than auditing forty URLs by hand.

Lab scores mislead in both directions. I have seen a 98 in Lighthouse alongside failing field data, because the test never sits through a cookie banner, a chat widget waking up, or a font server having a bad afternoon. I have also seen a mediocre 62 on a site whose real visitors were all perfectly happy. Chasing the number rather than the experience is how people end up spending £2,000 to go from 84 to 96 and gaining nothing.

So test on a real phone. Not your iPhone on office wifi. Borrow something two or three years old, walk outside, put it on mobile data and load your own homepage while counting seconds. If you get bored before the page appears, you have your answer and no score is going to argue with you.

The uncomfortable truth about page-builder sites

If your site is built in Elementor, Divi, WPBakery or something similar, there is a ceiling and you should know where it sits. These tools work by wrapping every element in extra markup and shipping their own CSS and JavaScript framework to render it. The overhead is the product. It is not a setting you can switch off.

Realistically, a well-maintained builder site with good hosting, sorted images and a trimmed plugin list gets to an LCP of about 2 to 2.5 seconds on mobile and a Lighthouse score in the 60s to 80s. That passes. It is fine. What it will not do is match a hand-built static page, where an LCP under 1.5 seconds on 4G is a realistic target, and no amount of tuning takes a builder there.

Which means the honest recommendation is usually not a rebuild. If your builder site sits at 3 seconds, spend a day on images, plugins and hosting to get it to 2. That is a day or so of work against a full rebuild, and the remaining difference will not decide whether somebody rings you. Rebuild when the site is wrong in other ways too, and let the speed arrive as a side effect. I have written separately about when a builder is the right answer and when it starts costing you work.

One more unprofitable thing. If you get 150 visits a month, speed is not your problem. Nobody is bouncing off a page they never found. Fix the images because it takes an afternoon, then put the money into pages that answer what people actually search for. I would rather say that than sell you a performance audit you don't need.

Two sector-specific notes, because speed does not cost every business the same amount. On a premium e-commerce brand the losses show up in order value rather than bounce rate, which I have written about in what urgency apps really cost. On a property or design-led site, where heavy imagery is the product, the trade-off is different again and covered in when animation earns its keep.

If you would rather someone else did the work, send me the URL. I will tell you which of the five is costing you most and whether it is worth paying anybody to fix it. Start there.