Is mod_pagespeed dead or deprecated?

The original Google and Apache-incubator repositories are archived and read-only (the incubator was archived on 2025-04-10), so in that sense the upstream project stopped. The codebase itself is not dead: it is maintained under the name mod_pagespeed 1.15 with current dependencies and modern packaging. "Deprecated" describes the archived upstream, not the software you can run today.

Why did mod_pagespeed go quiet?

Google moved mod_pagespeed and ngx_pagespeed to an Apache Software Foundation incubator. The incubator produced one release, 1.14.36.1, in August 2020, then went inactive — zero commits in 2024 and zero in 2025 — before being archived in April 2025. The code was also effectively un-buildable on modern systems, because it built with a 2012-era gyp and Python 2 toolchain pinned to Ubuntu 14.

Is the maintained version a drop-in replacement?

mod_pagespeed 1.15 keeps the same directives and the same filter names as the version you already run, so existing configuration carries over. The visible change is that the build system was migrated from gyp to Bazel, the cache backend was replaced, and the dependencies were brought current — not the directive surface.

Were the security vulnerabilities fixed?

The dependency CVEs were cleared by bumping the vendored libraries. libwebp went from 1.1.0 to 1.5.0, which clears CVE-2023-4863 (exploited in the wild); the image codecs (libpng, giflib, libjpeg-turbo) were brought current; curl was moved to the 8.x line and bumped specifically to clear a CVE cluster; and on the nginx side, when the Ubuntu CVE-2026-49975 patch shifted a struct and hung our prebuilt module (built against upstream nginx rather than the patched source each distro ships), we fixed the packaging to build per-distro and added a runtime guard.

What is the difference between mod_pagespeed 1.15 and ModPageSpeed 2.0?

mod_pagespeed 1.15 is the maintained continuation of the original module — same directives, same filters, Apache and nginx (plus IIS). ModPageSpeed 2.0 is a from-scratch C++23 rewrite that runs as an nginx reverse proxy or as ASP.NET Core middleware, moves optimization out of the web-server worker process, and uses a new variant-aware cache. 2.0 went GA on 2026-05-17. Run 1.15 if you want a drop-in upgrade; consider 2.0 for new deployments.

Maintenance status

Is mod_pagespeed still maintained?

Yes. The original Google and Apache-incubator repositories are archived, and the project went dormant in 2024 and 2025. It is maintained again: We-Amp ships mod_pagespeed 1.15 with the dependency CVEs cleared and signed apt and yum packages, alongside a from-scratch rewrite, ModPageSpeed 2.0. This page sets out what stopped, what did not, and what there is to run today.

The short answer

mod_pagespeed is maintained. We-Amp B.V. helped maintain the open-source project and prepared its last releases under both Google and the Apache incubator, contributing externally rather than as a Google employee. After a two-year gap, active development resumed on 2026-01-24, with more than 633 commits landing in 2026. The maintained line is mod_pagespeed 1.15, a drop-in continuation that keeps the same directives and filter names. A separate, from-scratch rewrite called ModPageSpeed 2.0 went GA on 2026-05-17.

Install the maintained build The maintained mod_pagespeed

What “dead” refers to, and what it doesn’t

When people call mod_pagespeed dead or deprecated, they are describing the upstream repositories. Google moved the project to an Apache Software Foundation incubator, which published a single release, 1.14.36.1, in August 2020. The incubator then went quiet and was archived and made read-only on 2025-04-10. That part is true: the original repositories are frozen.

Two things are separate from that. First, the codebase had also become un-buildable on modern systems, because it built with a 2012-era gyp and Python 2 toolchain pinned to Ubuntu 14 — which is why a fresh build attempt fails before it produces a module. Second, the software you can run today is not the archived upstream. It is maintained under the name mod_pagespeed 1.15, with a modern build system, current dependencies, and signed packages. “Archived upstream” and “nothing to run” are not the same statement.

The maintenance timeline

The clearest way to read the status is the commit history: the project stopped, then started again. The figures below are the commit counts per calendar year.

Feb 2018 Google publishes the last Google-era stable release, 1.13.35.2. The project then moves to an Apache Software Foundation incubator.
Aug 2020 The incubator publishes one release, 1.14.36.1. The build still depends on a 2012-era gyp and Python 2 toolchain.
2024 – 2025 Dormant. Zero commits in 2024, zero in 2025. The upstream incubator repositories are archived and made read-only on 2025-04-10.
Jan 2026 Active development resumes on 2026-01-24. The build is migrated from gyp to Bazel, dependencies are brought current, and the dependency CVEs are cleared.
2026 More than 633 commits land. mod_pagespeed 1.15 ships as signed apt and yum packages, and the from-scratch ModPageSpeed 2.0 rewrite goes GA on 2026-05-17.

Commits per year, for reference: 2020 = 61, 2021 = 4, 2022 = 6, 2023 = 7, 2024 = 0, 2025 = 0, then more than 633 in 2026.

Why maintenance matters here specifically

A web-optimization module decodes attacker-controlled image bytes while it rewrites them, so the image codecs are an exposed surface. A build frozen at the August 2020 incubator release still ships the 2020 versions of those decoders. The maintained line brings them current:

libwebp 1.1.0 → 1.5.0 — clears CVE-2023-4863, the libwebp heap overflow that was exploited in the wild.
The image codecs libpng, giflib, and libjpeg-turbo were brought to current upstream versions.
curl moved to the 8.x line and was bumped to clear a CVE cluster, with the HTTP fetcher rewritten on top of it.
When Ubuntu's CVE-2026-49975 patch shifted a struct, it spun the worker on our prebuilt module, which had been built against upstream nginx rather than the distro's own patched source. We fixed it with per-distro builds and a runtime guard. Ongoing fixes like this are what a maintained line provides.

