Nginx FastCGI Microcaching Strategy for Unauthenticated WordPress Traffic

Full-page caching plugins work well until you have logged-in users, WooCommerce carts, or personalized content — then they either break the personalization or don’t cache at all for those requests. Microcaching solves a narrower but very common problem: absorbing sudden traffic spikes on pages that don’t need to be personalized second-to-second.

The idea

Instead of caching a page for hours, you cache it for a few seconds — just long enough to survive a burst of simultaneous requests hitting PHP-FPM at once, which is usually what actually takes a site down during a traffic spike, not sustained load.

Nginx config

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ \.php$ {
        set $skip_cache 0;
        if ($request_method = POST) { set $skip_cache 1; }
        if ($query_string != "") { set $skip_cache 1; }
        if ($request_uri ~* "/wp-admin/|/wp-login.php|wp-json") { set $skip_cache 1; }
        if ($http_cookie ~* "comment_author|wordpress_logged_in|woocommerce_items_in_cart") { set $skip_cache 1; }

        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 5s;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        # ... standard fastcgi_pass config
    }
}

Why the cookie checks matter

The woocommerce_items_in_cart and wordpress_logged_in checks are what keep this safe — without them, a cached page could get served to a logged-in user showing someone else’s account state, which is a real bug that’s happened on real sites running caching without these exclusions.

Five seconds sounds too short to matter, but during a genuine traffic spike — a post going viral, a flash sale opening — it’s usually enough for PHP-FPM to stop drowning, because most requests in that window are asking for the exact same page.