Why your website is slow — and what to do about it

Slow sites lose people, but not dramatically. Visitors do not sit there counting seconds and then leave in a huff. They quietly do something else, and you never find out they were there at all — which makes this the most expensive kind of problem, because nothing in your inbox tells you it is happening.

The good news is that website slowness is rarely mysterious. It is almost always one of five things, and they are listed here in roughly the order they turn out to be the culprit.

1. Images, nearly every time

Start here. On most sites you will not need to go any further.

A photograph straight off a phone or a stock library can be several megabytes and four thousand pixels wide, displayed in a slot eight hundred pixels across. The browser downloads every one of those pixels and throws most of them away. Do that six times on a homepage and you have a page that takes ten seconds on a train.

Four fixes, in order of how much they give you:

• Resize before uploading. Nothing on a normal page needs to be wider than about 2000 pixels. This one step often halves a page.
• Use a modern format. WebP and AVIF are dramatically smaller than JPEG at the same visible quality, and every browser in current use supports WebP.
• Serve the right size per device. A phone should not download the desktop image. WordPress does this automatically if the theme asks it to — and a surprising number of themes do not.
• Lazy-load everything below the fold, but not the main image at the top. Lazy-loading the hero is a common own goal: it delays the one image the visitor is waiting for.

While you are there, give every image an explicit width and height. It costs nothing and it stops the page jumping around as pictures arrive — which matters for a reason we will come back to.

2. Cheap hosting

On budget shared hosting your site sits alongside hundreds of others on one machine, competing for the same processor. When one of them has a busy morning, yours gets slower, and there is nothing you can do about it from your end.

The number to look at is time to first byte — how long the server takes to start responding at all, before a single image or stylesheet is involved. If that alone is over half a second on a page that should be cached, the host is your bottleneck and no amount of front-end optimisation will reach it.

Moving host is less disruptive than people fear and is frequently the single biggest improvement available.

3. Too many plugins, or the wrong ones

Plugin count is a rough proxy, not a rule — twenty small ones can be lighter than three heavy ones. The real problem is plugins that load their code on every page, including the pages that do not use them. A contact form plugin has no business loading anything on your blog posts, and yet.

Page builders are the extreme case. They buy you drag-and-drop editing and charge for it in page weight on every single view, for ever. Sometimes that trade is worth it. Often it is not, which is the argument we made in why we build custom WordPress themes instead of using a page builder.

An audit worth doing once a quarter: list what is installed, and for each one ask whether anybody would notice if it were gone.

4. Fonts

Web fonts are small but badly behaved. Loaded carelessly, the browser waits for the font file before painting any text at all, so your visitor stares at a blank page that has technically already arrived.

Three rules. Host the font files yourself rather than calling a third party, so the browser opens one fewer connection. Load only the weights you actually use — a family with nine weights will happily ship you all nine. And set font-display: swap, so text appears immediately in a fallback and switches when the real font lands.

5. Code that blocks the page from rendering

A stylesheet or script in the wrong place stops the browser drawing anything until it has been fetched and processed. Analytics, chat widgets, cookie banners, heatmap tools and tracking pixels are the usual offenders, and they arrive one at a time, each one apparently harmless.

Every third-party script is a request to a server you do not control, running code you did not write, on a page whose speed you are judged on. Your page is only as fast as the slowest of them. Audit what is actually loading — on most sites that have been running a few years, at least one tag belongs to a tool nobody uses any more.

What “fast enough” actually means

Google publishes thresholds for this under the name Core Web Vitals. The names are awful; the ideas are simple, and they are a reasonable target for any site whether or not you care about search.

Metric	In plain words	Good	Poor
LCP Largest Contentful Paint	How long until the main thing appears	Under 2.5s	Over 4s
INP Interaction to Next Paint	How quickly it reacts when you tap	Under 200ms	Over 500ms
CLS Cumulative Layout Shift	How much things jump about while loading	Under 0.1	Over 0.25

You are judged on the 75th percentile of real visits, so three quarters of your visitors need a good experience — not your laptop on office wi-fi.

LCP: how long until something useful shows up

This measures when the biggest visible element finishes rendering, usually the hero image or the main headline. When it is bad the cause is nearly always one of the first two items on this page: an enormous hero image, or a slow server. Occasionally it is a stylesheet blocking the paint, or text waiting on a font.

INP: does it respond when you touch it

This is the gap between tapping something and the page acknowledging it. Bad INP feels like a site that is ignoring you, which is the most irritating thing a website can do.

The cause is almost always JavaScript doing too much at once — the browser is busy running code and cannot repaint. Third-party tags are frequent culprits, because they execute on your page but were written by somebody with no stake in its performance.

CLS: does the page sit still

You go to tap a link, something loads above it, everything shifts down, and you tap the wrong thing. That is layout shift, and it is the easiest of the three to fix because the causes are few and specific: images without width and height, ads and embeds in unreserved space, fonts swapping at a different size, and banners inserted at the top after load. Cookie notices are the classic offender.

How to find out which one you have

Tool	What it tells you	Cost
Google Search Console	Real-world data from your actual visitors. The one that counts.	Free
PageSpeed Insights	Field data for one page, plus a lab test with specific recommendations	Free
WebPageTest	A waterfall of every request, so you can see what is blocking what	Free tier
Browser DevTools, Network tab	The same, on your own machine, right now	Free

Start with real-world data rather than a lab score. A perfect 100 in a simulated test on a URL nobody visits tells you very little; field data from real users is the truth.

How much does this matter for rankings?

Honestly: less than the people selling performance audits imply. It is one signal among many, and relevance beats speed every time — a slow page that answers the question will outrank a fast page that does not. There is more on what actually moves rankings in SEO basics for small businesses.

But it is a tiebreaker between comparable pages, and more to the point it is not really about Google at all. People leave slow sites. That was true before these metrics existed and it will be true after they are renamed again.

Most sites get most of the way there by fixing images and moving off oversubscribed hosting — two afternoons of work, no rebuild required. If yours has had both and is still slow, the problem is in how it was built, and that is a different conversation.