What is the Google PageSpeed module, and what replaced it

What	Status	What it does
PageSpeed Module (`mod_pagespeed`, `ngx_pagespeed`)	Deprecated (last release 2020)	Server-side optimization module that rewrites HTML/CSS/JS/images at request time
PageSpeed Insights (PSI, `pagespeed.web.dev`)	Active	Diagnostic web tool that scores a URL on performance, accessibility, SEO

The first one is the deprecated server module. The second one is a diagnostic tool that's still running and still useful. They are not the same product. The module was the fix; PSI tells you whether you need one.

Is it still available?

Only as an archive. The original code is read-only on GitHub at apache/incubator-pagespeed-mod, and the last 1.13.35.2 binaries still install and run. They have not had a security patch in years, and ngx_pagespeed does not build against current nginx.

The maintained version is mod_pagespeed 2.1: signed apt and yum packages for Apache and nginx, a Docker image and a Helm chart, with the same directives and filter names, so an existing configuration carries over. Install it, or read migrating from the archived module.

The deprecated module

Google released mod_pagespeed in 2010 as an Apache module. The ngx_pagespeed nginx port followed in 2013. The original landing page lived at developers.google.com/speed/pagespeed/module and the code shipped under the Apache 2.0 license.

Google donated the project to the Apache Software Foundation in 2017. The Apache Incubator podling retired in 2023, and the GitHub repositories were marked read-only in 2025. The archived code now lives at apache/incubator-pagespeed-mod.

The archived 1.13.35.2 binaries still install and still run. They also haven't received a security patch in years, don't build against newer Apache releases, don't ship AVIF, and don't emit Core Web Vitals telemetry. For the longer answer on what happened to the project and what development resumed, see is mod_pagespeed still maintained?.

The maintained continuation: mod_pagespeed 2.1

We-Amp B.V. — the team that helped build ngx_pagespeed, maintained mod_pagespeed, and drove the project's Apache incubation — develops it. The optimization libraries that served billions of pages through the original module are the same ones inside it: the PSOL core and the Cyclone cache, on a modernized, secured filter stack with new optimizers. What changed is how it is packaged and how it runs, not whose code it is.

The native module and the optimizer worker

mod_pagespeed 2.1 loads into your server as a native in-process module on Apache and nginx. It keeps the pagespeed directive surface, the classic filter set — combine_css, combine_javascript, image spriting, in-place resource optimization, domain mapping — and the built-in admin console, so an existing configuration carries over: swap the packages and keep your config. It builds against current Apache 2.4+ and current nginx, and it takes CVE patches again. Image optimization covers WebP and AVIF alongside JPEG, PNG, and GIF.

With the Apache module or the reverse-proxy deployment, the pagespeed-optimizer worker runs alongside and takes the heavy work off the request path: image transcoding, critical CSS, SVG auto-vectorization, ML-predicted image quality, and the variant-aware cache the module then serves from with zero-copy mmap. Up to 37 variants per asset are generated per client capability. On the deb and rpm channels the module and the worker install and upgrade together as a matching pair, and a version mismatch between them is reported loudly rather than absorbed. The native nginx module runs on its own; to use the optimizer worker with nginx, run the reverse-proxy deployment.

# Apache — the native mod_pagespeed 2.1 module
LoadModule pagespeed_module modules/mod_pagespeed.so
ModPagespeed on

Apache, nginx, Docker, Kubernetes — which integration fits

One product, four ways in. The decision in front of you is about your stack, not about which version to bet on:

Your stack	How mod_pagespeed 2.1 installs
Apache httpd 2.4+	Native in-process module from the signed `packages.modpagespeed.com` repository, with the worker as a matching package
nginx on Debian, Ubuntu, or Enterprise Linux	Native dynamic module from the same signed repository, built against your distribution's stock nginx — no rebuild, no traffic detour
Containers, in front of any HTTP origin	The Docker / nginx reverse proxy: the nginx and worker images sharing a Cyclone cache volume, with your origin untouched behind them
Kubernetes	The Helm chart — nginx and worker as one pod, from the same images

