Skip to main content

ngx_pagespeed alternative

The nginx PageSpeed port lives on. The module you knew as ngx_pagespeed is now mod_pagespeed: the same native nginx module, the same pagespeed directives, built against current nginx and security-patched. Maintained by the people who maintained the original.

Install the nginx module Support plans

Open source under the Apache License 2.0 — free in development and in production.

Install it in two commands

# Ubuntu / Debian
curl -fsSL https://packages.modpagespeed.com/install.sh | sudo sh
apt install nginx-module-pagespeed

# AlmaLinux / RHEL / Rocky
curl -fsSL https://packages.modpagespeed.com/install.sh | sudo sh
dnf install nginx-module-pagespeed

mod_pagespeed, the maintained nginx module

The module loads into your nginx binary the way ngx_pagespeed did. The module file is ngx_pagespeed_module.so, the nginx port you came here for. Install the signed package, which loads the module for you, and keep the pagespeed directives, filter selectors, and URL-based variant fan-out you already wrote. 

# nginx.conf: the native mod_pagespeed module
# The package loads the module; check with:
#   sudo grep -Rns '^[[:space:]]*load_module.*pagespeed' /etc/nginx /usr/share/nginx/modules
# Only a module installed by hand needs, at the top of nginx.conf:
# load_module modules/ngx_pagespeed_module.so;                    # Debian / Ubuntu
# load_module /usr/lib64/nginx/modules/ngx_pagespeed_module.so;   # Enterprise Linux

pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;
pagespeed RewriteLevel CoreFilters;

It is the same ngx_pagespeed module: the same directive surface as open-source mod_pagespeed, with a modernized, secured filter stack and new optimizers. What changed: the module builds against current nginx, ships current image and TLS dependencies, and takes CVE patches again.

It carries the full classic filter set: combine_css, combine_javascript, image spriting, in-place resource optimization, domain mapping, DNS prefetch. It adds the built-in /pagespeed_admin/ console and per-filter control. It optimizes images to WebP and AVIF alongside JPEG, PNG, and GIF.

The same module runs natively on Apache. The IIS package ships as a signed installer on the mod_pagespeed GitHub release.

Module installation guide · Package repositories (packages.modpagespeed.com) · Support plans

Packages for your distribution's nginx

The signed nginx-module-pagespeed packages cover Debian 12 and 13 and Ubuntu 22.04 and 24.04 on amd64 and arm64, AlmaLinux, RHEL and Rocky 9 on x86_64 and aarch64, and 10 on x86_64. Debian 11 stays on the repository's final 1.15.0 packages. There is nothing to compile.

Each package depends on the stock nginx of its distribution, because nginx refuses to load a module built for a different version. The Ubuntu and Enterprise Linux packages are built against that distribution's own patched nginx source. The module also checks its layout on the first request and passes responses through unoptimized if it does not recognize it. The reasons are in the questions below, and the pinned nginx version per distribution is in the module guide.

Who maintains it

We-Amp B.V., based in Castricum, Netherlands, maintained mod_pagespeed throughout the Google era and helped ship the open-source 1.13.35.2 release. We-Amp owns ngxpagespeed.com, the historical landing page for the nginx port. Two primary sources record that history: Google's 2013 ngx_pagespeed beta announcement names We-Amp among the companies whose developers built the module, and the Apache PageSpeed incubation proposal lists We-Amp engineers among the project's initial committers. When upstream development moved to the Apache Software Foundation and then wound down, the nginx module did not stop. Its maintainers kept shipping it.

Why a maintained continuation matters

Google donated mod_pagespeed and ngx_pagespeed to the Apache Software Foundation in 2017. The Apache Incubator podling retired in 2023, and the repository at apache/incubator-pagespeed-ngx was marked read-only in 2025. The archived sources still document a good design. They no longer build cleanly against current nginx without patching — we wrote up why ngx_pagespeed won't build on modern nginx (and the prebuilt fix). Their image and TLS dependencies carry known CVEs that nobody is patching, including the libwebp version affected by CVE-2023-4863. The maintained module fixed the root cause: its build moved off the Python 2 gyp harness onto Bazel and a current C++ standard, the vendored libraries were brought forward (libwebp 1.1.0 to 1.5.0, clearing CVE-2023-4863; curl to the 8.x line), and each package is built inside its target distribution's own container, so the glibc and libstdc++ it needs match the system. A read-only repository is the reason to move to a maintained continuation, not the reason to leave nginx-native optimization behind. That is the gap the maintained module closes: the same module, still maintained.

If you want the container-native shape: the Docker reverse proxy

The same product has a second integration. Instead of loading into your nginx, it runs as a Docker reverse proxy in front of nginx (or any HTTP origin), which keeps optimization work off the request path. The proxy checks the cache and serves the variant via zero-copy mmap on a hit. On a miss it serves the original and notifies the optimizer worker. The worker decodes once and generates up to 37 variants per asset: WebP, AVIF, viewport sizes, pixel densities, save-data, plus SVG for eligible images. It writes them to the variant-aware cache, which the next request reads from a hit.

The optimization core underneath is the same PSOL core that ngx_pagespeed used. The architecture around it is what the C++23 rewrite added: viewport- and density-aware variants, generated proactively rather than on demand. 

# docker-compose.yml — the nginx reverse proxy and the optimizer worker
services:
  worker:
    image: ghcr.io/we-amp/pagespeed-worker:2.7.0
    environment:
      ACCEPT_EULA: "Y"
    volumes:
      - shared:/shared
  nginx:
    image: ghcr.io/we-amp/pagespeed-nginx:2.7.0
    ports:
      - "8080:8080"
    volumes:
      - shared:/shared
