mod_pagespeed alternative in 2026

The repository still exists, read-only, at apache/incubator-pagespeed-mod. The 1.13.35.2 binaries still install and serve pages. They also haven't taken a security patch in years, won't build against current Apache, emit no Core Web Vitals telemetry, and have no AVIF.

A short history

Year	Event
2010	Google releases `mod_pagespeed` for Apache
2013	Nginx port released as `ngx_pagespeed`
2017	Google donates the project to the Apache Software Foundation; active Google development ends
2018	Google's last stable release, 1.13.35.2
2020	Final open-source release, 1.14.36.1 (Apache incubator)
2023	Apache Incubator podling retires
2025	GitHub repositories marked read-only
2026	Development continues as mod_pagespeed 2.1: the native in-process module for Apache and nginx, with the optimizer worker alongside it

We-Amp B.V. — the team that helped build ngx_pagespeed, maintained mod_pagespeed, and drove the project's Apache incubation — develops that continuation. The open-source history on we-amp.com has the longer version of how the project changed hands, and is mod_pagespeed still maintained? covers what development resumed and what shipped since.

Public development going quiet did not mean the work stopped. We-Amp kept PageSpeed maintained privately through those years, supporting its commercial IISpeed customers without a gap and tracking new compilers, OS releases, and image codecs as they landed. That continuously maintained line is what ships today as mod_pagespeed 2.1, back in the public package repositories.

Why people are looking for an alternative

mod_pagespeed was excellent engineering for its era. The archived 1.13.35.2 binaries still run, but they no longer keep pace with a modern stack:

No security patches in years. Unpatched dependencies (libpng, libwebp, libjpeg, ICU) carry known CVEs (e.g. libwebp CVE-2023-4863).
No build against current Apache. The build needs the original toolchain and won't compile against current Apache releases without patching.
No Core Web Vitals tooling. LCP and INP signals are missing from the filter set.
No modern image formats. AVIF support never landed.
Dated build toolchain. Bazel 0.x, glibc constraints, and pinned Python 2 in the build scripts.

mod_pagespeed 2.1 — the native module and the optimizer worker

mod_pagespeed 2.1 is one product with two moving parts. The native module loads in-process and handles the request; the pagespeed-optimizer worker does the heavy work outside it. The worker reads originals from a shared Cyclone cache, generates up to 37 variants per asset (WebP, AVIF, viewport sizes, pixel densities, save-data, plus SVG for eligible images), and writes them back. The serving side returns cache hits via zero-copy mmap. On the deb and rpm channels the two install and upgrade together as a matching pair, and the Apache packages install the configuration that points the module at the worker. The native nginx module runs on its own; to use the optimizer worker with nginx, run the reverse-proxy deployment.

The optimization libraries underneath are the same ones mod_pagespeed proved at scale; the architecture around them is new.

Read the docs · the full feature set · Support plans

The native module for Apache and nginx

On Apache and nginx the module loads into your server as a native in-process module: no sidecar, no reverse-proxy hop, no container. It carries the same directive surface, the same filter names, and the same admin console as open-source mod_pagespeed, including the classic combine_css, combine_javascript, image spriting, in-place resource optimization, and domain-mapping filters, with granular per-filter control — now on a modernized, secured filter stack with new optimizers. Image optimization covers WebP and AVIF alongside JPEG, PNG, and GIF. New: CVE patches, current toolchain, and — with the Apache module or the reverse-proxy deployment — the Cyclone Cache shared with the optimizer worker.

An existing mod_pagespeed configuration carries over — swap the packages, keep the config. The IIS package ships from the 1.15 packaging channel.

# nginx
load_module modules/ngx_pagespeed.so;
pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;

# Apache
LoadModule pagespeed_module modules/mod_pagespeed.so
ModPagespeed on
ModPagespeedFileCachePath /var/cache/mod_pagespeed

Install from apt / yum · Apache PageSpeed module · Package repositories (packages.modpagespeed.com)

Apache, nginx, Docker, Kubernetes — which integration fits

One product, four ways in. What you are choosing is how it meets your stack, not which version to bet on:

Your stack	How mod_pagespeed 2.1 installs
Apache httpd 2.4+	Native in-process module from the signed apt/yum repository
nginx on Debian, Ubuntu, or Enterprise Linux	Native dynamic module from the same repository, built against your distribution's stock nginx
Existing `mod_pagespeed` 1.13.35.2 deployment, want a patched, drop-in replacement	Native module — the directive surface and filter names carry over
New container-native deployment, in front of any HTTP origin	Docker / nginx reverse proxy — nginx and worker images, shared cache volume
Kubernetes	The Helm chart — nginx and worker as one pod

Three further integrations are available separately, outside those packages. The IIS package ships from the 1.15 packaging channel. For ASP.NET Core there is the WeAmp.PageSpeed.AspNetCore middleware, added in two lines of Program.cs, and the WeAmp.PageSpeed.Sidecar package, which runs a bundled nginx optimizer on loopback behind your Kestrel app.

Migration

The 2.1 directive surface is the same as 1.13.35.2 — most installs are a package swap, and the module reports a version mismatch with its worker loudly instead of absorbing it. Container deployments configure the reverse proxy instead, which is a smaller surface than an inline module. See getting started for both install paths, and the deeper comparison for how it lines up against other tools.

Frequently asked questions

Is mod_pagespeed deprecated?

Yes. Google handed mod_pagespeed to the Apache Software Foundation in 2017. The Apache Incubator podling retired in 2023, and the repositories were marked read-only on GitHub in 2025. The 1.13.35.2 binaries still install but have not received security patches in years.

What happened to mod_pagespeed?

Google donated the project to the Apache Software Foundation in 2017, and active Google development ended there. The last open-source release, 1.14.36.1 (2020), was prepared under the Apache incubator by external maintainers including We-Amp. The repository at apache/incubator-pagespeed-mod is now read-only.

What replaces mod_pagespeed?

mod_pagespeed 2.1, actively maintained by We-Amp: the native in-process module for Apache and nginx, with the same configuration syntax, the classic filter set, and the built-in admin console, plus, with the Apache module or the reverse-proxy deployment, an optimizer worker for SVG auto-vectorization, variant-aware caching, and zero-copy serving. The IIS package ships from the 1.15 packaging channel.

Can I still use mod_pagespeed 1.13.35.2?

Yes, and it still installs. It also hasn't taken a security patch in years, won't build against current Apache, has no AVIF, and ships a build toolchain that wants Bazel 0.x and Python 2. If your threat model accepts unpatched dependencies, you can keep running it.

Which platform do I run mod_pagespeed 2.1 on?

Apache and nginx: the native in-process module with the familiar config surface, the classic filter set, and the built-in admin console, plus the optimizer worker for SVG auto-vectorization, variant-aware caching, and zero-copy serving. The Apache packages install the configuration that points the module at the worker. The native nginx module runs on its own; to use the optimizer worker with nginx, run the reverse-proxy deployment. The IIS package ships from the 1.15 packaging channel.

Install and run

Native module (Apache, nginx) — package repos · apt / yum install
Docker and Kubernetes — Docker guide · Helm chart
ASP.NET Core — dotnet add package WeAmp.PageSpeed.AspNetCore · .NET quickstart · Support plans

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