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

Is mod_pagespeed deprecated? (2026)

By Otto van der Schaaf

deprecation migration security

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 continuation is mod_pagespeed 2.1, licensed under Apache-2.0, developed by We-Amp B.V.

Practical paths forward

You currently runBest path
mod_pagespeed 1.13.35.2 on Apachemod_pagespeed 2.1 — drop-in replacement
ngx_pagespeed on nginxmod_pagespeed 2.1 — drop-in for nginx
IISpeed on Windows / IISmod_pagespeed for IIS — the IIS package ships from the 1.15 packaging channel
Envoy filter chainNo packaged build
Reverse proxy in front of any HTTP originmod_pagespeed 2.1 — see the migration guide
ASP.NET Core applicationWeAmp.PageSpeed NuGet middleware

Through 2026, We-Amp shipped two continuations — mod_pagespeed 1.15 and ModPageSpeed 2.0 — and they have since converged: mod_pagespeed 2.1 is a native in-process module for Apache and nginx, using the same ModPagespeed* directives and the built-in /pagespeed_admin/ console, with a separate optimizer worker doing the heavy optimization work outside the web server. It is licensed under Apache-2.0. mod_pagespeed 2.1 is a drop-in upgrade for mod_pagespeed 1.15 — see the upgrade guide. The deeper comparison lives in the mod_pagespeed alternatives post.

Install snippets

# mod_pagespeed 2.1 — ASP.NET Core middleware
dotnet add package WeAmp.PageSpeed.AspNetCore
# mod_pagespeed 2.1 (Apache) — Debian/Ubuntu
curl -fsSL https://packages.modpagespeed.com/setup-apt.sh | sudo bash
sudo apt install mod-pagespeed-stable
# mod_pagespeed 2.1 (Apache) — RHEL/Fedora
curl -fsSL https://packages.modpagespeed.com/setup-yum.sh | sudo bash
sudo dnf install mod-pagespeed-stable
# mod_pagespeed 2.1 (nginx) — Debian/Ubuntu / RHEL/Fedora
sudo apt install nginx-module-pagespeed   # or: sudo dnf install nginx-module-pagespeed
# nginx (2.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.

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 the team at We-Amp, who prepared the 1.13.35.2 release as external contributors.

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

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 shipped a cluster of buffer-overflow CVEs disclosed 2021–2024, including CVE-2023-4863, a heap overflow that hit every browser using the bundled decoder; libpng saw read-out-of-bounds issues in chunk parsing; ICU saw memory-safety issues in normalization — 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.

mod_pagespeed 2.1 — the maintained continuation

We-Amp B.V. — the team that helped build ngx_pagespeed, maintained mod_pagespeed, and drove the project’s Apache incubation — develops the converged continuation, mod_pagespeed 2.1: the native in-process module, joined by a separate optimizer worker, licensed under Apache-2.0.

The worker architecture moves optimization work out of the request path: a separate worker process reads originals from a shared cache, generates the optimized variants, and writes them back, so 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.

mod_pagespeed 2.1 continues the original codebase with security patches and a current toolchain on Apache and nginx. The IIS package ships from the 1.15 packaging channel — see the upgrade guide for details.

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 mod_pagespeed implements the fixes PSI recommends.

See Google PageSpeed Module alternative for the full disambiguation.

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

Like this kind of writeup?

We write about how mod_pagespeed actually works, and what we learn shipping it. Get the next post by email.

Read next