mod_pagespeed alternative in 2026

Name: mod_pagespeed
Brand: mod_pagespeed
Availability: InStock

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	The last Google-era 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: 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, 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 — the native module and the optimizer worker

mod_pagespeed 2 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 nginx module package does not pull the worker in: install pagespeed-optimizer first, then point the native nginx module at it with two directives (nginx install steps).

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 worker paired to the Apache or nginx module, or in 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 as a signed installer on the mod_pagespeed GitHub release.

# nginx (the package loads ngx_pagespeed_module.so itself)
pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;

# Apache (the package enables the module; on Debian/Ubuntu run
# sudo a2enmod pagespeed if it was disabled)
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 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 as a signed installer on the mod_pagespeed GitHub release. 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 mod_pagespeed 2 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, 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 an optimizer worker, paired with the Apache or nginx module or in the reverse-proxy deployment, for variant-aware caching and zero-copy serving, and for SVG auto-vectorization in the reverse-proxy deployment. The IIS package ships as a signed installer on the mod_pagespeed GitHub release.

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 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 variant-aware caching and zero-copy serving (and, in the reverse-proxy deployment, SVG auto-vectorization). The Apache packages install the configuration that points the module at the worker; the native nginx module uses it once two directives point it there. The IIS package ships as a signed installer on the mod_pagespeed GitHub release.

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.

mod_pagespeed alternative