Three further integrations are available separately, outside those packages. The IIS package ships from the 1.15 packaging channel. For ASP.NET Core there is the WeAmp.PageSpeed.AspNetCore middleware, added in two lines of Program.cs, and the WeAmp.PageSpeed.Sidecar package, which runs a bundled nginx optimizer on loopback behind your Kestrel app.

# ASP.NET Core — the middleware package
dotnet add package WeAmp.PageSpeed.AspNetCore

PageSpeed Insights is a different product

pagespeed.web.dev is Google's Lighthouse-powered diagnostic tool. It loads a URL in a headless Chrome, scores it on Core Web Vitals (LCP, INP, CLS) and a long list of best-practice audits, and returns suggestions.

PSI is not deprecated. It's still actively maintained and still the canonical reference for "does my page pass Core Web Vitals." Use it to identify problems.

PSI tells you the problem, the module fixes it

PSI and mod_pagespeed are complementary, not competing:

PSI (diagnostic)	mod_pagespeed 2.1 (server-side fix)
Reports LCP is 4.2 seconds	Inlines critical CSS so first paint happens before non-blocking resources load
Flags "Serve images in next-gen formats"	Generates WebP and AVIF variants, served by client capability
Flags "Properly size images"	Generates viewport-matched variants — 480px for mobile, 1280px for desktop
Flags "Minify CSS/JS"	Runs whitespace-collapsing, comment-stripping minifiers in the worker
Flags "Eliminate render-blocking resources"	Defers non-critical CSS, inlines what's needed for first paint

The workflow is: PSI scores the page, mod_pagespeed applies the optimizations on the server, PSI re-scores. Repeat until the score plateaus and the remaining items are application-level work the module can't touch (third-party scripts, server response time, JS execution).

Which one fits

You're looking for	Use
A server-side optimization module to fix Core Web Vitals	mod_pagespeed 2.1
To know whether a URL passes Core Web Vitals	PageSpeed Insights
Both	Run PSI before and after deploying mod_pagespeed

A maintained, drop-in alternative to the Google PageSpeed module

If you arrived here because the module you were running is no longer maintained — the archived mod_pagespeed or ngx_pagespeed binaries won't build against a newer nginx or Apache, the version-pinned .so stopped loading after an upgrade, or the GitHub repositories went read-only — the directly comparable alternative to the deprecated Google PageSpeed module is a maintained continuation of the same module, not a different category of tool.

