WordPress is a dynamic system. Every page visit — by default — triggers this sequence:
- Nginx receives the request
- Passes it to PHP-FPM
- PHP loads WordPress core
- WordPress queries the database for posts, options, menus, widgets
- PHP assembles the HTML
- Nginx sends the response
On a fast server with a lightweight theme and few plugins, this takes 100–300 milliseconds. On a VPS running multiple sites, with a heavier theme and twenty plugins, it takes 500ms–2 seconds per uncached request.
Cache reduces this dramatically — but only for repeat visits.
The Cache Ceiling
FastCGI cache and Redis object cache are the two most effective optimizations in this series. Together they can make a cached WordPress page nearly as fast as a static HTML file.
The ceiling: every URL’s first visitor always waits for full PHP execution.
When a new post is published, the cache is invalidated. The next visitor to that URL runs the full stack. When a bot crawls 500 URLs simultaneously, 500 PHP processes run simultaneously. When traffic spikes suddenly — a post gets shared, a sale begins — the cache hasn’t warmed yet and every concurrent request hits PHP and the database.
For a content blog with moderate, predictable traffic: cache is sufficient. For a site with thousands of unique URLs, frequent updates, or traffic spikes — cache helps but has limits.
What Actually Consumes Resources
PHP-FPM processes — each handles one request at a time. With 2GB RAM, you can safely run 10–15 PHP-FPM worker processes simultaneously. If 20 requests arrive at once, 5–10 queue and wait.
MariaDB — every uncached WordPress request runs multiple queries. A complex page with widgets, related posts, and custom queries can run 30–50 database queries per load.
WordPress itself — the core loads dozens of files on every request. A site with 40 active plugins loads 40 additional codebases on every PHP execution.
Redis object cache addresses the database bottleneck — frequently accessed data (options, post metadata, transients) is cached in memory. FastCGI cache bypasses PHP entirely for cached pages. Both help. Neither changes what happens when the cache misses.
The Architecture Decision
At some point, some WordPress sites outgrow WordPress.
Not outgrow hosting — outgrow the architecture. Dynamic page generation per request has a cost ceiling that hardware alone can’t remove. Adding RAM and CPU raises the ceiling; it doesn’t eliminate it.
I hit this with a price comparison site. Tens of thousands of product records, prices updating from multiple affiliate APIs, pages needing to stay current. Cache helped with repeat visitors. First visits on a large inventory were still slow. Moving to better hardware helped. Wasn’t enough.
The solution path I went through:
1. Standard cache (Redis + FastCGI) — faster for repeat visitors, still slow for first visits and crawlers.
2. Simply Static — exported the entire WordPress site to static HTML files. Blazing fast. No PHP, no database queries, pure file serving. But the HTML WordPress generates is bloated, non-semantic, difficult for search crawlers to parse cleanly.
3. Typesense — solved the search problem on a static site. But updating thousands of product prices in static files required a separate pipeline.
4. Jamstack with Astro — the actual solution. Generate clean, minimal HTML at build time from structured data. Fast by default, not by optimization. The site you’re reading now is built this way.
The lesson: optimization is the right answer for most WordPress sites. For high-volume, data-heavy, frequently-updated sites — the architecture question eventually becomes unavoidable.
What Part 6 Covers
For the vast majority of WordPress sites on a VPS, the optimizations in this part are sufficient:
- 6.2 — Redis object cache installation and configuration
- 6.3 — PHP-FPM pool tuning for your server’s RAM
- 6.4 — MariaDB configuration and slow query logging
These three optimizations, on top of the FastCGI cache configured in Part 4.5, represent a well-optimized WordPress VPS. The stack this series builds handles a typical content or affiliate site well within its hardware limits.