How We Audit the Stack
Every plugin in our production estate goes through a four-point audit before it reaches a client server: source readability, query behaviour under load, update cadence over the past 18 months, and deactivation safety. A plugin that fails any one of these is a candidate for replacement, regardless of its popularity.
We also run Query Monitor on every new plugin installation against a clone of the client's production database. If a plugin adds more than 8 queries per page load without a documented caching mechanism, it does not proceed to production without a code review.
Our Core Plugin Set
These are the plugins we install on every new WordPress build unless there is a specific reason not to.
- WP Rocket — full-page caching, asset minification, lazy load, CDN integration. Still the most reliable performance plugin for agency use. We disable its compression feature and handle that at the server level.
- Advanced Custom Fields Pro — we have evaluated every alternative. None match ACF's field group interface and PHP API for complex content models on agency timescales.
- WooCommerce — for e-commerce. We lock to a tested major version and run updates in staging before production. Never auto-update WooCommerce.
- Wordfence (free tier) — firewall and malware scan. The premium real-time feed is valuable but rarely justified on sites below 100 k monthly visitors.
- WP Mail SMTP — transactional email routing through SendGrid or Postmark. WordPress's default mail function is unreliable for delivery.
- Redirection — 301/302 management without touching server config. Reliable, fast, and editors can manage redirects without developer involvement.
What We Cut and Why
These were standard parts of the stack at various points. We removed them after they failed our audit criteria.
- Jetpack: Monolithic with no meaningful way to disable specific modules at the PHP bootstrap level. Even with modules turned off in the admin, the plugin loads its entire autoloader on every request. Replaced by individual purpose-built plugins for each feature we needed.
- Smush (WP Smush): Added 12–22 queries on image attachment pages. Replaced by Imagify, which offloads processing asynchronously and does not touch the query path.
- WPForms (free): Form submissions stored in the database with no cleanup mechanism. After 18 months a site with a high-traffic contact form had 40 k orphaned records slowing post meta queries sitewide. Replaced by Gravity Forms with a cron-based retention policy.
- All-in-One SEO: Overlapping functionality with Yoast at multiple clients created configuration conflicts during migrations. We standardised on Yoast across the estate to eliminate the variable.
Hosting Decisions
We route new clients toward managed WordPress hosts with object caching included: WP Engine, Kinsta, and Cloudways (with Redis add-on) are our three active choices depending on budget and technical requirements.
We do not use shared hosting for any site above 20 k monthly visitors. The performance ceiling is too low and the security isolation is inadequate for client data.
Redis object caching is the single highest-return infrastructure change for most WordPress sites. If your host does not include it, add it before any additional performance plugin work.
Process Patterns
Beyond the plugin list, two process decisions have more impact than any individual tool choice.
- Staging-first updates: Every plugin update, including security patches, is applied to a staging clone first and tested against a smoke-check list before being applied to production. We have prevented two significant production breakages in the past year this way.
- Plugin count discipline: We maintain a target of fewer than 20 active plugins per site. When a client requests a feature that would require a new plugin, we evaluate whether an existing plugin can be extended instead. Plugin count is a proxy for maintenance surface area.
What We'd Change
If we were building the stack from scratch today, we would write more bespoke lightweight plugins for features that currently rely on heavy general-purpose tools. Our own Lab plugins — GeoIP2 Self-Contained and MDL Local Service Lead Validator — came from exactly this instinct. The pattern works. The challenge is client timeline: bespoke development is harder to justify on a discovery call than a known plugin with a five-star rating.
We are also evaluating a shift toward block-based development for all new builds rather than ACF-heavy templates. The tooling is not quite there yet for complex field relationships, but the trajectory is clear.