Why a Slow Website Quietly Loses You Sales

A broken site generates phone calls. A slow site generates nothing at all, which is why it can carry on costing you for years without anybody raising it. The person waiting on your product page has no relationship with you and no reason to be patient. They go back to the search results and open the next one.

It gets worse the further you are from the visitor. Your site feels fine in your office, on a good connection, on a new laptop, with everything already cached from the last time you looked. Your customer is on a phone, on a train, on a network that is busy, holding a handset that is a few years old. That is where the real experience happens, and it is not the one anybody in the company sees.

There is an internal cost too. If your staff use an admin screen all day, every slow page load is paid for out of their working hours, over and over, every week, quietly.

Where it hurts most is the end of the journey. A slow homepage is a bad first impression. A slow checkout, a slow booking form or a slow search on a shop is money that was already halfway into your hand.

There are two kinds of measurement and you need both. A tool that loads your page on a controlled connection and reports what it found, and the record of what your real visitors actually experienced on their own devices. They frequently disagree, and when they do the second one is right.

Field data from real visitors tells you whether you have a problem. Lab tools tell you what to do about it, because they can show you exactly which file arrived when. Start with the first, then use the second on whichever page the first one is unhappy about.

The trap is chasing a score. A score is a summary of many things, some of which barely affect anybody. The question worth answering is simpler: how long after tapping the link can somebody see the page, and how long until they can use it without things jumping around under their finger.

Measure the pages that matter rather than the homepage alone. The homepage is usually the most optimised page on the site because it is the one everybody looks at. Test a product page, a blog article, the search results and the checkout. That is where the visitors are.

On most business sites this is the whole answer. Somebody uploads a photograph straight from a camera or a phone, the site displays it small, and the browser downloads every last bit of the original before shrinking it on screen. Multiply that by a page full of products.

The fixes are well understood and none of them require rebuilding anything. Resize images to roughly the size they are actually displayed at. Serve modern formats to browsers that support them. Serve a smaller file to phones than to desktops. Compress properly, because the difference between a carefully compressed photograph and a raw one is enormous and, at normal viewing sizes, invisible.

Two details matter more than people expect. Always set the width and height, so the browser reserves the space and the page does not shuffle around while it loads. And load images below the fold lazily, but never the main image at the top, because delaying that one delays the exact thing the visitor came to look at.

The habit is the real fix. If anybody in your company can upload an image through the editor, the site needs to resize on upload automatically. Otherwise you fix this once, and it comes back the following month when marketing adds a new banner.

This is the second cause, and on marketing sites it is often the first. Analytics, a tag manager, a chat widget, a heat map recorder, ad pixels, a testing tool, a cookie banner, a font loader, a reviews widget, a booking widget. Each one arrived for a reason. Nobody has ever removed one.

The problem is not their size, it is their behaviour. Many of them block the page while they load. Most of them fetch further scripts from other servers, which fetch more, and every one of those servers is a company whose bad afternoon becomes your bad afternoon. Your site is only as fast as the slowest third party you invited onto it.

The version we see most often looks like this. A chat widget loading on every page, including the checkout, where nobody has ever used it. Two analytics tools measuring the same thing because somebody added a new one and never switched the old one off. And a tag manager holding a tag for an advertising campaign that ended two years ago.

List every third party script on your site, and write an owner and a reason next to each one. Delete anything with neither. Whatever survives should load after the page is usable rather than in front of it, and the marketing team should have to ask before adding another.

Distance is real physics and no amount of code fixes it. If your customers are in India and the server is on another continent, every single request pays for the round trip, and a page that needs several of them pays several times.

A content delivery network solves this for files that do not change: images, stylesheets, scripts, fonts. It keeps copies close to your visitors. What it does not solve on its own is a page that has to be generated fresh by your server for every visitor, because that generation still happens in one place.

Cheap shared hosting is worth understanding rather than automatically condemning. You are on a machine with many other sites, and when one of them has a busy afternoon, you have a slow one. It is fine for a brochure site and a poor choice for anything that takes money.

The change with the biggest effect for the least work, on most sites, is caching. If a page looks the same for everybody who is not logged in, it should be generated once and served from a file after that. Sites that do this well go from noticeably slow to instantly fast without a single line of the application changing.

On sites built on a content system or a shop platform, the usual server side cause is a page that fires a surprising number of database queries because some plugin asks a question on every load and nobody has ever looked.

The classic version is a query that was instant when the table held a few hundred rows and is slow now that it holds a few hundred thousand, because nobody added an index. This is the sneakiest performance problem there is, because the site got slower gradually as the business grew. There was never a day when it broke, so there was never a day when anybody investigated.

A concrete one from shops: a category page that counts stock for every product in the category, on every load, for every visitor, including the visitors who are just browsing. Or a sidebar that lists popular posts by looking at every post ever written each time the page is drawn.

The work here is genuinely developer work. Turn on slow query logging, look at what runs on your worst page, add the missing indexes, and cache the expensive results rather than recalculating them for every visitor. This is the part of the job that repays a specialist, and it is usually a day or two rather than a project.

Chasing a perfect score in a testing tool. Past a certain point the remaining suggestions are academic, the fixes carry real risk of breaking something, and no visitor will ever notice the difference. Get the big things right and stop.

Micro optimisations in code while an enormous photograph sits at the top of the same page. It happens constantly, because tuning code is more interesting than resizing pictures.

Rewriting the site in a framework because that framework is described as fast. A fast framework rendering the same bloated page with the same seven tracking scripts produces the same slow page, and now you have also lost a year.

And do not remove things that earn money in order to save a fraction of a second. The chat widget may genuinely bring in enquiries. Measure what it costs you in speed, measure what it brings, and make an actual decision rather than a technical one.

Sites do not get slow in one step. They get slow the way a cupboard gets full: a script here, a bigger hero image there, another plugin because somebody needed a form. Nobody notices any single addition, and after a year the site is far heavier than it was.

Put a check into the release process so that a change which makes a key page substantially heavier is visible before it goes live rather than a quarter later. It does not need to be sophisticated. It needs to exist.

Look at the field data once a month, and look at it for the pages that make money rather than the homepage. Then give one person the authority to say no to a new tracking script. That last one is a political fix rather than a technical one, and it is the one that actually holds.

Agree what good looks like for your important pages and hold new work to it. A written target that somebody owns beats an occasional panic every time somebody notices the site feels sluggish.