Use object and page caching (Redis, Varnish, or plugin). Tune PHP-FPM and MySQL. For high traffic, separate DB and use a dedicated or larger VPS. Consider managed WordPress or headless if the team prefers not to manage servers.
Caching
- Object cache: Redis or Memcached backend for WordPress object cache (sessions, query results). Reduces DB load significantly.
- Page cache: Full-page cache (Varnish, Nginx FastCGI cache, or plugin like WP Super Cache, W3 Total Cache) so repeated visitors get static HTML. Invalidate on post update.
- CDN: Offload static assets (images, CSS, JS) to a CDN to reduce origin load and latency.
PHP and MySQL
- PHP-FPM: Tune pm.max_children and pm processes for your RAM. Use OPcache; keep PHP version supported (e.g. 8.x).
- MySQL: InnoDB buffer pool, query cache (if available), connection pool. Index tables properly; avoid heavy queries on large tables.
- Separate DB: When traffic grows, move MySQL to its own server so app and DB do not compete for CPU and I/O.
When to move to dedicated
- VPS limits: Consistent high CPU, memory, or I/O; need for more control or predictable performance.
- Dedicated: Full server for WordPress and (optionally) separate DB server. No noisy neighbors; better for high traffic or complex plugins.
- Managed WordPress: Provider handles updates, security, and scaling. Good when the team wants to focus on content and themes, not servers.
- Headless: Use WordPress as CMS (API) and serve front-end from a static site or separate app. Scales better for read-heavy traffic.
Summary
Cache at object and page level; tune PHP-FPM and MySQL; separate DB when needed. Move to dedicated or managed WordPress for high traffic or less ops.
