yum upgrades for production use, this is the repository for you.
Active subscription is required.
Technical Briefing: NGINX Microcaching — Varnish-Style Full-Page Caching with Stock Directives
The Problem
Full-page caching typically means standing up a second daemon (Varnish), a second port, and a second configuration language alongside NGINX. That operational overhead is real: an extra process to monitor, an extra config surface to maintain, and an extra hop in the request path.
The question this technique answers is whether the common case — serving mostly-anonymous pages fast and shielding a slow backend — can be handled by NGINX alone, using only directives that ship with it.
The Fix
Microcaching delivers Varnish-style full-page caching using only stock NGINX directives. No second daemon, no port, no config language. The technique uses a deliberately tiny TTL — typically 1 second — to collapse massive request volumes into roughly one backend hit per second per cached page. The cost is at most one second of staleness, which is invisible for news homepages, product listings, or JSON APIs aggregating slow upstream calls.
Core Recipe
The cache is pointed at /dev/shm (tmpfs) via proxy_cache_path, so the cache lives in RAM with no disk I/O. Key directives:
proxy_cache_valid 200 301 302 1s— the micro-TTLproxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504— stale-while-revalidate plus stale-if-errorproxy_cache_background_update on(NGINX 1.11.10+) — refreshes in a background subrequest so no visitor eats rebuild latencyproxy_cache_lock on(NGINX 1.1.12+) — request coalescing so concurrent misses don’t stampede the originadd_header X-Cache-Status $upstream_cache_status— exposesMISS,HIT,EXPIRED,STALE,UPDATING,REVALIDATED, orBYPASSfor observability
Coexisting with Personalized Pages
Personalized pages coexist with the cache via a map on $http_cookie matching wordpress_logged_in, comment_author, and PHPSESSID, then applying:
proxy_cache_bypass— skip lookup (showsBYPASS)proxy_no_cache— don’t store personalized responses
Anonymous traffic gets the cached path; logged-in users get fresh private pages.
If WP Rocket Is Already in Play
If WP Rocket already generates HTML cache files, serve those directly from NGINX rather than building a second proxy cache.
Full-RAM Shared Cache Variant
When whole rendered pages are needed in a shared in-memory store reachable by every NGINX worker — or across a fleet of edge nodes — the open-source srcache module with Memcached or Redis is the tool. Wiring:
- An internal
/memclocation withmemc_pass srcache_fetch GETandsrcache_store PUTon the real location
Status headers X-SRCache-Fetch and X-SRCache-Store confirm STORE on the first request and HIT on the next. Redis works via the redis2 module.
Installation (srcache recipe only — not needed for core microcaching)
- RHEL/CentOS/AlmaLinux/Rocky/Amazon Linux:
dnf installthe GetPageSpeed release RPM, thennginx-module-srcache nginx-module-memc nginx-module-redis2, loading modules viaload_modulelines innginx.conf - Debian/Ubuntu: add the GetPageSpeed APT repo, then install the same three packages — module loading is handled automatically, no
load_modulelines needed
Limitations
Microcaching is not a total replacement for a dedicated cache in every scenario. Varnish or similar is still warranted for cases needing more than what the core recipe provides. But for the common case — serving mostly-anonymous pages fast and shielding a slow backend — the core recipe wins on simplicity: one daemon, one config, no extra moving parts.
Verification
curl -sItwice showsMISSthenHITls -R /dev/shm/nginx-microconfirms cache files live under tmpfs and never touch disk
Practical Payoff
A backend handling a few thousand requests per second directly drops to a trickle while the edge serves hundreds of thousands of cached responses per second from RAM.
Read the full article: NGINX Microcaching: Full-Page Caching Without Varnish
