Google PageSpeed for NGINX: What It Was, Why It Died, and What to Use Instead

So Your Website Is Slow. Google Says It’s Your Fault.

Picture this. You’ve just launched your website. You’re proud of it. Then Google’s PageSpeed Insights tool opens up, takes one look at your page, and gives you a score of 43. In red. With seventeen recommendations, each more confusing than the last.

“Minify your JavaScript.” Sure. “Defer offscreen images.” Right. “Eliminate render-blocking resources.” Absolutely, let me just… what does that even mean?

For years, one tool promised to handle all of this automatically, on the server, without you touching a single line of code. It was called PageSpeed — and for a glorious decade, it was basically witchcraft.

Then Google abandoned it. And now here we are.

This post is the full story: what Google PageSpeed for NGINX was, what it actually did to your server, why it’s effectively dead in the modern stack, and — most importantly — what you should do instead.

---

What Is Google PageSpeed? (The ELI5 Version)

Let’s start at the beginning, because there’s actually a confusion baked into the name. “PageSpeed” means two different things and people mix them up constantly:

• Google PageSpeed Insights — the website at pagespeed.web.dev that scores your page and gives you a list of things to fix. This is a measurement tool. It’s still alive and well.
• mod_pagespeed / ngx_pagespeed — actual server modules for Apache and NGINX that automatically apply those optimizations at the server level. This is the one that’s dying. This is what we’re talking about today.

Think of it this way. PageSpeed Insights is the doctor who tells you “you need to eat better and exercise more.” The PageSpeed module is the robot butler who quietly prepared your meals and sneaked your car keys away before you could drive to McDonald’s. Very different things.

Google launched the server module in 2010 for Apache, then released ngx_pagespeed for NGINX in 2012. The premise was deceptively simple: what if the web server could automatically make your site faster, with zero changes to your code?

---

What PageSpeed Actually Did to Your Website

When a visitor requested a page from a NGINX server running ngx_pagespeed, the module intercepted the response before it hit the wire and applied a battery of optimizations. Automatically. In real time. Here’s what it was doing behind the scenes:

Minification

Your CSS and JavaScript files are full of spaces, line breaks, and comments written for humans. Computers don’t need any of that. PageSpeed stripped all of it out on the fly. A 120 KB stylesheet could shrink to 80 KB with zero change in behaviour. Free speed, every request.

Image Optimisation

You uploaded a 3 MB product photo from your DSLR. Your visitors are on mobile phones. PageSpeed detected the browser, converted the image to WebP (the modern, smaller format), resized it to fit the screen, and served the smaller version. Your visitors had no idea. Their pages just loaded faster.

Resource Inlining

Small CSS files (the kind that control your page header) cause an extra network round trip when loaded separately. PageSpeed embedded them directly into the HTML page. One fewer request. Faster first paint.

Cache Fingerprinting

When PageSpeed optimised an asset, it renamed it with a content hash: style.css became style.css.pagespeed.cf.abc123.css. This hash changed whenever the file changed, which meant browsers could cache assets forever without worrying about stale copies. Instant cache strategy, zero configuration.

Lazy Loading

Images below the fold (the part of the page you see after scrolling down) were loaded only when the user actually scrolled to them. No point downloading 20 images when the visitor only reads the top three paragraphs and leaves.

Pre-compression

PageSpeed pre-compressed assets so the web server could serve them directly without compressing on-the-fly for every request. Pairs nicely with the zstd-nginx-module we maintain for modern compression on NGINX and Angie today.

In short: PageSpeed was doing in milliseconds what a frontend developer would spend a week setting up in a proper build pipeline. It was remarkable engineering.

---

The Glory Years: 2012–2018

From 2012 to roughly 2018, ngx_pagespeed was the power move in NGINX deployments. Everyone was installing it. Blog posts were written about it. Sysadmins bragged about their PageSpeed scores in the same tone other people brag about their gym numbers.

The appeal was irresistible:

• NGINX was already faster than Apache (free win)
• PageSpeed made it perform like a mini-CDN (double win)
• You controlled your own server (no Cloudflare lock-in)
• It was completely free
• Configuration was optional — it worked out of the box

