Why Your Website Feels Slow, and What Speeds It Up

• First, work out what "slow" even means
• Nine times out of ten, it's the images
• Your site rebuilds itself on every single visit
• Too many moving parts
• Old PHP is slow PHP
• Some slowness you can't cache away
• What you're paying a host for
• A five-minute sanity check

Someone messages you: "hey, your site takes forever to load on my phone." Or you run it through PageSpeed Insights out of curiosity and get a red 34 next to a screen full of warnings you've never heard of. Your website is slow, and you have no idea why.

Most of the time the site did this to itself. That's good news, because whatever got piled on can be taken back off, usually without touching your hosting at all. The only real skill is finding where the seconds are going before you start ripping things out. In rough order of how much they cost you, here's where they tend to hide.

First, work out what "slow" even means#

"Slow" is two different problems wearing the same coat.

The first is time to first byte: how long the server takes to start answering at all. The second is everything after that: the images, scripts and fonts a browser downloads and assembles into the page. A site can have a quick first byte and still feel sluggish because it's loading four megabytes of photos. The reverse happens too: a lean page stalls because the server takes two seconds to start responding.

So measure before you change anything. Run your homepage and one inner page through PageSpeed Insights or WebPageTest, and test from somewhere your visitors actually are. A site that scores beautifully from a test server next door can still crawl for someone on mobile data three countries away.

Once you can see the numbers, it's usually obvious which fix to start with.

Nine times out of ten, it's the images#

Oversized images are the single most common cause of a heavy page, by a wide margin. The usual story goes like this. Someone uploads a photo straight off a phone or a stock library, four thousand pixels wide and three or four megabytes, and drops it into a slot that's 600 pixels wide on screen. The browser downloads the whole enormous file and only then shrinks it to fit. Multiply that across a gallery and your "slow site" is really a slow download of pictures nobody needed at that size.

All four fixes here are chores:

• Resize images to the size they're displayed at. Around 1600 pixels wide is plenty for almost any layout.
• Compress them. Squoosh or TinyPNG will cut the file size by half or more with no visible difference.
• Serve modern formats. WebP and AVIF are far smaller than old JPEGs and PNGs, and every current browser reads them.
• Switch on lazy loading, so images below the fold only download once someone scrolls to them.

A surprising number of sites go from heavy to quick on these four alone, which is a lot of payoff for what amounts to housekeeping.

Your site rebuilds itself on every single visit#

Most dynamic sites, WordPress among them, assemble each page from scratch the moment it's requested: run the PHP, hit the database, build the HTML and send it off. Fine for one visitor, pure waste for the next thousand who get an identical page.

Caching removes the waste. A page cache saves the finished HTML the first time it's built and hands that copy to everyone afterwards, so the server skips the whole rebuild. It's often the single biggest jump available to you, bigger than anything you'll do to the code itself.

It's also one spot where the host matters. Our servers run LiteSpeed, and on WordPress the free LiteSpeed Cache plugin hooks straight into it, caching pages at the server level instead of inside PHP where it's slower. Set it up once and most visitors get a ready-made page in a few milliseconds.

Too many moving parts#

Open your site and watch what it loads. On a lot of sites it's a small crowd: a chat widget, two analytics scripts, a cookie banner, a font service, a slider, an embedded map. Every one of those is another request the page waits on before it finishes loading.

Some of that list can probably go. On WordPress the problem is worst, because each plugin brings its own scripts and styles along whether the current page uses them or not. Twenty plugins doing the job of five is one of the most common reasons a site feels bloated.

Go through the list once a year and turn off what you're not using.

Old PHP is slow PHP#

Every major PHP release has been meaningfully quicker than the last, and upgrading costs nothing, yet it's the fix people skip most often. A site still running PHP 7.4 can pick up real speed just by moving to 8.2 or 8.3, frequently with no other change at all. In cPanel you can switch versions yourself under Select PHP Version. Test on a staging copy first, then flip the live site over. The whole thing takes about five minutes.

Some slowness you can't cache away#

If your server sits in the Netherlands and your visitor is in Amsterdam, the round trip is a few milliseconds. If the server is in Texas and the visitor is in Warsaw, every request pays for the distance, and no cache erases that entirely.

Two things help. Host near the people you're serving: for a European audience, a server in the EU beats one across the Atlantic before you've tuned anything, and it's the tidier answer for data-protection reasons too. And if your audience really is spread across the globe, put a CDN in front of the site so static files come from a point near each visitor rather than from one origin for the whole planet.

If your current host is a long way from your readers, we wrote a step-by-step on migrating with near-zero downtime for exactly that situation.

What you're paying a host for#

Everything so far you can do yourself. What's left is the part that has to come from the host.

On cheap shared hosting, hundreds of accounts share one machine, and if the provider oversells it, one busy neighbour can drag everyone else down with them. There's nothing you can optimise your way out of, because the resources aren't there when you reach for them. That's the hidden tax on bargain hosting.

On our platform every account runs under CloudLinux, which gives each site a guaranteed share of CPU, memory and disk speed, so other accounts on the machine can't consume your allocation. The storage underneath is enterprise SSD, not the tired, oversold disks a lot of budget hosts still run.

A five-minute sanity check#

If you do nothing else: measure from where your visitors are, then fix the images, then turn on caching. Those three get most sites most of the way. After that, prune the plugins you don't use and move PHP up to a current version. If the site is still slow once all of that is done, the problem is probably the host, either too far from your readers or too crowded, and that's the point where moving becomes worth the hassle.

Most of these fixes are ordinary, and most of them are already in your hands. The guaranteed resources and a server close to your readers are the part a decent host brings.

Stuck on where your own time is going? Send us the URL and we'll tell you what we'd fix first. You don't have to be a customer to ask.