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 — today as mod_pagespeed 2.1, open source under the Apache License 2.0 — 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 2.1 keeps the same directives and the same filter names as the version you already run — 1.14 and 1.15 configurations carry over unchanged. 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.

How do mod_pagespeed 1.15 and the 2.0 re-architecture fit into 2.1?

They converged. mod_pagespeed 2.1 continues both: the original module — same directives, Apache and nginx — plus a separate optimizer worker process, under one Apache-2.0 open-source license. The IIS package ships from the 1.15 packaging channel.

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 2.1, the open-source (Apache-2.0) continuation, with the dependency CVEs cleared and signed apt and yum packages. 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 during both the Google era and the Apache incubation, 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 2.1, an open-source (Apache-2.0) drop-in continuation that keeps the same directives and filter names. It converges the 1.15 line and the from-scratch ModPageSpeed 2.0 rewrite (GA 2026-05-17) into one product.

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 2.1, 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.
2026 The lines converge: mod_pagespeed 2.1 ships as the successor to both — same directives, plus the optimizer worker — open source under the Apache License 2.0.

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 cleared them in 1.15 and carries those versions forward:

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.
An Ubuntu security patch to nginx (CVE-2026-49975) changed the module ABI, so our prebuilt nginx module — built against upstream nginx rather than each distro’s patched source — was no longer compatible. We fixed it with per-distro builds and a runtime compatibility guard. Ongoing fixes like this are what a maintained line provides.

The mod_pagespeed 1.15 release write-up walks through the full dependency graph and the sanitizer coverage behind these fixes.

What there is to run today

The maintained line is mod_pagespeed 2.1 — one product, converging the two lines We-Amp shipped through 2026.

The converged line

mod_pagespeed 2.1

The maintained continuation of the original module, open source under the Apache License 2.0. Same directives, same filter names, so your existing configuration carries over. Runs on Apache and nginx, with a separate optimizer worker process doing the heavy lifting outside the web server.

The maintained mod_pagespeed →

The IIS package ships from the 1.15 packaging channel. See the upgrade guide. Running ModPageSpeed 2.0 Docker/Helm? See the migration guide.

Running IISpeed? Its license transfers to mod_pagespeed 2.1 at no cost — see the IISpeed transfer details.

mod_pagespeed 2.1 is open source under the Apache License 2.0: free to install and run. Support — and hardened builds — are what’s for sale; see support.

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 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 documentation and the production deployment guide, or 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 2.1 is a drop-in replacement: the directives are unchanged, and the dependency CVEs are cleared. It is open source under the Apache License 2.0 — install and run it freely. Support — and hardened builds — are what’s for sale.

Download & run → Read about the maintained module →

Open source under the Apache License 2.0. Support plans available.

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 and resumed active development in January 2026; We-Amp helped maintain mod_pagespeed and prepared its last Google-era and Apache-incubator-era releases as an external contributor. The maintained line today is mod_pagespeed 2.1, open source under the Apache License 2.0, with the dependency CVEs cleared and signed apt and yum packages.
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 — today as mod_pagespeed 2.1, open source under the Apache License 2.0 — 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 during both the Google era and the Apache incubation, 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 2.1 keeps the same directives and the same filter names as the version you already run — 1.14 and 1.15 configurations carry over unchanged. 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.
How do mod_pagespeed 1.15 and the 2.0 re-architecture fit into 2.1?: They converged. mod_pagespeed 2.1 continues both: the original module — same directives, Apache and nginx — plus a separate optimizer worker process, under one Apache-2.0 open-source license. The IIS package ships from the 1.15 packaging channel.