For a small shop or a solo developer who didn’t have a CDN budget or a webpack setup, PageSpeed was transformative. Your slow WordPress site suddenly felt fast. Clients were happy. Life was good.

---

Then the Cracks Appeared (2018–2021)

Nothing good lasts forever, especially when Google is involved.

Around 2018, things started getting wobbly. Not dramatically. Slowly. The way a wheel bearing fails — it’s fine, it’s fine, it’s fine, and then suddenly it’s very much not fine.

The Competition Caught Up

Cloudflare launched Auto Minify, Rocket Loader, and image optimisation. All of it point-and-click in a dashboard. No server modules to compile. No configuration files to read. Just toggle a switch. For most sites, that was enough.

Build tools matured too. Webpack, then Parcel, then Vite arrived and did PageSpeed’s job at build time instead of runtime. Doing it at build time is strictly better — it happens once, not on every request, and you get full control over the result.

HTTP/2 Made Some Tricks Obsolete

PageSpeed used a trick called domain sharding — splitting assets across multiple subdomains so browsers could download them in parallel (old browsers limited connections per domain). HTTP/2 made this completely unnecessary by multiplexing everything over a single connection. PageSpeed’s domain sharding actually hurt performance on HTTP/2 sites.

Core Web Vitals Changed the Goalposts

Google replaced their old performance metrics with Core Web Vitals: LCP (Largest Contentful Paint), FID (First Input Delay), and CLS (Cumulative Layout Shift). PageSpeed’s optimisations were designed for the old metrics. Minifying CSS doesn’t directly improve LCP. Inlining small files can actually cause CLS if done carelessly. The magic formula stopped adding up.

PageSpeed Got Weird and Buggy

The module started producing mysterious bugs. Image optimisation broke on certain formats. Inlined CSS caused flash-of-unstyled-content (FOUC) — that jarring flicker where your page briefly shows unstyled content before the CSS kicks in. Debugging was a nightmare because PageSpeed’s error logs were about as helpful as a “something went wrong” toast notification.

---

How Google Quietly Ghosted ngx_pagespeed (2020–2022)

In 2020, Google quietly handed off PageSpeed maintenance. “Community-maintained” is corporate speak for “we stopped paying people to work on this.”

By 2021 it was official: no more active development, no more security patches, no more new features. The project wasn’t formally declared dead — it was just… left alone. Like a houseplant someone forgot to water.

Why did Google do this? Because Google built Google Cloud. And Cloudflare, Fastly, and Akamai had already proven that CDNs were the right answer to the performance problem. The right answer was “use a CDN”, not “install a complex server module and hope it doesn’t break.”

There’s a certain irony here: Google spent a decade telling everyone to make their websites faster, built the module that helped them do it, and then essentially said “actually, just pay for a CDN.” Classic Google.

---

What This Means for NGINX and Angie Today

Here’s the practical situation if you run NGINX or Angie on Debian or Ubuntu:

• ngx_pagespeed is no longer compatible with modern NGINX versions. The module was written against older NGINX internals. Newer NGINX versions have changed APIs that ngx_pagespeed relies on.
• No security patches. Any vulnerability found in ngx_pagespeed today will not be fixed upstream. You’re on your own.
• Angie never included it. Angie, the actively maintained NGINX fork, never picked up ngx_pagespeed. It’s not going to start now.
• Our position at deb.myguard.nl: when PageSpeed breaks with a NGINX upgrade, it comes out of the stack. No backports. No maintenance. It’s already effectively gone from the Angie packages.

That said — the documentation for PageSpeed still lives at pagespeed.myguard.nl. If you’re maintaining a legacy server that still runs it, that’s where to look. We keep the docs alive because we’re not monsters. But we’re not writing new ones either.

---

What to Use Instead of PageSpeed (Modern Alternatives)

Good news: the alternatives are better. Not “cheaper” or “similar”. Actually better. Here’s how to think about replacing what PageSpeed was doing.

For Compression — Use zstd or Brotli on NGINX

