What Actually Makes a Website Slow (And Why It Probably Isn’t Your Hosting)

When a business owner tells us their website is slow, the next sentence is almost always about hosting. They are about to move host, or they have just moved host, or somebody has told them to move host. Occasionally that is the right answer. Far more often it is an expensive way to change nothing.

Hosting gets the blame because it is the one part of a website that arrives as a monthly bill with a company name on it. It is visible, it is switchable, and switching feels like doing something. The actual causes of a slow site are mostly invisible, sit inside the site itself, and nobody sends you an invoice for them.

Here is what is usually going on, roughly in the order it matters.

First, what “slow” actually means

Speed is not one number. The measurements that matter describe three different experiences, and a site can fail one while passing the others.

How long until the main thing appears. Largest Contentful Paint — usually your hero image or headline. This is what people mean by “it takes ages to load”.

How long until it responds when tapped. Interaction to Next Paint. A page can look finished and still ignore you for half a second because scripts are still working. This is the one that makes a site feel cheap.

Whether it moves while you are reading. Cumulative Layout Shift — the button that jumps as a late image loads, so you tap the wrong thing. Not slowness exactly, but it registers as the site being badly made.

The causes, in the order they usually matter

1. Images, almost every time

This is the first thing to check and the most common single answer. A photographer sends 4000-pixel-wide images, someone uploads them straight into the page, and the browser downloads several megabytes to display something 800 pixels wide on a phone. The site is not slow because of the server. It is slow because it is posting a poster through a letterbox.

The fixes are dull and effective: resize images to the largest size they are actually displayed at, save them in a modern format, compress them properly, and let anything below the fold load only when it is scrolled to. On a lot of small business sites this alone is the difference between a bad score and a good one.

2. Third-party scripts you forgot you added

The chat widget. The cookie banner. Analytics, then a second analytics because someone wanted a different dashboard. A tracking pixel for an ad campaign that ended in 2024. An embedded map. A reviews widget. A booking embed.

Each one is a request to somebody else’s server, and your page is only as fast as the slowest of them. You control none of them. This is the category that most often makes a site that used to be fast gradually stop being fast, because nobody ever removes anything — things are only ever added. Keeping on top of that is exactly what ongoing care is for.

3. Render-blocking CSS and JavaScript

Some files stop the page drawing anything at all until they have downloaded and been processed. If a large stylesheet or script sits at the top of the page, the visitor gets a blank white screen while it works, no matter how quick your server was to answer.

The work here is to load only what the page needs to display first, and defer the rest until after something is on screen. It is unglamorous and it makes a very visible difference.

4. Fonts

Custom fonts are worth having and are a common cause of two specific problems: text that is invisible for a moment while the font downloads, and text that reflows once it arrives, shoving the layout around. Both are fixable with how the font is loaded rather than by giving up the font.

5. JavaScript nobody is using

Page builders and plugins tend to load their whole toolkit on every page in case you need it. A slider library on a page with no slider. A form library on a page with no form. Individually small, collectively a real weight, and entirely invisible to the person browsing their own site.

6. Plugins doing overlapping jobs

Not the number of plugins — that is a myth, and a well-built plugin costs almost nothing. The problem is duplication: two caching plugins fighting each other, three security plugins scanning the same files, an SEO plugin plus a second SEO plugin nobody switched off. This is common on sites that have passed through several hands.

7. And then, finally, the server

Server response time — how long the host takes to send the first byte — is a real thing and it does matter. It is simply rarely the largest number in the list. On most small business sites we look at, the server responds in a few hundred milliseconds and then the page spends several seconds doing everything above.

When hosting genuinely is the problem

Being fair to the thing everyone blames, there are cases where moving is the right call.

• Server response is consistently slow. If the first byte takes well over a second on a page with nothing complicated on it, and it does that repeatedly, that is the host.
• The site is fast at 8am and slow at 8pm. Time-of-day variation on cheap shared hosting usually means you are sharing a machine with somebody having a busier day than you.
• There is no caching at all. If every page is rebuilt from the database for every visitor, you are paying for the same work thousands of times.
• Your host is on the wrong continent. Occasionally a UK business is hosted a very long way from its customers for no reason anyone can remember.

The honest test is simple: measure server response separately from everything else. If the server is quick and the page is slow, moving host will change your bill and not your speed.

Why it is worth fixing beyond the obvious

The reason to care is not a score. It is that most local service searches happen on a phone, often on a patchy connection, by someone with a problem right now who has three tabs open. You are not competing with a stopwatch, you are competing with the other two tabs.

Speed is also one of the few site improvements that helps everything at once: people wait rather than leave, search engines see a page that responds properly, and the enquiry form gets reached more often. It rarely needs a redesign — the site you have is usually the site you keep.

What to do, in order

• Measure before you change anything. Otherwise you are guessing, and you will have no way of knowing whether what you did worked.
• Measure on mobile. Desktop numbers flatter almost every site and describe an experience most of your visitors are not having.
• Start with images. Highest impact, lowest risk, no design decisions required.
• Then audit what you are loading from other people. Remove anything you cannot name a reason for. Old tracking pixels are free to delete.
• Then deal with render-blocking files and fonts. This is where you probably want somebody technical.
• Only then consider the host — and only if the server response time actually justifies it.
• Re-measure. The number is most useful as a before and after, not a verdict.

Finding out what is true for your site

You can do a lot of this yourself. Our free website audit tool calls Google’s own performance API for both mobile and desktop, records Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift and total page weight, and then — the part that matters here — separates out the causes: render-blocking resources, unused JavaScript, image optimisation, text compression, caching policy, third-party script impact and font loading. Anything you are already doing well is filtered out, so you get a list of what to fix rather than a list of everything that exists.

It takes a few minutes, there is nothing to install, and the report tells you which of the things above is actually your problem — which is the only way to avoid spending money on the wrong one.

Common questions

Will moving to a faster host fix my site? Only if the server is genuinely the bottleneck, which you can measure. If the server responds quickly and the page still takes six seconds, a new host inherits the same six seconds.

Do I need a rebuild? Usually not. Most speed problems are things loaded by the site rather than the way it was built. A rebuild is the answer when the site also cannot be updated, does not work properly on a phone, or is built on something nobody can maintain — and if you are weighing up who should do it, we wrote about how to choose a web designer separately.

Is a caching plugin enough on its own? It helps, sometimes a lot, and it does nothing about oversized images, third-party scripts or render-blocking files. It is a good early step, not a complete answer.

How fast does my site actually need to be? Fast enough that nobody notices it. Chasing a perfect score has diminishing returns; going from very slow to comfortably quick is where all the value is.

My site scores well on desktop and badly on mobile. Which matters? Mobile, in almost every case, because that is where the enquiries come from.

The short version

Blaming the host is understandable, because it is the only part of the arrangement that looks like a bill. But on most small business websites the server is doing its job and the page is the problem — images that are far too large, other people’s scripts, and files that block the page from drawing.

Measure it on a phone, fix it in that order, and re-measure. You will usually find you did not need to move anywhere.