Why your website is slow, and which bit is to blame

“The website’s slow” is a symptom. Four or five different causes produce it, each needs a different fix, and the one people guess at first is rarely the one they have.

You can work out which you have got in about five minutes.

The number that tells you most

Run your home page through PageSpeed Insights and ignore the score. The score blends a dozen measurements together and hides more than it shows.

What you want is time to first byte, or TTFB. It measures how long your server took to start answering, before a single image or stylesheet came into it. Pure hosting, pure server work.

• Under 0.2 seconds: your hosting is fine. Whatever is slow, the server is not it. Skip to the next section.
• 0.2 to 0.5 seconds: acceptable. Not brilliant.
• Over 0.8 seconds: stop reading about image formats. Your problem is the server, and no amount of optimising pictures will fix it.

We took over a site last year that averaged 4.15 seconds to load, with a worst case of 13.67. Nothing was wrong with the pictures. It sat on shared hosting with a few hundred other sites, and at the busy part of the day it had to queue. Same site, same content, moved onto its own server: 0.52 seconds on average, 1.31 at worst.

That is the shape of the problem for most small business sites. Shared hosting sells on price, and the thing being shared is speed.

When TTFB is fine and the page still drags

Now look at what the page loads. In your browser, press F12, open the Network tab, and reload. Sort by size.

Three things are worth hunting for.

One enormous image. Somebody uploaded a photo straight off a phone at 4,000 pixels wide and 6MB, and WordPress serves it into a slot 600 pixels wide. The visitor downloads all 6MB. Everything else on the page waits behind it. Resize before uploading, and serve modern formats: WebP and AVIF run 30 to 50 per cent smaller than the same picture as a JPEG, with nothing visible lost.

A pile of small requests to other people’s domains. Fonts from one company, a chat widget from another, analytics from a third, a booking tool from a fourth. Each one opens a fresh connection to a server you do not control, and your page cannot finish until they answer. Nobody counts this tax when they add the widget.

Enormous CSS and JavaScript files. A WordPress site running a page-builder theme ships several hundred kilobytes of CSS to render a page that uses five per cent of it, plus jQuery, plus whatever each active plugin decided to load on every page whether that page needs it or not.

The plugin question

The honest test: take a staging copy of the site, not the live one, deactivate every plugin, measure, then switch them back on one at a time, measuring as you go. Tedious, and it gives you a definite answer.

You will usually find two or three plugins account for nearly all of it. The repeat offenders are sliders, page builders, “related posts” plugins that fire a database query on every page load, and anything that phones home to a licence server while your visitor waits.

While you are in there: delete the deactivated plugins rather than leaving them. They take up space and, as the OWASP piece covers, an attacker can still exploit them.

What slow costs you

Two things, and only one of them is the thing people worry about.

The one people worry about is Google. Core Web Vitals feed into ranking. The signal is real and modest. A fast page with poor content will not outrank a slow page that answers the question.

The one that costs money is visitors leaving. Google’s own field data shows the probability of a bounce climbing sharply as load time goes from one second to three, and climbing again from three to five. For a business page, that is somebody who searched for exactly what you sell, found you, and went back to the results because nothing happened fast enough. You will never see them in your analytics as a lost sale. They are absent.

The order to fix things in

1. Sort the hosting if TTFB runs over 0.8s. Nothing else you do matters until this is right, and it buys the most seconds per pound.
2. Sort the images. Resize, compress, serve WebP or AVIF, and lazy-load anything below the fold.
3. Remove what you no longer use. Plugins, third-party scripts, tracking tools left over from campaigns that ended two years ago.
4. Then worry about minification, critical CSS and the rest of it.

Most people work that list backwards, spend a weekend on step four, and shave 40 milliseconds off a four-second page.

To have us run these checks on your site and tell you which of the four you are dealing with, ask for a free website review. It takes us about twenty minutes and you get the numbers rather than a score out of a hundred.