Compare package tracks by distribution and architecture. Checkmarks show the architectures available in each repository channel.
Distro
Channel
aarch64
noarch
x86_64
Version
Fedora 44
Stable
—
1.30.4+1.0.1
NGINX mainline
—
1.31.4+1.0.1
Fedora 43
Stable
—
1.30.4+1.0.1
NGINX mainline
—
1.31.4+1.0.1
Description
Native Edge Side Includes for NGINX: per-fragment caching with independent
TTLs using nothing but NGINX and `proxy_cache`. Cache a page shell for hours
while a cart fragment stays uncached and a header fragment caches for a
minute — the classic reason a Varnish instance sits in front of NGINX.
Key Features:
- `` resolved as an NGINX subrequest, so each fragment can point
at a `location` with its own `proxy_cache` / `proxy_cache_valid`
- Same-authority absolute and scheme-relative include URLs are reduced to
safe local subrequests, including Magento's percent-encoded fragment paths
- Fragments fetched **concurrently**. Open-source Varnish Cache resolves ESI
includes sequentially, with the head-of-line blocking that implies; parallel
ESI is a Varnish Enterprise feature
- `alt=` and `onerror="continue"` failover on a 4xx/5xx fragment
- `esi:remove`, `esi:comment`, `esi:vars` markup stripping, ``
unwrap; unknown `esi:` tags pass through verbatim rather than being guessed
at, matching Varnish
- `esi_plan` — memoises where a cached object's ESI constructs are into a
shared zone, so a page is scanned once per object rather than once per
delivery. Markup-dense cached pages go from 34-40% of `esi off` throughput
to ~97%
- `esi_stitch` — stores what each unchanged run of the page deflates to and
emits those bytes instead of re-compressing the shell on every delivery,
the way Varnish does. Moves the compression level off the hot path entirely
- Gzipped upstreams need nothing configured: the module decodes what the
`gunzip` filter declined to, and the assembled page is recompressed as usual
Measured head-to-head against Varnish Cache OSS 7.6.5 on a dedicated 8-vCPU
host, one core each, output verified byte-identical before timing: no row in
the 24-row matrix is won by Varnish, with 2-6x less CPU per request. Pages
with one fragment over a latent origin are a dead heat, which is the honest
boundary — there is nothing to parallelise with a single include.
Verified on twin Magento Open Source 2.4.8-p5 stores with eight instrumented
50 ms fragments: NGINX rendered every fragment in parallel batches with
0.411 s median page latency versus Varnish 8.0.2 at 1.001 s, a 59% reduction.
Used with the Pro cache-purge module, Magento's native X-Magento-Tags purge
requests selectively invalidate related pages without a full cache flush.
Premium module by GetPageSpeed.
To enable this module after installation, add the following to
/etc/nginx/nginx.conf and reload NGINX:
load_module modules/ngx_http_esi_filter_module.so;
Alternatively, enable all installed modules by adding this line
to the top of /etc/nginx/nginx.conf:
include /usr/share/nginx/modules/*.conf;