A scenario prompt for working through a 47-plugin site using real Query Monitor timings, flagging overlapping tools and sitewide asset loaders, while catching the plugin that quietly powers something another plugin depends on.
Works with Claude / GPT610 uses★ 4.4
The prompt
performance-plugin-bloat-audit
A client's site has 47 active plugins and Query Monitor's "Plugins" tab shows the
following as the heaviest by load time:
[- Plugin A (SEO toolkit #1): 180ms, hooks into wp_head and admin_init on every request
- Plugin B (backup plugin): 140ms, running a cron check on every admin page load
- Plugin C (page builder addon pack): 260ms, enqueues its full CSS/JS bundle sitewide
- Plugin D (second SEO plugin, mostly unused): 90ms
- Plugin E (related-posts widget): 60ms, but runs a custom SQL query with no caching]
CONTEXT: [Cloudways-hosted DigitalOcean droplet, 2GB RAM, site also runs WooCommerce
and a membership plugin that gates content based on ACF fields]
Work through this as a consultant doing a bloat audit, not a plugin-by-plugin recap:
1. Group the plugins by overlapping function first: two SEO plugins is the obvious
redundancy here, name which one to keep based on what's actually configured versus
just installed and forgotten.
2. For the page builder addon pack loading its full bundle sitewide, name the likely
fix: a setting to enable conditional asset loading, or, if that's unavailable, a
manual dequeue keyed to whether the page actually uses that builder's elements.
3. For the related-posts widget's uncached SQL query, explain whether a caching layer
(transient or object cache) solves it outright or whether the query itself needs
rewriting for large post counts.
4. Propose a safe removal order: which plugins to deactivate first as low-risk, and
which to leave for last because removing them could cascade, for example if the
membership plugin depends on ACF fields, don't touch ACF even though it doesn't
show up as "heavy" in Query Monitor.
5. Call out the one from this list you should NOT just deactivate without a staging
test: the backup plugin, since removing it without confirming an alternate backup
is running first could leave the site with no recovery option.
Bloat audits go wrong when they treat every plugin the same way a load-time number
treats it: heaviest first. That misses the plugin sitting at 60ms that’s actually load-
bearing for a membership gate elsewhere on the site. This prompt forces a dependency
check before a removal order.
Paste your own Query Monitor plugin timings and a one-line note on anything gating
content or payments, since those are the ones worth double-checking before deactivation.