Microcaching is an ordinary fastcgi_cache or proxy_cache with a lifetime of one to five seconds instead of the usual minutes. For a dynamic page that needs to look current, one second of caching is invisible to the user, but it removes most of the repeated requests during a traffic spike — for example, when hundreds of readers hit the site at once through the same link.
How microcaching differs from regular fastcgi_cache
Regular page caching for minutes or hours, covered in the article on proxy_cache and fastcgi_cache, fits content that changes rarely — a product page, a blog post. For pages with frequent updates, where a 10-minute cache shows deliberately stale data, that approach does not work.
Microcaching solves a different problem: it does not turn the page into a static one, it just stops the same request from hitting PHP-FPM dozens of times a second. An entry lifetime of 1 or 2 seconds is enough to flatten a spike of simultaneous requests, but too short to be noticeably stale for a real person.
Setting up fastcgi_cache for 1 to 5 seconds
The cache zone and key are set up the same way as for regular fastcgi_cache — the difference is only in the fastcgi_cache_valid value and in handling session cookies more carefully, because microcaching is more often applied to the whole page, including the part that is not normally cached.
The nginx and php-fpm link that the request passes through before hitting the cache is set up as described in the article on Nginx and PHP-FPM.
fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=microcache:10m max_size=512m inactive=10m;
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_cache microcache;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_valid 200 1s;
fastcgi_cache_use_stale updating;
fastcgi_cache_lock on;
fastcgi_cache_bypass $cookie_PHPSESSID;
fastcgi_no_cache $cookie_PHPSESSID;
}
Why a second of caching matters, not just a minute
The effect is easiest to see side by side with other TTL values.
| Cache TTL | What the user gets | Load on PHP-FPM |
|---|---|---|
| 0 (no cache) | always fresh data | every request hits the backend |
| 1 second | data is current almost all the time | dozens of identical requests per second collapse into one |
| 10 minutes | data can be minutes out of date | minimal, but unacceptable for frequently changing content |
The collapsing effect in the middle row only works with fastcgi_cache_lock enabled — without it, simultaneous requests to a cold cache would still all go to the backend at once.
Where microcaching shows up most: WordPress under a traffic spike
For WordPress without a full-featured static cache plugin, microcaching at the nginx level is a fast way to survive a spike of visitors after a link lands on social media or a news aggregator, without touching theme or plugin code.
General WordPress speed-up techniques — page caching, image optimization, a CDN — are covered in the article on speeding up WordPress. Microcaching complements these techniques for cases when the fully warmed page cache still goes stale faster than the peak load requires.
Checklist before enabling microcaching
A short cache lifetime does not remove the usual caching mistakes — if anything, they show up faster, because the cache keeps refreshing constantly.
- Pages for logged-in users are excluded through fastcgi_cache_bypass and fastcgi_no_cache on the session cookie.
- fastcgi_cache_lock is enabled, otherwise during a real spike hundreds of requests will still reach the backend in the first second.
- The fastcgi_cache_valid value is set separately for error codes, so a random 500 is not cached for longer than needed.
- The X-Cache-Status header is added to the response, so it is easy to confirm with curl that microcaching is actually working.
- Forms with a CSRF token and payment pages are excluded from the general caching rule.
Frequently asked questions
Is one second too short to noticeably cut the load?
During a traffic spike, requests to the same page usually arrive not once a second but in dozens or hundreds within that same second — it is exactly that batch that microcaching collapses into one request to PHP-FPM. For even traffic without spikes, the effect is much smaller.
Can microcaching be turned on only during a spike instead of all the time?
Technically fastcgi_cache_valid can be changed on the fly with a configuration reload, but it is simpler to keep microcaching on all the time: under normal load a second of staleness is unnoticeable, and the moment a spike hits, the protection is already in place without manual action.
What if users see each other's data after microcaching is enabled?
This usually means the fastcgi_cache_key is missing parameters that make the response individual — for example the interface language or an identifier from a cookie. The cache for that location must be disabled immediately and the key rebuilt to account for every variable the response content depends on.