The team behind ModPageSpeed.

mod_pagespeed was an open-source server-side optimization framework originally built and released by Google in 2010. The original team — Joshua Marantz, Jeff Kaufman, Maks Orlovich, Bryan McQuade and others — shipped an Apache module that did things the rest of the web hadn't figured out yet: server-side image transcoding, critical-CSS inlining, cache-extension, JS minification, dozens of transforms across a content pipeline that thousands of operators put in front of production traffic.

It set the standard. It's no longer actively developed upstream — Google retired the project in 2020. The optimization libraries from the original mod_pagespeed are the foundation of 2.0. The architecture around them is new: a separate worker process, a modern cache layer, async pipelines, C++23 throughout. But the rewriters that decide how to compress an image or rewrite a stylesheet are the ones the original team built and proved.

Different era, not a better team.

The optimization work is theirs. What 2.0 adds is a runtime built for the 2026 web.

We-Amp B.V. is a Dutch private limited company, registered at the KvK under 57898138, founded in Castricum in 2012. The specialty has always been web performance: image optimization, content rewriting, cache architecture, the boring infrastructure that decides whether a page is fast or slow.

Today this is one engineer. Otto van der Schaaf, who maintained mod_pagespeed at Google before starting We-Amp, and has shipped optimization code continuously since 2010 — including across Apache, nginx, Envoy and IIS ports of the 1.x line. Two active products (2.0 and 1.1), one shared optimization core, one Cyclone Cache library underneath both.

One engineer can ship a focused product, answer support email the same day, and keep the codebase legible. It cannot answer a Slack channel at 2 a.m. or attend twelve customer QBRs in a quarter. Self-hosted software is the model that matches the team size: you run the binary on your infrastructure, you control the upgrade timing, we don't sit in your request path.

There are two places AI shows up around this product. Both worth naming.

Inside the binary: small LightGBM models — one per format, JPEG, WebP, AVIF — predict the encoder quality that hits a target SSIMULACRA2 perceptual score. Compiled to C through TL2cgen, around five microseconds per call. No model downloads, no runtime dependency, no outbound call in the request path. Every variant is verified against the original with SSIMULACRA2 before it reaches your cache. Don't want it? --no-learned-quality-jpeg, --no-learned-quality-webp, --no-learned-quality-avif. Per format.

Outside the binary: a one-engineer shop runs at all because agents watch security advisories, performance research and upstream changes, and brief the engineer. The engineer approves before anything user-visible ships. Human in the loop is not a marketing phrase here — it's the only path to a release.

Inference compiled in. Approval kept human.

The 2026 web is HTTP/2 and HTTP/3, container orchestration, nginx in front of nearly everything, AVIF in every browser worth optimizing for. The performance story is no longer "the network is slow" — it's "your origin is doing too much work and shipping too many bytes." Server-side optimization should live next to your origin, not in someone else's data center two hops away.

ModPageSpeed 2.0 reflects that reality. It runs as an nginx interceptor plus a worker process, talks to your origin over a local socket, and never phones home with request data. There is no third-party proxy in the path. There is no CDN dependency. The license server you talk to once a day for token renewal is the only external contact, and that's documented and bypassable on air-gapped installs.

Operators in 2026 have absorbed the trade-offs of edge platforms and managed services, and a growing number want some things back on their own boxes. 2.0 runs there.