Almost every website launches fast. Then a year or two passes, and customers start mentioning it feels sluggish. Nothing obvious changed — so what happened? Websites are a bit like a garage: they accumulate. Here are the usual culprits behind a site that's quietly slowed to a crawl.
1. Images that were never optimized
The most common cause, by far. Someone uploads a photo straight off their phone — a 6 MB, 4000-pixel-wide image — to fill a space that's 600 pixels wide. The browser still has to download the whole thing. A handful of these on a page can take a fast site and make it feel broken on a phone.
2. Plugin creep
Every time the site needs to do something new, it's tempting to install a plugin. Each one adds code that loads on every page, even pages that don't use it. Ten or fifteen plugins later, the site is hauling around a lot of weight to do a little work. (This is a big reason I build on a lean theme framework instead.)
3. Outdated software
WordPress, themes, and plugins all get performance improvements over time. A site that hasn't been updated in two years is missing two years of speed and security fixes — and is more likely to hit conflicts that cause slow, clunky behavior.
4. No caching or CDN
Without caching, your server rebuilds every page from scratch for every visitor. Without a content delivery network (CDN), a visitor in New York is pulling your site all the way from wherever your server physically sits. Both are fixable, and both make a dramatic difference.
Speed perception and speed ranking are not the same thing
I've spent time working close to the way Google measures page performance — including projects where the measurement methodology itself was what we were building. One thing that surprised a lot of clients when they first encountered it: a site that feels fast to a real visitor can score poorly on technical benchmarks, and a site that ranks well on paper can feel slightly sluggish in practice.
The reason is usually third-party code. Analytics tags, chat widgets, booking integrations, review badges, social embeds — each one phones home to an outside server, and the browser has to wait. That doesn't always show up as a blank screen (which users notice) but it does show up in metrics like Time to Interactive or Total Blocking Time (which Google notices). The site feels loaded, but technically it isn't, and it gets dinged accordingly.
The goalposts keep moving
Performance requirements aren't static. As average device computing power increases, user expectations tighten — what felt snappy on a 2018 phone feels normal on a 2024 phone, so the bar keeps rising. Google's Core Web Vitals thresholds have tightened over time too, and they'll keep tightening. A site that passed with flying colors two years ago may be in the "needs improvement" band today having changed nothing.
That's not a reason to give up on performance. It's a reason to think carefully about what you're actually optimizing for. Chasing a perfect Lighthouse score can lead you to strip out legitimately useful features — a booking widget, a live chat, an embedded calendar — because they carry a technical cost. Sometimes that trade-off is worth it. Often it isn't.
What actually keeps a site fast
- Resizing and compressing images before they go up
- Keeping the plugin count low and the software current
- Caching pages and serving them through a CDN
- Building on a lightweight foundation in the first place
- Being selective about which third-party tools actually earn their weight
Site feel is the real target
My philosophy, after years of working on this problem at multiple levels: Core Web Vitals and tools like Lighthouse are genuinely useful diagnostics. They surface real problems and give you a common language to talk about performance. But they don't always paint a complete picture of whether someone using your site is having a good experience, and a perfect score isn't always an achievable or sensible target given real business needs.
What I care about is whether the site feels fast and reliable to the person using it — that pages snap into view, that nothing jangles or jumps around while it loads, that it works on a mid-range phone with a middling connection. The benchmarks are a tool toward that goal, not the goal itself. Routine upkeep — images, updates, caching, a clean codebase — gets you most of the way there, and keeps you there as the goalposts move.
Is your site slower than it used to be?
I can take a look and keep it quick — image optimization, caching, and performance are part of every plan.
See the Plans