Still Slow? Hidden Reasons Optimisation Isn’t Working
You've installed a caching plugin, compressed your images, maybe even run a CDN. The Google PageSpeed score ticked up a little. Yet visitors are still waiting, and bounce rates haven't budged. This is one of the more frustrating problems in web development because the obvious fixes are already done. What's left tends to be quieter, harder to spot, and almost never mentioned in the standard optimisation guides. Here's where to look next.
On this page
Your Hosting Is the Ceiling Everything Else Hits
No amount of caching compensates for a server that’s genuinely slow to respond. Time to First Byte (TTFB) is the metric to watch here. If the server takes longer than roughly 200ms to start sending a response, every other optimisation you’ve done is fighting upstream.
Shared hosting is the usual suspect. When your site shares physical resources with hundreds of others, your response time isn’t entirely in your control. A plugin or CDN can mask some of that latency, but it can’t eliminate it. If TTFB is your problem, the real fix is a better hosting environment, not another layer of optimisation stacked on top of the existing one.
Render-Blocking Resources You Haven’t Touched Yet
Caching plugins handle a lot, but they rarely deal with render-blocking JavaScript and CSS automatically, or they do it badly. These are the files the browser has to download and process before it can paint anything on screen.
The tell-tale sign is a high Largest Contentful Paint (LCP) score alongside a fast TTFB. The server is responding quickly, but something is holding the browser up. Check which scripts load in the <head> and whether they’re deferred or loaded asynchronously. Third-party scripts are often the real culprit, especially chat widgets, fonts pulled from an external server, or tag manager containers stuffed with extras. Each one adds a round trip the browser has to complete before anything meaningful appears.
Too Many Plugins Doing Overlapping Jobs
WordPress sites accumulate plugins over time. An SEO plugin, a schema plugin, a redirection plugin, a forms plugin, a social sharing plugin. Each one is usually harmless alone.
Together, they can generate a surprising number of database queries, extra HTTP requests, and script loads on every single page view. The problem isn’t any individual plugin. It’s the combined weight of plugins that each add a little, and nobody has ever audited the total. Deactivate anything that isn’t actively earning its place. If two plugins do roughly the same thing, pick one. A leaner setup nearly always performs better than a feature-heavy one with everything switched on.
We’d argue that most WordPress sites carry at least three or four plugins they no longer need. That dead weight has a real cost, even if no single plugin looks heavy in isolation.
Images That Look Compressed but Aren’t Properly Served
You compressed the JPEGs. Good. But are they being served in a next-generation format like WebP? And are they sized correctly for the device requesting them, or is a mobile visitor downloading a 1,400-pixel-wide image to display it at 400 pixels?
Responsive images, the srcset attribute, and WebP conversion are separate steps from basic compression. Many sites do one but not the others. Getting the technical fundamentals right means covering all three, not just the most visible one. A site that scores well on desktop PageSpeed but serves oversized images to mobile users is only half-optimised, and mobile is where most of your traffic is coming from.
The Database Is Working Too Hard
WordPress stores everything in a database, posts, settings, transients, revisions, session data. Over time, that database accumulates a lot of junk. Thousands of post revisions for pages nobody edits anymore. Expired transients that never got cleaned. Autoloaded options that grow with every plugin install and removal.
A bloated database slows down query times. Not dramatically on any single query, but the effect compounds across every page load. Running a regular database optimisation, removing post revisions beyond a sensible limit, and auditing autoloaded data are the kinds of tasks that don’t show up in a PageSpeed report but absolutely affect how snappy a site feels under real traffic conditions.
What the Score Doesn’t Tell You
A PageSpeed Insights score is a lab measurement taken under ideal conditions with a single simulated request. Real users don’t behave that way. They arrive on different devices, from different locations, with warm or cold caches, alongside other users hitting the same server.
Field data from Google’s Chrome User Experience Report often tells a very different story from the lab score. If your Core Web Vitals are green in the lab but amber or red in field data, the gap usually points to real-world server load, JavaScript execution on low-powered devices, or content that loads differently under actual conditions. That’s the number worth fixing, because it’s what Google uses for ranking.
Chasing a high lab score while the field data stays poor is a common trap. A site that feels slow to real visitors costs you conversions regardless of what the tool says. The work that actually moves the needle happens well below the surface, and it takes patience to get right.