Here’s a pattern I’ve seen repeatedly across client sites: someone installs a caching plugin, runs a PageSpeed Insights test, sees the score jump from 45 to 85, and considers the problem solved. Three months later, the site is slow again, and nobody’s quite sure why.
This isn’t a caching plugin problem. It’s a maintenance problem disguised as a one-time fix. Here’s what actually happens, and what holds up long-term instead.
Why the Score Regresses
New plugins get added without anyone checking their weight
A client asks for a new feature. A plugin gets installed to handle it. Nobody checks whether that plugin loads its own copy of jQuery, adds three new database queries per page load, or enqueues a 200kb CSS file on every page even though the feature only appears on one. Individually, each addition seems harmless. After a year of this, you’ve got a site carrying the weight of a dozen plugins nobody remembers the original justification for.
Image uploads bypass your original optimization setup
You configured image compression and WebP conversion when you built the site. Then the client’s marketing team starts uploading their own images directly through the media library, and depending on your setup, these may not pass through the same optimization pipeline — especially if the plugin was configured for a specific upload workflow that doesn’t match how content actually gets added later.
Database bloat accumulates silently
Every form submission, every WooCommerce order, every revision of every post adds rows to the database. Post revisions in particular pile up — WordPress keeps every revision by default, indefinitely, unless you’ve explicitly limited or cleaned them. A site with two years of active content editing can easily be carrying tens of thousands of unnecessary revision rows, each one adding overhead to every query that touches the posts table.
Caching gets misconfigured by well-meaning changes
Someone installs a new plugin and, following its instructions, adds an exclusion rule to the caching plugin so the new feature “works properly.” A year later, half the site is on some kind of caching exception list, effectively serving uncached pages for large sections without anyone noticing performance quietly degrading.
Hosting doesn’t scale with traffic growth
The hosting plan that handled the site fine at launch with modest traffic starts struggling once the site actually succeeds and traffic grows. Shared hosting in particular has hard resource ceilings — CPU throttling under load is common and rarely obvious from the outside. It just looks like “the site got slow” with no clear cause.
What Actually Holds Up
Set a plugin governance habit, not just a plugin choice
The fix isn’t “use fewer plugins” as a one-time cleanup — it’s establishing an ongoing habit of checking, before adding any new plugin, what it loads on the frontend and whether that load is scoped only to the pages that need it. Query Monitor is the tool I use for this: it shows exactly what a plugin adds to page load, database queries, and memory in real time, not just in theory.
Automate image handling at the point of upload, not after the fact
Rather than relying on a one-time bulk optimization pass, configure compression and WebP conversion to run automatically on every upload, regardless of who’s uploading or through what workflow. WP Rocket and similar tools can handle this at the upload hook level so there’s no “optimization pipeline” someone can accidentally bypass.
Schedule actual database maintenance, not just a plugin install
Limiting post revisions (define('WP_POST_REVISIONS', 5); in wp-config.php) prevents the problem from growing further, but doesn’t clean up what’s already accumulated. A scheduled cleanup — via WP-CLI (wp post delete $(wp post list --post_type='revision' --format=ids)) run periodically, or a maintenance plugin configured to run automatically — is what actually keeps the database lean over time rather than just once.
Treat caching configuration as something to audit, not just set
Every time a plugin asks you to add a caching exclusion rule, that’s worth logging somewhere and periodically reviewing — not just accepting and forgetting. I keep a simple running note per client site listing every cache exception and why it was added, so six months later there’s a record instead of a mystery.
Match hosting to actual traffic, and revisit the decision periodically
The hosting decision that made sense at launch is worth revisiting at meaningful traffic milestones, not left as a “set and forget” choice. For clients whose traffic has meaningfully grown, moving from shared hosting to a VPS with proper resource allocation (or a managed WordPress host with real headroom) tends to fix performance issues that no amount of plugin-level optimization can solve, because the underlying constraint is CPU and memory, not code efficiency.
The Actual Long-Term Approach
None of this is a single fix you apply once. It’s an ongoing practice:
- Quarterly plugin audit — review what’s installed, check what’s still actually needed, measure what each one costs via Query Monitor
- Automated image pipeline — configured once, but verified periodically to confirm it’s still applying to all upload paths
- Scheduled database cleanup — not manual, not one-time
- A living log of caching exceptions — reviewed, not just accumulated
- Hosting reviewed against current traffic — not fixed at the launch decision forever
The sites I maintain that have stayed consistently fast over multiple years are the ones where this is treated as ongoing maintenance, the same way you’d think about security updates — not a project with a defined end date.
If you ran a speed test today and got a great score, that’s a snapshot, not a guarantee. The question worth asking isn’t “is my site fast right now” — it’s “do I have a system in place that keeps it fast six months from now, after the next dozen small changes nobody thinks twice about.”
If your WordPress site has slowed down over time and you want an actual diagnosis rather than another cache plugin, get in touch.
