Performance problems often show up as instability—503s, timeouts, or random slowness—before they look like “slow pages.” This guide covers the main tuning layers and common mistakes so you fix the right thing first.
Start with measurement
- Identify slow pages and peak load windows
- Check Apache and PHP-FPM logs before raising limits
Key tuning layers
| Layer | Purpose | Common mistakes |
|---|---|---|
| OPcache | PHP bytecode caching | Disabled or undersized |
| Object cache | DB query reduction | Misconfigured Redis/Memcached |
| Page cache | HTML caching | Caching logged-in users |
| CDN | Edge delivery | Caching dynamic or admin routes |
PHP-FPM basics
- Watch for queueing and worker exhaustion
- Tune pool limits intentionally (see PHP memory limits)
- Restart or reload after config changes: PHP-FPM restart vs reload
FAQ
Site is slow and sometimes returns 503.
Check PHP-FPM pool size and memory limits. If workers are exhausted or hitting memory limits, you’ll see 502/503. Use 500 triage to confirm it’s PHP-FPM and not Apache or WordPress.
Should I enable OPcache on production?
Yes. It’s the highest-impact PHP tuning for WordPress. Enable it in the PHP version that serves the site (often in php.ini or the PHP-FPM pool) and set a sensible memory_consumption and max_accelerated_files.
Related
- PHP memory limits and WordPress stability — memory and pool limits
- WordPress 500 errors: fast triage — when you see 500/503