WordPress powers over 40% of the web, yet it has a reputation for poor performance at scale. That reputation is largely undeserved. The platform itself is efficient. The problems arise from poor hosting choices, unoptimised plugins, and missing caching layers. Over fifteen years of WordPress development, we have built and maintained sites serving millions of page views per month, and the performance strategies are well-understood.
The foundation of WordPress performance is full-page caching. A cached WordPress page is just an HTML file served from disk or memory, which any web server can deliver in single-digit milliseconds. We use a layered caching approach: a CDN like CloudFront at the edge, Nginx FastCGI caching on the server, and Redis object caching for database query results. With this stack in place, the PHP application only executes for uncached requests, logged-in users, and form submissions.
WordPress performance problems are almost never WordPress problems. They are infrastructure and plugin problems.
Database optimisation is the second priority. A default WordPress installation generates dozens of database queries per page load, many of which are redundant. We use the Query Monitor plugin to identify slow queries, then address them through targeted indexing, query optimisation, and in some cases replacing WordPress queries with custom SQL. The wp_postmeta table is the most common bottleneck; for sites with large amounts of custom field data, we migrate critical meta to dedicated tables with proper indexing.
The Performance Stack
Plugin discipline is essential. Every plugin adds PHP execution time, database queries, and often external HTTP requests. We audit every plugin for performance impact before approving it for client sites. A single poorly-written plugin can double page generation time. We maintain a list of approved plugins that have been tested for performance, security, and maintenance status. For functionality that no well-maintained plugin provides, we build custom solutions.
- Implement full-page caching with a CDN, server-level cache, and object cache
- Audit every plugin for performance impact before deployment
- Optimise the wp_postmeta table for sites with heavy custom field usage
- Use a horizontal scaling architecture with shared storage for high-traffic sites
- Monitor performance continuously with tools like Query Monitor and New Relic
- Set a performance budget and test against it in your CI pipeline
The infrastructure architecture for high-traffic WordPress uses an Auto Scaling Group behind an ALB, with a shared EFS volume for uploads and an Aurora MySQL cluster for the database. This allows horizontal scaling during traffic spikes while maintaining a shared filesystem that all instances can access. Deployments are handled through a custom pipeline that builds a fresh AMI, runs integration tests, and performs a rolling update across the Auto Scaling Group.
