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 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 closely with Google team members involved in the way Google measures page performance, such as on the AMP project which coincided with the push for speed in the mobile space that is standard today. At the time standards were being introduced and needed enforcement, but a pattern I see more and more as technology and processing power impoves faster than the algorithm is that a site that feels fast to a real visitor can score poorly on technical benchmarks, and a site that scores well on paper can feel sluggish in practice. Even Core Web Vitals, the ranking standard, are not immune.
One typical cause is 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. If implemented thoughtfully, that shouldn't show up as a blank screen (which users notice) but it still shows 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, a branded font) because they carry a technical cost. Sometimes that trade-off is worth it. Often it isn't.
What 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 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