Too many WordPress plugins

#The site we inherited

Plugin sprawl rarely announces itself. No single plugin is the villain. The site works, slowly, until someone measures it and finds that the cost is cumulative: every plugin adds queries, scripts, styles, an update obligation, and a slice of attack surface, and thirty of them together turn a simple content site into something that takes nearly eight seconds to paint.

#The worst offender was a view counter

The single largest problem was not a heavy page builder or an image. It was a view counter. The site counted article views by incrementing a value in wp_postmeta on every page load, synchronously, inside the request. wp_postmeta is a general key-value table that WordPress reads constantly; it is not built for a high-frequency write on every visit. Left running, that one mechanism had grown wp_postmeta to 322 MB of the 705 MB database.

The damage is not just disk. A bloated, hot wp_postmeta slows down a large share of normal WordPress queries, because so much of the system reads from it. So a feature nobody thought about, a view count, was quietly taxing every page. Removing the synchronous write and counting views properly returned that table to a sane size and took load off every request.

#Sprawl is also a security story

The plugin count did not only cost speed. It widened the attack surface in the predictable ways:

• An open xmlrpc.php endpoint, a classic vector for brute-force and amplification.
• PHP errors displayed on production, leaking server paths (information disclosure).
• Plugins carrying known vulnerabilities, because abandoned or un-updated plugins stop getting patched.

This is why cutting the plugin count is a security measure, not only a performance one. Every plugin you remove is code you no longer have to trust, watch, and update. It is the same logic behind a proper WordPress security audit: less surface, fewer ways in.

#What actually fixed it

The remediation was unglamorous and effective:

• Audit every plugin against what it actually did, then remove the overlaps and the abandoned ones, and replace small plugin jobs with a few lines of theme code.
• Rewrite the view counter so it no longer writes to wp_postmeta on every request, which let the database shrink back.
• Move over 1.5 GB of static PDFs off the application server to Cloudflare R2 object storage, so the VPS was not serving large files it had no business serving.
• Add a Redis object cache so repeated queries hit memory instead of the database, relieving the 3 vCPU VPS.
• Close xmlrpc.php, turn off error display on production, and bring the remaining plugins up to patched versions.

None of this is clever. It is discipline applied to a stack that had none, and it is the bulk of what real Core Web Vitals work turns out to be once you look past the lab score.

#Why AI-assisted builds keep recreating this

Plugin sprawl predates AI. But AI assistants make it worse in a specific way: when the answer to every requirement is “install a plugin for that,” the debt accumulates faster, because suggesting a plugin is the path of least resistance for an assistant just as it is for a person in a hurry. You end up with the same 30-plugin stack, only assembled in an afternoon. That is why this teardown sits inside our broader AI-built website rescue work: whether the sprawl came from a person or a prompt, the cleanup is identical, audit, remove, replace with targeted code, and measure.

#Glossary

• wp_postmeta - a core WordPress table storing key-value metadata for posts; read very frequently, so bloating it slows the whole site.
• Object cache (Redis) - an in-memory store that holds the results of repeated database queries so they do not hit the database every time.
• Object storage (Cloudflare R2) - storage for static files like PDFs and images, served independently of your application server.
• LCP (Largest Contentful Paint) - how long until the largest visible element renders; a core measure of perceived load speed.

#The takeaway

If your WordPress site has drifted past a dozen or two plugins, the cost is almost never one obvious culprit. It is the accumulation, plus one or two quiet mechanisms, a view counter, an unindexed log, a synchronous API call, doing real damage in the background. The fix is to count the plugins, find the mechanism that is writing on every request, and move the heavy static weight off the application server. A site at 7.7 seconds is not beyond help. It is usually a stack that nobody has audited, which is a very different and much cheaper problem than it looks.