Skip to main content
ModPageSpeed 2.0 and mod_pagespeed 1.1 — Now available

dl-ssl.google.com mod_pagespeed download

By Otto van der Schaaf

deprecation history

If you landed here, you probably ran something like this and got a working .deb:

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb
sudo dpkg -i mod-pagespeed-stable_current_amd64.deb

That URL has historically served the mod_pagespeed 1.13.35.2 build from 2020. It was the last .deb Google shipped before the project was archived. If the URL still resolves for you in 2026, the file behind it is the same 2020 binary. It has had no security patches in years.

Install the maintained build instead

If you came here looking for an install command, this is the one to run on Debian or Ubuntu. It installs the signed apt repository at packages.modpagespeed.com and the maintained mod_pagespeed 1.1 package:

curl -fsSL https://packages.modpagespeed.com/setup-apt.sh | sudo bash
sudo apt install mod-pagespeed-stable

The package name is unchanged (mod-pagespeed-stable), so .deb file paths in your config management carry over. Same filter syntax, same admin console at /pagespeed_admin/. Full instructions below.

This post explains what happened to the original download, why the file might still be there, what’s broken about installing it today, and where to get a maintained build instead.

Short timeline

YearEvent
2010Google releases mod_pagespeed for Apache.
2013nginx port released as ngx_pagespeed.
2017Google donates the project to the Apache Software Foundation; active Google development ends.
2020mod_pagespeed 1.13.35.2 ships, the final Google-blessed release.
2023Apache Incubator podling retires.
2025GitHub repositories marked read-only.
2020–2026The 2020 binary stays accessible at the dl-ssl.google.com URL with no patches and no successor banner.
2026You’re reading this.

The full history is at mod_pagespeed is deprecated if you want the context.

Why the download URL still works

Google didn’t take the file down. They left it accessible as a courtesy to operators who had install scripts and CI pipelines referencing it. There is no redirect to a successor, no banner on the file, and no notice in the package metadata. The .deb itself is unchanged from its 2020 build.

This is the part that traps people. The URL is the same URL it has been for 15 years. Hosting providers’ documentation still references it. Stack Overflow answers from 2018 still recommend it. The install completes successfully. There is no in-band signal that this is a frozen artifact.

What’s broken about installing it in 2026

Concrete list, not editorial.

Unpatched CVEs in image-decoding dependencies

mod_pagespeed bundles its own libpng, libwebp, libjpeg-turbo, and ICU versions, statically linked. The bundled versions are pinned to their 2020 releases. Every CVE in those libraries since then is unpatched in the module’s address space, including the ones that affect parsing attacker-controlled image bytes (e.g. CVE-2023-4863 in libwebp, a heap overflow that hit every browser using the bundled decoder), which is exactly what mod_pagespeed does on every request that hits its rewrite path.

A sampling of unpatched CVE territory in the bundled libraries:

  • libwebp (multiple buffer-overflow CVEs disclosed 2021–2024, including CVE-2023-4863)
  • libpng (read-out-of-bounds CVEs in chunk parsing)
  • ICU (multiple memory-safety issues in normalization)

If your threat model accepts “module decodes attacker-controlled image bytes with five-year-old image libraries”, the 2020 build is technically functional. For most operators it is not.

No build against newer Apache releases

Apache 2.4 has been the production line for over a decade. Builds against current Apache trunk fail because internal APIs have shifted, and mod_pagespeed has no upstream maintainer to follow those changes. Distributions that backport API changes or move toward newer Apache releases eventually break the module. There is no upstream fix because the upstream is archived.

No AVIF

AVIF support was being prototyped at Google when active development stopped. It never landed in a public release. The 2020 build only emits WebP and the legacy JPEG/PNG paths. In 2026 that’s a meaningful weight penalty for above-the-fold hero images: AVIF is typically 20–30% smaller than WebP at equivalent quality.

No Core Web Vitals signals

LCP, INP, and CLS-aware filters were on the roadmap. None of them shipped. The module’s optimization passes are tuned for 2017-era page-weight metrics, not the 2024+ Core Web Vitals.

The actual filters (image variants, CSS inlining, JS minification) still produce useful output. But Google’s own ranking metric, the one the module was originally designed to improve, has moved on, and the 2020 build doesn’t know about the new shape of the problem.

Toolchain rot

