Why is my website slow? The real causes and the fixes that matter

"Why is my website slow?" is one of those questions that sounds simple and almost never has a simple answer. Usually it arrives with a screenshot of a red PageSpeed score, or a nagging sense that the site felt snappier a year ago, or a suspicion that slowness is quietly costing sales. The good news is that "slow" is not a mystery. It is a handful of specific, measurable causes, and most of them are fixable once you know which one you actually have. The trap is guessing — throwing a caching plugin at a problem that lives on your server, or compressing images when the real culprit is a chat widget loading four other scripts behind it.

Before you change anything, it is worth being clear about what people mean by slow, because there are two different problems hiding under one word. There is how long the page takes to first respond — the server thinking before it sends anything back — and there is how long the page takes to become usable in the browser once it does. They have different causes and different fixes. Diagnose which one you're facing first and you save yourself weeks of chasing the wrong thing.

Start by measuring, not guessing

Run the page through a real diagnostic before you touch a line of code. Google's PageSpeed Insights is free and, crucially, shows you field data from actual visitors alongside its lab test — which matters, because a site can score well on a fast test machine and still be slow on a mid-range phone on 4G, which is what most of your customers are actually using. Tools like WebPageTest or GTmetrix give you a waterfall: a chart of every file the page loads, in order, so you can see exactly what is arriving late and what is holding everything else up.

What you're looking for is the biggest single delay, not a long list of minor ones. A page that scores poorly usually has one or two dominant problems dragging the number down. Fix those and the rest often stops mattering. Optimising a 30-kilobyte script while a two-megabyte hero image loads uncompressed is effort spent in the wrong place.

Your server is slow to respond (TTFB)

This is the one most people miss, because it happens before anything appears on screen. Time to First Byte is how long the browser waits after asking for the page before it receives the first scrap of HTML back. If that number is high — anything much above 400 milliseconds is worth investigating — then nothing you do in the browser can save you. The visitor is staring at a blank screen while your server is still thinking.

Slow TTFB usually traces to one of a few things: cheap shared hosting where your site is competing with hundreds of others for the same processor; a database doing too much work on every request; a content management system running heavy uncached queries; or a server physically far from your visitors. The fixes range from cheap to structural — better hosting, server-side caching so the page isn't rebuilt from scratch for every visitor, and a CDN so static files are served from a location near the user rather than a single origin server. A CDN alone can shave meaningful time off for visitors who aren't sitting next to your data centre. This is exactly the kind of foundational work that sits inside proper web development rather than being patched over afterwards.

Images and video are doing the damage

On a huge proportion of the sites we look at, the single heaviest thing on the page is an image — often the big one at the top, the very first thing a visitor is waiting to see. Uncompressed photos, images served far larger than they're displayed, and old formats like unoptimised PNG or JPEG are the most common cause of a slow-feeling page, and also the easiest to fix.

• Compress and resize properly. An image displayed at 800 pixels wide has no business being 3,000 pixels wide in the file. Serve it close to the size it's shown at.
• Use modern formats. WebP and AVIF typically cut file size by a third or more against a JPEG at the same visible quality. There is very little reason not to.
• Lazy-load anything below the fold. Images the visitor hasn't scrolled to yet shouldn't cost them a single millisecond up front.
• Prioritise the one that matters. Tell the browser to fetch the main hero image early, and let the rest wait their turn.

Video deserves its own warning, because an autoplaying, uncompressed hero video loading the instant the page opens is one of the most self-inflicted performance wounds there is. It is entirely possible to have atmosphere and speed at once — we've written about exactly how in our piece on speed, video and conversion — but only if the video is compressed, deferred, and sat behind a lightweight poster image rather than blocking everything on load.

Too much JavaScript, most of it not yours

The other big culprit is code, and here's the uncomfortable part: a lot of it is code you didn't write and don't need. Every analytics tag, chat widget, cookie banner, heatmap tool, review embed and social pixel is another file the browser must fetch and run, and each of those often quietly loads several more behind it. We regularly find sites where third-party scripts outweigh everything the business actually built. The browser can only do so much at once — while it's busy parsing and executing all that, the page sits there looking loaded but refusing to respond to a tap.

Render-blocking resources make it worse. If a stylesheet or script has to be fully downloaded and processed before the browser will draw anything, it sits directly in the critical path and delays the moment your content appears. The fixes are unglamorous but effective: defer non-essential scripts so they load after the content, audit your third-party tags and remove the ones nobody actually uses, and be honest about whether that fourth tracking pixel is earning its keep. This is also why we build content to be server-rendered in the first place — if the important part of the page is in the HTML rather than assembled by JavaScript in the browser, it appears fast and doesn't depend on a pile of scripts finishing first.

Most slow websites aren't slow because of one big mistake. They're slow because nobody ever said no — to another plugin, another pixel, another oversized image — and it added up.

The layout keeps jumping (and why it counts as slow)

There's a kind of slowness that isn't about load time at all — it's about the page feeling unstable. Content shoves down as an image finally loads. A button moves just as you go to tap it. A cookie banner elbows everything sideways. Even if the raw numbers are fine, a page that lurches around feels broken and slow, and Google measures it directly as one of its Core Web Vitals. The usual causes are images and embeds without reserved space, and fonts that swap in late and reflow the text. We've broken the whole thing down properly in our guide to Core Web Vitals, which is the right next read if you want to understand what Google is actually scoring and why it feeds into rankings as well as experience.

Getting the priorities right

If you take one thing from this, let it be the order. Measure first and find the biggest single delay. Check your server response before you touch anything in the browser, because a slow server caps everything downstream. Then handle the heaviest asset — usually an image or a video — because that's where the fastest wins live. Only then start trimming scripts and chasing the smaller gains. Working in that order means the first hour of effort buys you most of the improvement, rather than the last.

Some of this you can do yourself in an afternoon: compressing images, deleting a dead plugin, switching on caching. Some of it — a slow server, a bloated build, render-blocking code baked into a theme — is structural and doesn't respond to plugins, which is where it becomes a build problem rather than a settings problem. And keeping a site fast is not a one-off; performance drifts as content, apps and tracking accumulate, which is precisely what ongoing website care and maintenance is there to hold in check. If your site is slow and you'd rather know exactly why than keep guessing, send us the URL and we'll tell you honestly what's dragging it down and what's worth fixing first.