Is mod_pagespeed deprecated? (2026)

Yes. mod_pagespeed is deprecated. The 1.13.35.2 binaries still install, but the project receives no maintenance and the dependency stack has not been patched in years. The maintained continuations are ModPageSpeed 2.0 and mod_pagespeed 1.1, both developed by We-Amp B.V.

Practical paths forward

You currently run	Best path
mod_pagespeed 1.13.35.2 on Apache	mod_pagespeed 1.1 for Apache — drop-in upgrade
ngx_pagespeed on nginx	ModPageSpeed 2.0 (nginx-first) or mod_pagespeed 1.1 for nginx (drop-in)
IISpeed on Windows / IIS	mod_pagespeed 1.1 for IIS or WeAmp.PageSpeed NuGet middleware
Envoy filter chain	mod_pagespeed 1.1 for Envoy
New deployment, want modern architecture	ModPageSpeed 2.0
ASP.NET Core application	WeAmp.PageSpeed NuGet middleware

If you’re deciding between 2.0 and 1.1, the rough rule is: pick 1.1 if you have an existing pagespeed-style configuration you want to keep working and want a security-patched upgrade. Pick 2.0 if you’re starting fresh, or if AVIF, variant-aware caching, and zero-copy serving are worth a re-architecture. The deeper comparison lives in the mod_pagespeed alternatives post.

Install snippets

# ModPageSpeed 2.0 — Docker Compose
curl -fsSL https://get.modpagespeed.com | sh
docker compose up -d

# mod_pagespeed 1.1 — Debian/Ubuntu
curl -fsSL https://packages.modpagespeed.com/setup-apt.sh | sudo bash
sudo apt install mod-pagespeed-stable

# mod_pagespeed 1.1 — RHEL/Fedora
curl -fsSL https://packages.modpagespeed.com/setup-yum.sh | sudo bash
sudo dnf install mod-pagespeed-stable

# nginx (1.1, drop-in for ngx_pagespeed)
load_module modules/ngx_pagespeed.so;
pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;

What happened — the short history

mod_pagespeed started as a Google open-source project in 2010. It was an Apache module that rewrote HTML, CSS, JavaScript, and images on the fly to reduce page weight. The nginx port (ngx_pagespeed) followed in 2013, and the IIS port (IISpeed, by We-Amp) shortly after.

The module shipped at industrial scale. Hosting providers bundled it in their cPanel and Plesk stacks. CDN vendors used the libraries inside their own optimization layers. It served billions of pages.

In 2017, Google handed mod_pagespeed to the Apache Software Foundation as part of incubation, and active Google-side development effectively ended at that point. Maintenance contributions came in from a small group of external maintainers, including Otto van der Schaaf at We-Amp, who shipped the final 1.13.35.2 release.

The Apache Incubator podling retired in 2023, and the repositories were marked read-only on GitHub in 2025:

• apache/incubator-pagespeed-mod
• apache/incubator-pagespeed-ngx

That’s the state today. The code is public, the binaries are downloadable, the documentation is up. Nobody is patching it.

What still works

The 1.13.35.2 binaries still install. They still build (against an increasingly narrow toolchain). And they still serve pages: image optimization, CSS/JS minification, critical CSS, all running.

If you have a working install and your threat model accepts unpatched dependencies, you can keep running it. Some operators have. The accumulating cost shows up in several places. The bundled libpng, libwebp, libjpeg, and ICU versions have all racked up CVEs since the 1.13.35.2 release (libwebp alone shipped CVE-2023-4863, a heap overflow that hit every browser using the bundled decoder), and mod_pagespeed decodes attacker-controlled image bytes on every rewrite, which is exactly the threat surface those CVEs hit. Builds against current Apache trunk fail, so distributions that ship newer Apache eventually stop being viable. WebP support landed before the freeze; AVIF never did. LCP, INP, and CLS signals are missing from the filter set. And the build still wants Bazel 0.x, Python 2, and old glibc constraints, so setting it up from scratch on a 2026 machine is a weekend project.

The binaries work; the ecosystem around them is decaying.

ModPageSpeed 2.0 — the actively-maintained continuation

We-Amp B.V. — founded by mod_pagespeed maintainer Otto van der Schaaf — develops both the lineage continuation (mod_pagespeed 1.1) and the from-scratch rewrite (ModPageSpeed 2.0).

The 2.0 architecture moves optimization work out of the request path. A separate worker process reads originals from a shared cache, generates up to 36 variants per asset (WebP, AVIF, three viewport sizes, two pixel densities, save-data), and writes them back. Nginx serves cache hits via zero-copy mmap. The request path no longer waits on encoding.

The optimization libraries (the parts that decide how to recompress a JPEG, how to fold a stylesheet, how to extract critical CSS) are the same ones mod_pagespeed proved at scale. The architecture around them is new.

For deployments that want a drop-in upgrade with the same configuration syntax and same admin console, mod_pagespeed 1.1 continues the original codebase with security patches, modern toolchain, AVIF, Apache 2.4+, nginx 1.30, IIS, and Envoy ports.

What about PageSpeed Insights?

If you’ve been searching for “PageSpeed” and ended up here, a quick disambiguation: pagespeed.web.dev (PageSpeed Insights, PSI) is a different Google product. It’s a diagnostic tool that scores a URL on Core Web Vitals, and it’s still actively maintained. PSI tells you whether your page passes; a server-side module like ModPageSpeed implements the fixes PSI recommends.

See Google PageSpeed Module alternative for the full disambiguation.

Where to read next

• mod_pagespeed alternative — full comparison and decision matrix
• ngx_pagespeed alternative — for the nginx audience specifically
• IISpeed alternative — for Windows / IIS / ASP.NET
• Google PageSpeed Module alternative — disambiguation against PageSpeed Insights
• mod_pagespeed alternatives — the deep comparison
• Getting started — concrete install steps

Two URLs and you’re done. Use packages.modpagespeed.com for the 1.1 lineage, modpagespeed.com/download for 2.0. The old binaries aren’t moving from dl-ssl.google.com; you should.