Is the PageSpeed module still maintained?

No. Google retired both mod_pagespeed and ngx_pagespeed. The project is no longer receiving updates from upstream. The documentation on this site is preserved for existing deployments still running it.

Should I install PageSpeed on a new site?

No. Use modern alternatives: NGINX's native modules, image/CSS/JS minification at build time, brotli or zstd compression, and HTTP/2 or HTTP/3. The MyGuard NGINX project ships many of these natively.

What does the PageSpeed module actually do?

It rewrites HTML, CSS, JavaScript and images on the fly to apply web-performance best practices: inlining critical CSS, lazy-loading images, combining and minifying assets, cache-extending static files and converting images to modern formats like WebP.

Where can I download the PSOL library?

Prebuilt PSOL binaries are no longer published by Google. MyGuard maintains a build script at https://github.com/eilandert/build_psol that compiles PSOL from source for current Linux distributions.

Will MyGuard keep these docs online forever?

The aim is to keep PageSpeed documentation reachable for as long as it is useful to administrators with existing deployments. We do not guarantee perpetual availability.

mod_pagespeed & ngx_pagespeed Documentation

Heads up: The PageSpeed module is no longer being developed upstream. If you have not deployed it yet, do not start now — use NGINX's native modules, build-time asset pipelines and modern compression (brotli, zstd) instead. For context, alternatives and the full backstory of the project's retirement, read our deep-dive: Google PageSpeed for NGINX: What It Was & Alternatives →

About this mirror: This documentation site is part of the MyGuard NGINX project. The goal is to keep the PageSpeed module documentation reachable for administrators who still run it in production. Source repositories (mod_pagespeed, ngx_pagespeed) remain archived on GitHub.

What is the PageSpeed module?

The PageSpeed module — shipped as mod_pagespeed for Apache HTTPD and ngx_pagespeed for NGINX — was Google's automatic web-performance optimiser. Once loaded into the webserver, it intercepted HTML, CSS, JavaScript and image responses and applied a configurable pipeline of filters: minifying code, combining stylesheets, inlining critical CSS, lazy-loading offscreen images, recompressing PNG/JPEG files into WebP, and cache-extending static assets behind hashed URLs. All of it happened at the edge with zero changes to the underlying application.

Under the hood the heavy lifting was done by the PageSpeed Optimization Library (PSOL), a C++ library shared between the Apache and NGINX builds. Google discontinued public PSOL binaries; if you build from source today, use eilandert/build_psol, which keeps the build recipe alive against current distributions.

Documentation

Get started

The full filter reference, configuration syntax and build guides — everything from the original Apache documentation set.

Documentation index Configuring filters Release notes

Build & install

Compile mod_pagespeed or ngx_pagespeed from source, including the PSOL library.

Build from source NGINX build guide Apache build guide

Popular filters

PageSpeed shipped with dozens of filters. The most common in production deployments:

Prioritize critical CSS

Insert Google Analytics

See the complete filter list for the full set including image spriting, local-storage caching, AdSense / GA async rewrites and the experimental modules.

Modern alternatives

Most of what PageSpeed automated can now be done better elsewhere in the stack:

Compression: brotli and zstd at the NGINX layer outperform PageSpeed's text rewrites (see our compression deep-dive).
Image optimisation: build-time WebP/AVIF conversion with cwebp or avifenc beats on-the-fly conversion every time.
Critical CSS & JS bundling: handled by modern bundlers (Vite, esbuild, Rollup).
Cache-busting: use hashed filenames from your build tool plus long Cache-Control: immutable.
HTTP/2 and HTTP/3: remove the historical motivation for resource combining filters entirely.

For the full story — why PageSpeed mattered, why it was retired and what each filter's modern replacement looks like — read Google PageSpeed for NGINX: What It Was & Alternatives on the MyGuard blog.

Frequently Asked Questions

Is the PageSpeed module still maintained?: No. Google retired both mod_pagespeed and ngx_pagespeed. The repositories are archived on GitHub. No further releases or security fixes are coming from upstream. This documentation site is a community mirror for existing deployments.
Should I install PageSpeed on a new site?: No. For new deployments, use modern alternatives: NGINX's built-in compression (zstd/brotli/gzip), build-time asset pipelines, HTTP/2 push hints, preload/preconnect link headers and image build steps. See the alternatives section above.
What is PSOL and where do I get it?: PSOL — the PageSpeed Optimization Library — is the shared C++ engine that both the Apache and NGINX modules link against. Google stopped distributing PSOL binaries when the project was retired. Build it from source with eilandert/build_psol.
Does PageSpeed work with HTTPS, HTTP/2 and HTTP/3?: HTTPS, yes — see HTTPS support. HTTP/2 works as the transport, but many PageSpeed filters (resource combining, domain sharding) were designed for HTTP/1.1 and bring no benefit — or are actively counterproductive — over multiplexed protocols. HTTP/3 is unaffected; PageSpeed sits above the transport layer.
Where can I get support?: The original mailing lists are read-only. For configuration help with the MyGuard NGINX packages, open an issue on the relevant GitHub repository. For PageSpeed-specific questions, your best bet is searching existing archived issues at the mod_pagespeed and ngx_pagespeed repositories.
Why does www.modpagespeed.com not work anymore?: It was a live demo site running mod_pagespeed against curated example pages. When the project was retired the demo went offline. We rewrote the demo links in this archive to point at the local documentation for the corresponding filter instead.