Someone searches for what you sell. Your business comes up. They tap it, on a phone, somewhere with ordinary signal.
And then they wait. Three seconds. Five. Eight.
They go back and tap your competitor instead.
You will never hear about this. Nobody emails to say your website was slow. The enquiry simply doesn't arrive, and the day looks like any other quiet day.
We recently audited a site where a version of this was happening on every visit. A real business, 63 pages, ranking respectably, tens of thousands of people seeing it in Google every few months. Its homepage took 14.6 seconds to show its main content on a phone.
Here is what was actually wrong, in plain English, and what it was costing. It is a site we look after, which is the only reason we can publish real numbers rather than general advice.
Your regular customers may be looking at an old version of your site
Start with the strangest finding, because almost nobody checks it and it is worryingly common.
Websites tell your visitor's browser how long to keep a saved copy of things like the site's styling. Saving a copy is a good idea — it means someone coming back doesn't download everything again, so the site feels quick.
This site told browsers to keep that copy for a year, and not to bother checking whether a newer one existed.
That is a perfectly normal, modern setting. It is only safe if the file's name changes every time its contents change, so browsers can tell something new has arrived. On this site, it didn't.
When we checked what the live site was actually handing to visitors, the styling file coming back was fifty-six days old.
Think about what that means commercially. Every improvement made to that site over the previous two months was sitting there, live, and completely invisible to anyone who had visited before. New visitors saw the current site. Returning visitors — the ones who already liked you enough to come back — were shown the version from two months ago, and would have kept seeing it for up to a year.
It is the online equivalent of refitting your shop and discovering that every existing customer still walks into the old one.
We had just spent a day making this site faster. Without catching this, none of that work would have reached the people most likely to buy.
If you take one thing from this article, take this. Ask whoever looks after your site: "when you change our styling or code, does the file name change too?" A confident yes is a good sign. A vague answer means your recent improvements may not be reaching your existing customers.
The site made every visitor stand in a queue
The main reason for that 14.6 seconds was a queue nobody could see.
A website's appearance comes from styling files. This site had one main styling file, and that file didn't contain any styling. It contained a list pointing at nine other files.
So the browser had to fetch the first file, read it, discover there were nine more, and only then start fetching those — one after another, in strict order. It could not know they existed in advance, and it could not collect them all at once.
Picture a relay race where each runner has to finish before the next one is even told they're taking part. That was happening on all 63 pages, every time anybody visited.
We combined those nine files into one. The design didn't change. The content didn't change. Nothing about the site looked any different.
The homepage went from 14.6 seconds to 5.8 seconds.
One change, and the browser simply stopped waiting.
Two pictures nobody could see properly
Next: the background image on the homepage was 1.84 MB, and another image further down was 1.98 MB. Together, nearly four megabytes — a substantial download on mobile data before anyone sees anything useful.
The background one is the instructive case. It sits behind a dark overlay at low opacity, so you can barely make it out. It was carrying almost two megabytes of fine detail that the design deliberately hides.
Saved in a modern image format, it came out at 95 KB — about 5% of the original — and looks identical. The second went from 1.98 MB to 112 KB.
Roughly four megabytes of the page turned into a couple of hundred kilobytes, with no visible difference at all.
This is the single most common thing we find, and it is never anybody's fault. Someone exports a photo at the quality they'd want for print, uploads it, and checks it on the office broadband where everything is fast.
Why one fix did nothing until we made another
After combining the styling files, the homepage had gone from 14.6 seconds to 5.8. Then it stopped improving, no matter what else we tried.
The reason is worth understanding, because it explains why speed work needs measuring rather than a checklist.
The site loaded its fonts in a way that stopped anything at all appearing on screen until the font file arrived — a blank page, held for 2.6 seconds. And the main content obviously cannot appear before anything appears. That 2.6 seconds was a floor. Every other improvement was hitting it and stopping.
Changing how the fonts load — so the page appears immediately and the fonts arrive a moment later — removed the floor. The site already had sensible backup fonts defined, so the brief moment before they load looks fine rather than jarring.
The general lesson: slow websites are usually a queue, not a list of faults. Fix the wrong thing and nothing happens, because something else is still blocking the way. That is why we measure between each change instead of working through a generic checklist and hoping.
What this costs in real terms
It is tempting to read all this as a technical scorecard. It isn't one.
Someone on a phone, on mobile data, looking at a blank screen for fourteen seconds, is gone. And the loss is invisible — no complaint, no feedback, just a competitor getting the job.
This site was already ranking. It was already being seen by tens of thousands of people in search results. All that work was being wasted at the front door. And because of the caching problem, even the people who came back — the warmest possible audience — were being handed the old, slow version.
Speed also affects your Google ranking directly, so a slow site is quietly held back in the very results it is trying to win. But the lost enquiries are the bigger cost, and they arrive first.
Five checks you can do yourself in ten minutes
You don't need a developer for the first pass:
- Search for "PageSpeed Insights", put your homepage in, and read the mobile score — not the desktop one. Desktop flatters nearly every site. Your customers are on phones.
- Find the line called Largest Contentful Paint. That's how long until the main thing on the page appears. Under 2.5 seconds is good. Over 4 seconds is costing you money.
- Check your biggest image. Right-click the main picture on your homepage, save it, and look at the file size. Anything over about 300 KB is worth a question.
- Open your site in a private browsing window, then in your normal browser. If they look different, something is being saved that shouldn't be.
- Ask the file-name question above. How confidently it gets answered tells you a lot.
If that turns up something you would rather not unpick yourself, our free website audit covers exactly this ground. The fixes themselves are web development and web design work, and because speed feeds directly into how findable you are, it connects straight to our AI and SEO side too.
Frequently Asked Questions
How fast should my website be?
The number to look at is called Largest Contentful Paint — how long before the main content appears — measured on mobile. Under 2.5 seconds is good, 2.5 to 4 seconds needs attention, and over 4 seconds is actively losing you enquiries. Always read the mobile figure rather than the desktop one, because desktop flatters almost every site.
Why does my website look different in a private browsing window?
Almost always because your normal browser is holding on to a saved copy of an older version, while the private window fetches everything fresh. It usually means your site's files are set to be saved for a long time but their names never change, so browsers never discover that a newer version exists.
Does a slow website really affect my Google ranking?
Yes, speed is one of the things Google measures when deciding how to rank pages. But the bigger and faster-arriving cost is simply lost customers: someone who gives up on a slow page never becomes an enquiry, and never tells you why.
Will making my images smaller make them look worse?
Usually not in any way a visitor would notice. Converting a photo to a modern image format typically cuts the file size by 90% or more with no visible difference at the size it is actually shown. In the audit above, a 1.84 MB image became 95 KB and looked exactly the same.
How do I know whether my web developer has handled this properly?
Three fair questions: do our file names change when you update our styling or code; what is our mobile Largest Contentful Paint; and what is the biggest single file on our homepage. Clear answers to all three is a good sign. Hesitation on the first is worth following up.
The summary
Four problems on one site, none of them exotic:
- Existing customers were being shown a version of the site that was two months out of date, and would have been for up to a year.
- Every visitor waited in an invisible queue while nine files loaded one after another.
- Four megabytes of images that should have been a couple of hundred kilobytes.
- Fonts that held the whole page blank, putting a floor under every other improvement.
We find some combination of these on most sites we audit, including expensive ones that look superb. Good design and good engineering are different jobs, and a site can pass the first while quietly failing the second.
The measurable result here was the homepage dropping from 14.6 seconds to 5.8 on the single biggest fix, with the font change clearing what was holding it there. But the finding that mattered most was the caching one — because without it, every other improvement would have stayed invisible to the customers most likely to come back.
A fast website isn't a luxury. It is whether the people who already found you ever get to see the site you paid for.