The build system wants old Bazel, Python 2 in some helper scripts, and glibc constraints that match 2020 LTS distributions. Building from source on a 2026 machine is a weekend project even if you don’t change a single line of code. This matters if you ever need to patch a CVE yourself, audit the build for supply-chain assurance, or rebuild for a custom Apache version.

Where to get a maintained build instead

You have two actively-maintained paths. The right choice depends on whether you want a drop-in for an existing 1.13.35.2 install or a modern rewrite designed for nginx.

Path 1: mod_pagespeed 1.1, the lineage continuation

Same configuration syntax as 1.13.35.2. Same filter names. Same admin console. New under the hood: CVE patches, modern toolchain, AVIF, Apache 2.4+, current nginx, IIS, Envoy, Cyclone Cache.

If you have a working 1.13.35.2 install and want a security upgrade that doesn’t require config changes, this is the path. The 1.1 site has the full docs.

Debian / Ubuntu:

curl -fsSL https://packages.modpagespeed.com/setup-apt.sh | sudo bash
sudo apt install mod-pagespeed-stable

RHEL / Rocky / Fedora:

curl -fsSL https://packages.modpagespeed.com/setup-yum.sh | sudo bash
sudo dnf install mod-pagespeed-stable

The setup script installs a signed apt or yum repository at packages.modpagespeed.com, signed with the We-Amp public GPG key. CVE patches ship through the same channel.

Configuration in /etc/httpd/conf.d/pagespeed.conf or /etc/nginx/conf.d/pagespeed.conf is identical to the Google build. No migration needed beyond verifying the new install loaded:

# Apache
$ httpd -M 2>&1 | grep pagespeed
 pagespeed_module (shared)

$ curl -sI http://localhost/ | grep -i pagespeed
X-Mod-Pagespeed: 1.1.0-...
# nginx
$ nginx -T 2>&1 | grep -i pagespeed
load_module modules/ngx_pagespeed.so;
pagespeed on;
...

$ curl -sI http://localhost/ | grep -i pagespeed
X-Page-Speed: 1.1.0-...

Path 2: ModPageSpeed 2.0, the rewrite

A from-scratch rewrite designed for nginx and container-native deployment. Separate worker process, shared Cyclone cache via mmap, runtime content negotiation against Accept. Different architecture from the original mod_pagespeed; the same optimization libraries underneath.

If you’re starting fresh on nginx and want the modern architecture, this is the path.

curl -fsSL https://get.modpagespeed.com | sh
docker compose up -d

The trial is card-at-start via FastSpring. See the pricing page for terms.

Full setup walkthrough at Run ModPageSpeed 2.0 with Docker Compose in 5 minutes.

IIS, ASP.NET Core, Envoy

If you were installing mod_pagespeed because it had a port for your server, the modern equivalents:

What to do with the existing install

If you already installed the 2020 build, here’s the migration:

# Stop the web server
sudo systemctl stop apache2   # or nginx

# Remove the Google build (config files preserved by default)
sudo apt purge mod-pagespeed-stable

# Install the maintained build
curl -fsSL https://packages.modpagespeed.com/setup-apt.sh | sudo bash
sudo apt install mod-pagespeed-stable

# Restart
sudo systemctl start apache2

# Verify
curl -sI http://localhost/ | grep -i pagespeed

Your existing pagespeed.conf continues to work. Same filter names, same admin console at /pagespeed_admin/ (and /pagespeed_global_admin on 1.1 for global trial/license state). Cache directory under /var/cache/mod_pagespeed is preserved across the upgrade and will be re-populated as new requests hit.

If you used the dl-ssl.google.com URL in a Dockerfile, CI script, or Ansible role, swap the install line for the packages.modpagespeed.com apt/yum setup. The package name is unchanged (mod-pagespeed-stable); only the source repo differs.

Why this page exists

The deprecation isn’t loud. Google didn’t take the file down, didn’t add a banner, didn’t redirect to anything. If you found this page by searching for mod_pagespeed download, you probably found the dl-ssl.google.com URL first and were about to install a 2020 binary with years of unpatched CVEs.

The maintained continuations live on modpagespeed.com, both the 1.1 lineage and the 2.0 rewrite. The optimization work that mod_pagespeed did still matters. The 2020 binary isn’t where to get it in 2026.

Get the maintained build

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

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

mod_pagespeed 1.1 is the drop-in continuation; a 14-day trial starts from /pagespeed_global_admin (card-at-start via FastSpring). See license terms. Starting fresh on nginx? The ModPageSpeed 2.0 Docker Compose quickstart covers the rewrite.

Read next