Why your website is slow (and what to actually do about it)

I hear this a lot. Someone tells me their site feels sluggish. Their host suggested upgrading to a more expensive plan. A developer mentioned a CDN. A friend recommended a caching plugin. But where should they actually invest their time and money.

Most slow websites aren’t slow because of where they’re hosted. They’re slow because of what’s on them. The host is usually the last thing to fix, not the first.

Why it matters

I’m sure it won’t surprise anyone reading this that a slow site is annoying for it’s users. And honestly, that’s the main reason you should care.

If someone searches for your church’s service times and the page takes ten seconds to load, they don’t wait. They go to the next result. If a potential client clicks your portfolio and the images are still loading after five seconds, they don’t wait to see if they were worth the wait. If your charity’s donation page takes too long, people give up halfway through.

Google also cares. Not in a way you need to obsess over. But the slower your site, the lower it ranks. That compounds the problem. Fewer people find you. The ones who do leave before they see anything.

It doesn’t take much. A two-second improvement is the difference between someone reading your page and someone hitting back.

This isn’t about chasing a perfect score in some performance dashboard. It’s about not getting in your users’ way.

How you build it sets the floor

A lot of modern themes ship with sliders, animation libraries, icon sets, font packs, and layout engines. You use a fraction of them, but your visitors may be downloading all of them on every visit.

Page builders like Elementor, Divi, and Beaver Builder make it even worse. The code needed to support the complex layouts is large and often different between pages. And the code they produce is normally overly verbose. A simple text-and-image section can end up in 50 lines of code when 10 would do when written by hand.

On its own, that’s not a disaster. But it’s the baseline. And if your foundation already has a head start on bloat, everything you add after makes it worse.

Images that aren’t optimised

Straight from a phone or camera, a single photo can be 4–6 MB. A page with ten of those is 40–60 MB before any text, scripts, or styling loads.

Most people don’t know this. They upload the photo they took. The website resizes it visually but still serves the full file. Your visitors are downloading a 5 MB image to display a 500 pixel box.

The fix is simple. Compress your images. Serve them at the right dimensions. Use WebP or AVIF as alternatives to JPEG.

This can often be done automatically for you. This one change fixes more slow sites than anything else I can think of.

I mention images, but the same can be true for video if you use that.

Too many things loading on every visit

Every extra script is a conversation between the browser and a server. Analytics. Custom fonts. Social media feed widgets. Chat widgets. Cookie consent banners. That plugin that promises live weather on the home page.

None of these are bad on their own. Ten of them, all blocking or delaying the page from rendering. That’s your slowdown.

Static sites reset the problem

If you’re starting fresh, or ready for a real change, this is the direction I’d point point most people in.

A static site generator like Hugo, 11ty, or Jekyll produces plain HTML files. No database. No PHP. No page builder processing. No plugin overhead. Every page is a file on disk. When someone visits, the server just sends the file. There’s nothing to process, nothing to cache, nothing to optimise away. It’s as fast as the server can serve a file.

You lose the drag-and-drop editor. That’s the trade-off. You gain a site that loads in a fraction of the time, has zero attack surface from outdated plugins, and costs less to host. This very site is built with Hugo. It loads quickly on a 3G connection in a rural area. That’s not because I’ve done anything clever. It’s because there’s almost nothing for the server to do, and very little the browser needs to download.

Not every site needs to be static. But most small organisation sites would be dramatically faster and simpler if they were. The kind that publish information pages, blog posts and event listings. That’s most of them.

The host comes last

Shared hosting gets a bad reputation. For good reason. Cheap hosts are overcrowded and slow.

But here’s the thing. For most small organisations, the difference between “cheap shared” and “premium managed” is a few hundred milliseconds if the site is already optimised. If your site has a bloated theme, unoptimised images, and twelve tracking scripts, a faster host won’t save you. You’re just moving the problem somewhere more expensive.

Fix what’s on the site first. Then see if you still need better hosting.

If you’ve opted for a static site, you can normally cut the cost and use much cheaper hosting.

What to actually do

1. Audit your foundation. If you’re using a heavy theme or page builder, ask honestly whether you use the features it ships. Most sites use a fraction of what’s installed. A lightweight theme removes that weight at the source.
2. Consider going static. If your site is mostly pages and posts, a static site generator removes almost every source of slowness at the architectural level. No database. No runtime. No plugins. Just files.
3. Optimise your images. Compress them. Serve them at the right size. Use modern formats.
4. Trim your scripts and plugins. Remove all the ones you don’t need.
5. Add caching. Browser caching or a lightweight caching layer stops the server from regenerating the same page on every visit.
6. Then, and only then, look at hosting. If it’s still slow after steps 1–5, you might need to move. Chances are you won’t.

Where Lumen IT fits in

I can help in two ways.

If you need a new site. I build static sites that are fast by default. No database, no page builder, no scripts you didn’t choose. Just pages that load instantly and stay that way.

If you already have a site. I can audit what’s slowing it down. I’ll open DevTools, look at everything loading, and tell you what to remove. Half the time it’s images and a handful of scripts you forgot were there.

It’s not a sales pitch. If your site is fixable with a few changes, I’ll tell you. If a static rebuild makes more sense, I’ll tell you that too. Either way, you get a clear answer.

The takeaway

Your website isn’t slow because you’re not spending enough. It’s slow because you’re carrying too much. Lighten the load before you upgrade the engine.

Speed isn’t something you buy. It’s something you clear space for.