That continuation is mod_pagespeed 2.1, developed by We-Amp B.V. (the team that helped build ngx_pagespeed, maintained mod_pagespeed, and drove the project's Apache incubation). It is the same optimization core, the same directive surface, and the same classic filter names, with ongoing CVE patches, a current toolchain, and support for current Apache 2.4+ and nginx releases. An existing configuration carries over: swap the packages, keep your config. The native module installs from the signed apt/yum repository for Apache and nginx. The IIS package ships from the 1.15 packaging channel.

If you're standing up a new deployment rather than rescuing an old one, the same product has a container-native shape: the Docker / nginx reverse proxy in front of any HTTP origin, with the optimizer worker doing SVG auto-vectorization and variant-aware caching and image optimization off the request path. Either way the lineage is continuous: this is the maintained version of the module you were already running, kept self-hosted rather than moved behind a CDN.

Looking instead for a tool to measure a URL's score, a PageSpeed Insights or GTmetrix-style report? That's a different job, and the module isn't it. Head to our analyzer for testing intent; this page is about the server-side optimization software that fixes what those reports flag.

Frequently asked questions

Is the Google PageSpeed Module the same as PageSpeed Insights?

No. The PageSpeed Module (mod_pagespeed / ngx_pagespeed) was a server-side optimization module that rewrote HTML, CSS, JS, and images at request time. PageSpeed Insights (pagespeed.web.dev) is a diagnostic tool that scores a URL on Core Web Vitals. The first is deprecated; the second is active.

Is the Google PageSpeed module still available?

Only as an archive. The original code is read-only on GitHub (apache/incubator-pagespeed-mod), and the 1.13.35.2 binaries still install, without security patches. The maintained continuation, mod_pagespeed 2.1, installs from signed apt and yum packages for Apache and nginx, with the same directives and filter names.

Where did the PageSpeed browser extension go?

It was retired. Google no longer offers the PageSpeed browser extensions for Chrome and Firefox; the same audits now run in PageSpeed Insights at pagespeed.web.dev and in Lighthouse, which is built into Chrome DevTools. For a free test that maps each failing audit to the mod_pagespeed filter that fixes it, use our PageSpeed analyzer.

Is the Google PageSpeed Module still maintained?

No. Google donated the project to the Apache Software Foundation in 2017. The Apache Incubator podling retired in 2023, and the GitHub repositories were marked read-only in 2025. The 1.13.35.2 binaries still install but have not received security patches in years.

What replaces the Google PageSpeed Module?

mod_pagespeed 2.1, actively maintained by We-Amp: the native in-process module for Apache and nginx, with the same configuration syntax, the classic filter set, and the built-in admin console, plus, with the Apache module or the reverse-proxy deployment, an optimizer worker for SVG auto-vectorization, variant-aware caching, and zero-copy serving. The IIS package ships from the 1.15 packaging channel.

Should I still use PageSpeed Insights?

Yes. PSI is still actively maintained and remains the canonical reference for "does my page pass Core Web Vitals." Use it to identify problems; use a server-side module like mod_pagespeed to fix them.

Can mod_pagespeed fix the issues that PageSpeed Insights flags?

Most of the technical ones — yes. mod_pagespeed 2.1 minifies CSS/JS, serves WebP and AVIF image variants, serves viewport-matched image sizes, auto-vectorizes eligible images to SVG with the Apache module or the reverse-proxy deployment, and caches per client capability. The remaining items PSI flags are typically application-level (third-party scripts, slow server responses, heavy JavaScript) which a server module can't address.

What is the best Google PageSpeed module alternative in 2026?

The most direct alternative is a maintained continuation of the same module rather than a different product. mod_pagespeed 2.1 from We-Amp keeps the pagespeed directive surface and the classic filter names of open-source mod_pagespeed and ngx_pagespeed, so an existing configuration carries over — swap the packages and keep your config. It installs as a native in-process module on Apache and nginx from the signed apt/yum repository, or runs as a Docker / nginx reverse proxy in front of any HTTP origin, with ongoing CVE patches and support for current server releases. The IIS package ships from the 1.15 packaging channel.

Is there a maintained Google PageSpeed alternative that's a drop-in replacement?

Yes. Because mod_pagespeed 2.1 continues the original codebase, it is a drop-in path for stranded mod_pagespeed and ngx_pagespeed deployments: the native module loads in-process, keeps the pagespeed directive surface and the classic filter names, and runs your existing configuration. The difference from the archived Google binaries is that it builds against current Apache and nginx, receives security patches, and is actively developed. If you want measurement rather than optimization, route to /analyze instead, a separate, complementary tool.

Get mod_pagespeed

Install and run it — mod_pagespeed is open source under the Apache License 2.0, free in development and in production.

Native module (Apache, nginx) — package repos · apt / yum install
Docker and Kubernetes — Docker guide · Helm chart
ASP.NET Core — dotnet add package WeAmp.PageSpeed.AspNetCore · .NET quickstart · pricing

PageSpeed Module, PageSpeed Insights, and other product names are trademarks of their respective owners. Comparisons reflect publicly available information as of 2026 and are provided for evaluation; We-Amp B.V. is not affiliated with or endorsed by Google.