PageSpeed’s pre-compression is now better handled directly by NGINX using modern algorithms. We maintain both a zstd compression module (faster than gzip, comparable ratios) and Brotli support in our packages. No PageSpeed needed. See the full NGINX performance guide for the config.

For Image Optimisation — Optimise Before Upload

The modern answer is: don’t optimise at request time, optimise at upload time. Tools like Squoosh, ImageMagick, or a CDN with image transformation (Cloudflare Images, Bunny.net Optimizer) handle this better than PageSpeed ever did. WordPress users: the EWWW Image Optimizer or ShortPixel plugins do this automatically on upload.

For Minification — Build Tools or a CDN

If you control your code: use Vite, esbuild, or Webpack to minify CSS and JS at build time. It happens once, the result is stored as a static file, and your server just serves that file. No per-request overhead whatsoever.

If you’re running WordPress or a CMS where you don’t control the build: a CDN like Cloudflare can do minification at the edge. Enable Auto Minify in the Cloudflare dashboard. Done.

For Caching — NGINX FastCGI Cache

PageSpeed cached its optimised assets on disk. NGINX’s built-in FastCGI cache does the same for entire pages, and it’s dramatically simpler and more predictable. Covered in detail in our NGINX optimisation guide.

For Everything at Once — A CDN

The honest answer for most sites is: put Cloudflare (free tier is fine for most cases) in front of your server and enable their performance features. Minification, image optimisation, caching, HTTP/3, DDoS protection — all of it, managed for you, at no extra cost beyond their base plan. PageSpeed was a single-server CDN emulator. Use an actual CDN.

---

Should You Remove PageSpeed If You Still Have It Running?

Depends on your situation. Here’s a honest decision guide:

Remove it now if…

• You’re on a modern NGINX version (1.24+). It likely doesn’t compile cleanly anyway.
• You’re migrating to Angie. Angie doesn’t have it and never will.
• You’re seeing weird bugs — image corruption, FOUC, mysterious cache issues. That’s PageSpeed.
• You use a CDN. There’s zero reason to run both.

Leave it alone if…

• It’s working and your server is frozen (no NGINX upgrades planned).
• You’re maintaining a legacy site that isn’t worth refactoring.
• You tested removing it and your scores dropped (measure first, then decide).

If you do remove it: replace the compression with zstd or Brotli, set up proper cache headers, and consider a CDN. Your site will likely perform better, not worse.

---

A Brief Moment of Appreciation

Before we close the coffin, let’s give PageSpeed its due.

In 2010, the average webpage was 700 KB and loaded in 8 seconds on a decent connection. PageSpeed was one of the tools that forced the industry to take performance seriously. It proved that server-side optimisation was possible and practical. It inspired the build tools, CDN features, and browser APIs that replaced it.

The fact that it’s now obsolete isn’t a failure. It means the problems it was solving have been solved properly. That’s a win.

Rest in peace, ngx_pagespeed. You were a magnificent hack, and we mean that as a compliment.

---

Frequently Asked Questions

---

Related Posts

If you’re here because your site needs to go faster, these posts are the next logical steps:

• How to Optimize NGINX and Angie for Maximum Performance and Security — The complete modern replacement for what PageSpeed was doing. TLS tuning, HTTP/3, zstd compression, FastCGI caching, ModSecurity — all of it explained from scratch.
• zstd-nginx-module: What It Does and How We Fixed 22 Bugs in It — The modern compression story. zstd is faster than gzip and better than PageSpeed’s old pre-compression approach.
• Migrating from NGINX to Angie: The Laziest Upgrade You’ll Ever Do — If PageSpeed is the reason you’ve been stuck on an old NGINX, this is how you move forward without it.
• openssl-nginx: A Dedicated OpenSSL Build for NGINX and Angie — While you’re modernising your stack, give NGINX its own tuned OpenSSL. It’s one of the simplest performance wins available.

---

PageSpeed documentation archive: pagespeed.myguard.nl. The rest of the myguard packages — including the compression modules, optimised OpenSSL, and ModSecurity builds that replace what PageSpeed used to do — are at deb.myguard.nl.