How to install sw-nginx-module-esi in CentOS/RHEL 8 (x86_64)

Native ESI (Edge Side Includes) with parallel fragment fetching

Important: The Plesk control panel must be installed on your server before using this repository.

Install

# The Plesk control panel must be installed on your server.
sudo dnf -y install https://extras.getpagespeed.com/release-latest.rpm
sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --enable getpagespeed-extras-plesk
sudo dnf -y install sw-nginx-module-esi

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. After installation, enable this module by running: plesk sbin nginx_modules_ctl --enable esi

Compatibility

This package is compatible with all RHEL-based distributions, including CentOS, AlmaLinux, Oracle Linux, Rocky Linux, etc.

RPMs

Subscribe