volumes:
  shared:

On Kubernetes the Helm chart deploys the same two images as one pod. On ASP.NET Core, the separately available WeAmp.PageSpeed.AspNetCore middleware skips the proxy entirely: 

# ASP.NET Core — the middleware package
dotnet add package WeAmp.PageSpeed.AspNetCore

the full feature set · Docker guide · .NET quickstart · Download & run

Which integration fits your nginx

mod_pagespeed is the nginx answer either way: both integrations share the optimization core (PSOL) and the Cyclone cache, and both are open source under the Apache License 2.0: free in development and in production. What differs is where the optimization runs.

What you want Native nginx module Docker / nginx reverse proxy
Deployment In-process in your nginx (load_module) A container in front of nginx or any other HTTP origin
Configuration Your existing pagespeed directives, unchanged Compose or Helm values; the directive surface is smaller
Install Signed apt/yum package, pinned to your distribution's stock nginx Published images, or the Helm chart on Kubernetes
Image formats WebP, AVIF, JPEG, PNG, GIF WebP, AVIF, JPEG, PNG, GIF
Cache serving Variant-aware Cyclone cache, zero-copy mmap on hits Variant-aware Cyclone cache, zero-copy mmap on hits
Admin / stats Built-in /pagespeed_admin/ console Worker dashboard and stats
Best when You run nginx yourself and want the module where ngx_pagespeed sat You are container-native, or the origin is not nginx

Migration

Coming from ngx_pagespeed 1.13.35.2, the native module is a package swap. Install the signed nginx-module-pagespeed from packages.modpagespeed.com and keep your directives unchanged.

Choosing the reverse proxy instead is a deployment change rather than a config port: the directive surface is intentionally smaller and the worker model differs from inline rewriting. The migration notes cover what stays, what changes, and how the worker model works.

Frequently asked questions

Is the nginx port still maintained?

Yes. mod_pagespeed is the maintained continuation of the nginx port. It ships a native nginx module (the same ngx_pagespeed module, the same pagespeed directives) built against current nginx, with current image and TLS dependencies and applied CVE patches. We-Amp helped ship the open-source 1.13.35.2 release and kept the module going.

Can I keep my existing pagespeed directives?

Yes. mod_pagespeed keeps the pagespeed directive surface and the classic filter names, so the directives and filter selectors you already wrote keep working. Install the signed package (it loads the module itself), keep your config.

What happened to the old ngx_pagespeed repository?

Google donated mod_pagespeed and ngx_pagespeed to the Apache Software Foundation in 2017. The Apache Incubator podling retired in 2023, and apache/incubator-pagespeed-ngx was marked read-only in 2025. The archived sources no longer build cleanly against current nginx without patching. The module itself did not stop. Its maintainers kept shipping it, and it ships today as mod_pagespeed.

Native nginx module or Docker reverse proxy — which fits my stack?

Both are mod_pagespeed. Install the native nginx module when you run nginx on Debian, Ubuntu, or Enterprise Linux and want the module in-process where ngx_pagespeed sat: the package loads it, your existing directives, no traffic detour. Run the Docker / nginx reverse proxy when you are container-native, when the origin is something other than nginx, or on Kubernetes via the Helm chart. Both are the same product and the same Cyclone cache library. The native nginx module runs on its own by default; since 2.2.0 (package 1.17.0) it can also hand in-place optimization to the optimizer worker: install the pagespeed-optimizer package of the same release and set pagespeed DaemonSocketPath and pagespeed DaemonVolumePath in the server block.

Why is the nginx module pinned to one exact nginx version?

nginx refuses to load a dynamic module built for a different nginx version, and --with-compat does not relax that check. Even at the same version, a distribution's security patch can change the internal request structures the module reads. So each package depends on the distribution's stock nginx (for example 1.24.0 on Ubuntu 24.04), and the Ubuntu and Enterprise Linux packages are built against that distribution's own patched nginx source. Running an nginx we do not package? Contact us for a matching pinned build.

Why did a routine apt upgrade break my self-built PageSpeed module?

A 2026-06-05 Ubuntu security update for CVE-2026-49975 inserted a field into the middle of nginx's internal request-headers struct, shifting every field after it by 8 bytes. A module compiled against the earlier nginx then read the wrong offsets and spun the worker on the first request it tried to optimize, while nginx -t still passed. Our Ubuntu and Enterprise Linux packages are built against the distribution's own patched nginx source, and the module checks its layout on the first request: if it does not recognize it, it logs one alert per worker and passes responses through unoptimized instead of hanging the worker.

Does the nginx module generate AVIF?

Yes. mod_pagespeed encodes AVIF alongside WebP, JPEG, PNG, and GIF, and serves the variant the client signals support for. AVIF is not a reason to pick one integration over another. Pick by deployment fit.

Who maintains this?

We-Amp B.V., based in Castricum, Netherlands. We-Amp helped build ngx_pagespeed and maintained mod_pagespeed, helped drive the Apache PageSpeed incubation, and contributed to open-source PageSpeed releases (including 1.13.35.2). We-Amp owns ngxpagespeed.com, the historical landing page for the nginx port.

Install and run

Related

ngx_pagespeed, nginx, and other product names are trademarks of their respective owners. Comparisons reflect publicly available information as of 2026 and are provided for evaluation; We-Amp B.V. is not affiliated with or endorsed by Google or the Apache Software Foundation.

Search