Skip to main content
mod_pagespeed 2.1 is here — open source (Apache-2.0): the module you know, plus the optimizer worker

ngx_pagespeed alternative

The nginx PageSpeed port lives on. The module you knew as ngx_pagespeed is now mod_pagespeed 2.1: 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 2.1 — the maintained nginx module

The module loads into your nginx binary the way ngx_pagespeed did. It is still named ngx_pagespeed.so because it is the nginx port — the one you came here for. Install the signed package, add one load_module line, and keep the pagespeed directives, filter selectors, and URL-based variant fan-out you already wrote. 

# nginx.conf — the native mod_pagespeed 2.1 module
load_module modules/ngx_pagespeed.so;

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

It is the same ngx_pagespeed.so: 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 from the 1.15 packaging channel.

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

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. 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), and the ngx_pagespeed alternative on ngxpagespeed.com walks through the prebuilt nginx module in more detail. Their image and TLS dependencies carry known CVEs that nobody is patching. 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.1.0
    environment:
      ACCEPT_EULA: "Y"
    volumes:
      - shared:/shared
  nginx:
    image: ghcr.io/we-amp/pagespeed-nginx:2.1.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 2.1 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 2.1 is the maintained continuation of the nginx port. It ships a native nginx module — the same ngx_pagespeed.so, 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 2.1 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, add the load_module line, 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 2.1.

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

Both are mod_pagespeed 2.1. 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: one load_module line, 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; to use the optimizer worker with nginx, run the reverse-proxy deployment.

Does the nginx module generate AVIF?

Yes. mod_pagespeed 2.1 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.