Why your website speed is costing you customers

Every discussion about website speed eventually produces the same statistic: some percentage of visitors abandon a page that takes longer than three seconds. The number varies depending on who is quoting it, which should tell you something about how precisely it has been measured.

The underlying point survives the imprecision. Speed matters twice over. Google uses Core Web Vitals as a ranking signal, so a slow site is harder to find. And a visitor who does find you is measurably less likely to stay. You lose at both ends of the same funnel.

What actually makes a site slow

In my experience rebuilding sites for clients, the causes cluster into four groups, roughly in order of how much damage they do.

Images that were never optimised

This is the most common and the easiest to fix. A photographer supplies a 6 MB JPEG, someone uploads it directly, and the browser downloads all six megabytes to display it at 400 pixels wide. Converting to WebP and serving appropriately sized variants routinely cuts total page weight by seventy per cent or more, with no visible difference in quality.

The plugin stack

Each plugin adds its own stylesheet and script, and those files load whether the page uses them or not. A contact form plugin loads on your privacy policy. A slider plugin loads on pages with no slider. Thirty plugins is not unusual, and thirty plugins is a lot of code executing before a visitor sees anything.

Render-blocking resources

Fonts and stylesheets loaded in the document head stop the browser from painting anything until they arrive. A single web font requested from a third-party server can add several hundred milliseconds of blank screen. Preloading and asynchronous loading solve this, and almost nobody configures it.

The platform itself

Some slowness is structural. A page builder that outputs six nested divs where one would do, a theme that ships with features you disabled but which still load, a hosting plan sharing a server with four hundred other sites. You can optimise around these to a point, and then you cannot.

How to find out where you stand

Run your homepage and one product or service page through PageSpeed Insights. Look at the mobile score rather than the desktop one, because mobile is what Google indexes and what most of your visitors use.

Two things matter more than the headline number. Largest Contentful Paint tells you how long until the main content appears; under 2.5 seconds is the target. Cumulative Layout Shift measures how much the page jumps around while loading; under 0.1 is the target, and anything above 0.25 is actively annoying to use.

What is worth fixing, and in what order

If you are working through this yourself, the order that produces the most improvement for the least effort is fairly consistent:

1. Compress and convert your images. Free tools handle this and it is often the single biggest win.
2. Audit your plugins and remove anything you are not actively using.
3. Set explicit width and height attributes on images so the layout stops jumping.
4. Move non-essential scripts to load after the page renders.
5. Check your hosting. If your server takes 800 milliseconds to respond, nothing else you do will make the site feel fast.

If you get through all five and the site is still slow, the problem is structural and the honest answer is that optimisation has run out of road.

The uncomfortable conclusion

A code-built site starts fast and stays fast because there is nothing in it that does not need to be there. That is not a clever technique, it is just an absence of accumulated weight.

Whether that justifies a rebuild depends entirely on what your site is worth to you. If it is a brochure nobody visits, live with the slowness. If it is where your revenue comes from, three seconds of load time is an expense you are paying every single day.