What there is to run today

There are two maintained lines. They share the same cache library and the same commercial licensing model; they differ in architecture.

Drop-in continuation

mod_pagespeed 1.15

The maintained continuation of the original module. Same directives, same filter names, so your existing configuration carries over. Runs on Apache and nginx, plus a native IIS port. The build moved from gyp to Bazel and the cache backend was replaced, but the directive surface you configure did not change.

The maintained mod_pagespeed →

From-scratch rewrite

ModPageSpeed 2.0

A clean-room C++23 rebuild that runs as an nginx reverse proxy or ASP.NET Core middleware. Optimization runs in a separate worker process, not inside the web-server worker, and a new variant-aware cache serves results with no copy on a hit. It went GA on 2026-05-17.

What 2.0 does →

Both are free to install and run. Production use requires a commercial license — but the software never locks you out. An unlicensed install keeps optimizing and adds an X-PageSpeed-Warn: unlicensed response header; it never refuses to optimize. See pricing for the licensing ladder.

Installing the maintained build

The maintained packages are signed and live at packages.modpagespeed.com. On Debian and Ubuntu the nginx module installs from apt — no compiling the 2020 toolchain:

# add the signed repo, then:
apt-get install nginx-module-pagespeed

# the package drops the module in and adds a modules-enabled
# auto-include — there is no load_module line to copy by hand.
# enable it in a server {} block:
server {
    pagespeed on;
    pagespeed FileCachePath /var/cache/pagespeed;
}

The signed apt matrix is exact-version-pinned to each distro’s stock nginx (Debian 11 bullseye (nginx 1.18.0), Debian 12 bookworm (nginx 1.22.1), Debian 13 trixie (nginx 1.26.3), Ubuntu 22.04 jammy (nginx 1.18.0), Ubuntu 24.04 noble (nginx 1.24.0)), for amd64 + arm64. The Apache module ships across the same distros via apt, and there is an el9 yum tree. The pin is required: nginx’s --with-compat does not relax the dynamic-module version check, so each module is built against its distro’s exact nginx. See the mod_pagespeed 1.15 documentation and the live demo for a running instance.

Move off the archived build

If you are running a frozen 2020-era build, the maintained mod_pagespeed 1.15 is a drop-in upgrade: the directives are unchanged, and the dependency CVEs are cleared. Install and run it unlicensed to evaluate it; production use requires a commercial license — but the software never locks you out.

Download & run → Read about the maintained module →

Production use requires a commercial license — but the software never locks you out.

mod_pagespeed maintenance: common questions

Is mod_pagespeed still maintained?: Yes. After a dormant period in 2024 and 2025, We-Amp picked the project back up: the maintained line, mod_pagespeed 1.15, ships with the dependency CVEs cleared and signed apt and yum packages. We-Amp helped maintain mod_pagespeed and prepared its last Google-era and Apache-incubator-era releases as an external contributor, and resumed active development in January 2026.
Is mod_pagespeed dead or deprecated?: The original Google and Apache-incubator repositories are archived and read-only (the incubator was archived on 2025-04-10), so in that sense the upstream project stopped. The codebase itself is not dead: it is maintained under the name mod_pagespeed 1.15 with current dependencies and modern packaging. "Deprecated" describes the archived upstream, not the software you can run today.
Why did mod_pagespeed go quiet?: Google moved mod_pagespeed and ngx_pagespeed to an Apache Software Foundation incubator. The incubator produced one release, 1.14.36.1, in August 2020, then went inactive — zero commits in 2024 and zero in 2025 — before being archived in April 2025. The code was also effectively un-buildable on modern systems, because it built with a 2012-era gyp and Python 2 toolchain pinned to Ubuntu 14.
Who maintains mod_pagespeed now?: We-Amp B.V., a Dutch company. We-Amp helped maintain the open-source project and prepared its last releases under both Google and the Apache incubator, contributing externally rather than as a Google employee. Development resumed on 2026-01-24, with more than 633 commits landing in 2026 after the two-year gap.
Is the maintained version a drop-in replacement?: mod_pagespeed 1.15 keeps the same directives and the same filter names as the version you already run, so existing configuration carries over. The visible change is that the build system was migrated from gyp to Bazel, the cache backend was replaced, and the dependencies were brought current — not the directive surface.
Were the security vulnerabilities fixed?: The dependency CVEs were cleared by bumping the vendored libraries. libwebp went from 1.1.0 to 1.5.0, which clears CVE-2023-4863 (exploited in the wild); the image codecs (libpng, giflib, libjpeg-turbo) were brought current; curl was moved to the 8.x line and bumped specifically to clear a CVE cluster; and on the nginx side, when the Ubuntu CVE-2026-49975 patch shifted a struct and hung our prebuilt module (built against upstream nginx rather than the patched source each distro ships), we fixed the packaging to build per-distro and added a runtime guard.
What is the difference between mod_pagespeed 1.15 and ModPageSpeed 2.0?: mod_pagespeed 1.15 is the maintained continuation of the original module — same directives, same filters, Apache and nginx (plus IIS). ModPageSpeed 2.0 is a from-scratch C++23 rewrite that runs as an nginx reverse proxy or as ASP.NET Core middleware, moves optimization out of the web-server worker process, and uses a new variant-aware cache. 2.0 went GA on 2026-05-17. Run 1.15 if you want a drop-in upgrade; consider 2.0 for new deployments.