Lighthouse 56 to 90.
On your own servers.
mod_pagespeed transcodes images to AVIF, minifies CSS and JS, and injects critical CSS — optimized off the request path, served from cache by your own nginx or Apache. Open source under the Apache License 2.0. No proxy, no CDN, nothing third-party in your request path.
Running IIS or ASP.NET Core? mod_pagespeed 1.15 covers you →
The optimization core behind 230,000+ live sites (BuiltWith, May 2026) — maintained by We-Amp, credited by Google as an ngx_pagespeed contributor.
56 → 90
Lighthouse performance score
1.8s → 0.8s
page load, cut in half
−76%
product image, JPEG → AVIF
0
third parties in the request path
Measured on our own demo stack — see it live.
Open source under the Apache License 2.0 — install and run it freely, in development and in production.
No per-image or per-request metering like a CDN. Support — and hardened builds — are what’s for sale. See support plans →
Built by We-Amp — the team that helped build ngx_pagespeed and maintains mod_pagespeed today.
mod_pagespeed 2.1 is developed by We-Amp B.V. and is not affiliated with or endorsed by Google. mod_pagespeed is an open-source project originally developed at Google.
$ curl -I https://example.com/
HTTP/2 200
content-type: text/html
content-length: 167824
cache-control: max-age=600
server: nginx
date: Sun, 17 May 2026 09:14:02 GMT
(no X-PageSpeed header)$ curl -I https://example.com/
HTTP/2 200
content-type: text/html
content-length: 53120
cache-control: max-age=600
server: nginx
date: Sun, 17 May 2026 09:14:08 GMT
x-pagespeed: HIT (mmap, <1ms)X-PageSpeed: HIT header confirms the response was served from the variant cache — not regenerated.
One product again. The module you know, plus the worker.
mod_pagespeed 2.1 converges the two lines We-Amp shipped through 2026: the native in-process module that stays compatible with your existing pagespeed.conf, and the optimizer worker that does the heavy optimization work outside the web server. Open source under the Apache License 2.0.
Pick by your stack
- nginx · Apache native module + worker → mod_pagespeed 2.1 (this page)
- IIS / Windows Server → mod_pagespeed 1.15 — supported until a converged Windows package ships, plus a transition window
- ASP.NET Core → the PageSpeed middleware (WeAmp.PageSpeed.AspNetCore) — supported until February 7, 2027
Every line shares the same optimization core; the converged module keeps the 1.14/1.15 directives, so existing configuration carries over.
mod_pagespeed 2.1
The converged line — open source under the Apache License 2.0
- ✓ Native in-process module — no proxy hop; drop-in for your pagespeed.conf
- ✓ Optimizer worker off the request path — ML quality + SSIMULACRA2 verification
- ✓ Classic filters: combine, sprite, IPRO, domain mapping
-
✓ Built-in
/pagespeed_admin/console - ✓ Serving straight from the variant-aware cache — no re-optimization on the request path
Previous lines
Supported through their transition windows
- mod_pagespeed 1.15 — security fixes only, with per-platform windows; IIS stays covered until a converged Windows package ships. The windows →
- ModPageSpeed 2.0 — feature-frozen; Docker/Helm and the ASP.NET Core middleware are supported until February 7, 2027. Migration guide →
Start here: docs & deep dives
The pages that answer the questions most readers arrive with.
Docs
Configuration
Configuration options for Apache and nginx: directives, cache modes, worker settings, and per-location overrides.
Read the docs
Docs
PageSpeed filters reference
Every rewrite filter and what it does: image transcoding, CSS and JS minification, combining, spriting, IPRO, and domain mapping.
Read the docs
Blog
Image optimization cost: self-hosted vs CDN (2026)
Cost comparison at 100K, 1M, and 10M monthly image requests — with break-even analysis against self-hosted optimization.
Read post
Blog
mod_pagespeed Alternatives in 2026
The original mod_pagespeed and ngx_pagespeed — developed at Google — are no longer actively developed. Here is where to go instead.
Read post
Install. Configure. Verify.
Three steps: add optimization to your server, set the options you want, and check the response headers.
1
Install
A native module for your existing web server.
apt install the signed mod-pagespeed (Apache) or nginx-module-pagespeed (nginx) — prebuilt, nothing to compile. The optimizer worker installs alongside as
pagespeed-optimizer.
2
Tell it what to optimize
Same configuration directives as open-source mod_pagespeed. Your existing
pagespeed.conf
carries over. Enable filters, set the cache path, done.
3
Check the response headers
curl -I your-site | grep X-Mod-Pagespeed. The version string confirms the module is active; the worker optimizes off the
request path and serves come from the cache.
The worker optimizes off the request path. The module serves from cache.
The module serves; the worker optimizes outside the request path. Both sides use the same proven PSOL optimization core.
Install in a few commands — pick your platform
# one-time: add the signed We-Amp package repo
$ curl -fsSL https://packages.modpagespeed.com/install.sh | sudo sh
$ sudo apt install nginx-module-pagespeed
# Add to nginx.conf: pagespeed on;
$ sudo nginx -t && sudo systemctl reload nginx
$ curl -I http://localhost/ | grep X-Mod-Pagespeed
X-Mod-Pagespeed: 1.15.0.0
On IIS / Windows Server? mod_pagespeed 1.15 covers you until a converged Windows package ships.
The optimization core behind 230,000+ live sites — now on your own servers.
One decode pass, up to 37 variants out
Automatic WebP and AVIF transcoding with viewport-aware resizing. Every variant is verified against the original with SSIMULACRA2 before it reaches the cache, using ML-predicted per-format quality. The optimizer worker can auto-vectorize eligible images to SVG. Content-aware compression adapts to photos, screenshots, and illustrations differently.
Render-blocking CSS eliminated
Heuristic-based critical CSS extraction and injection. CSS/JS minification. Early Hints (103) for preloading. No headless browser required. Optional browser pipeline for Lighthouse validation, waterfall capture, and visual comparison.
Cache hits are a pointer, not a pipeline
The Cyclone cache serves optimized content from a memory-mapped file — a hash lookup and a pointer, no re-optimization on the request path.
Self-hosted by design
Visitor data never leaves your origin, and nothing in the request path talks to us. Open source you can audit, running entirely on infrastructure you control.
Deliberately conservative
JS minification strips whitespace and comments only. No variable renaming, no AST transforms. The design falls back to the original when an optimization step fails.
The right bytes for every client
Per-URL cache variants tuned to each client — image format (AVIF / WebP / original), viewport size, pixel density, Save-Data, and pre-compressed encoding — so each request gets the smallest appropriate bytes off the cache.
The lineage
The optimization core behind 230,000+ live sites —
now maintained by We-Amp.
We-Amp's products are the maintained continuation of the open-source mod_pagespeed optimization core. These are not our customers — they are the proof the optimization core works at scale.
230,000+
live sites run mod_pagespeed today
1.9 million
sites across its history
Usage data: BuiltWith, May 2026 (231,341 live; 1,900,000+ historical).
We run every We-Amp site through it.
We run our own sites, this page included, through mod_pagespeed — the binary serving this page is the binary we ship. Same Cyclone cache. Check the response headers. On our own demo sites we measure up to 69% smaller pages.
Before it goes in front of production traffic.
The questions that come up on every evaluation call.
- mod_pagespeed is free. What does We-Amp sell?
- Support — and hardened builds. The original mod_pagespeed and ngx_pagespeed are no longer actively developed; mod_pagespeed 2.1 is the maintained, open-source (Apache-2.0) continuation — the same directives and filters, with security fixes and a current toolchain, plus a separate optimizer worker with variant-aware caching that serves optimized variants straight from cache and optimizes off the request path. The software is free; what We-Amp sells is support plans and hardened, attested builds from the people who build it.
- Does it add latency?
- No. On cache hit, serving is a hash lookup and an mmap pointer. On cache miss, the original content gets served while the worker optimizes in the background.
- Can it break my site?
- Transforms are deliberately conservative — JS minification strips whitespace and comments, no variable renaming — and the design falls back to your original content when an optimization step fails. Edge cases exist: test on staging, then disable any path, URL pattern, or transform type with one line of config.
- Why not just use Cloudflare?
- CDN-based optimization routes your traffic through a third-party proxy. mod_pagespeed runs on your servers — visitor data never leaves your origin, and nothing third-party sits in your request path.
- How is this different from a CDN optimizer (Cloudflare Mirage, Bunny Optimizer, Fastly IO)?
- Those rewrite assets at the edge, on infrastructure you don't control, with cache state you can't inspect. mod_pagespeed runs on your origin, so your rewrites carry your URLs, your headers, your cache policy. Use both — we optimize the origin, the CDN accelerates the delivery.
- How is this different from a build-time optimizer (Astro, Next.js Image, Vite plugins)?
- Those require a modern build pipeline you own end-to-end. We win when your build is owned by your CMS (WordPress, Magento, ASP.NET Framework) or your content is dynamic. If you already ship through a modern JS framework's asset pipeline, you may not need us.
Comparing against a CDN optimizer or a build-time pipeline? See the side-by-side comparisons →
Free to install and run. Start today.
Apache-2.0, on your own servers. No per-request fees. No bandwidth metering. Support — and hardened builds — from the people who build it are what’s for sale.
Apache-2.0 — free to install and run, in development and in production.