We ran this in production from its initial release over two years ago. Last month, we moved to a new datacenter and decided to forgo ngxpagespeed entirely.

The results have long been mixed - it does a great job minifying content and reducing requests, but the net results are highly questionable. While we reduced our network transfers and round-trips, the amount of time it took to serve requests was significantly increased to a point where the net gains were minimal. We played around with enabling and disabling the various filters and changing the settings and configurations to a great extent, and filed quite a few issues with the (ngx)pagespeed teams as we came across them.

If you do use this module, don't enable image recompression. It'll use up a lot of CPU, but worse, it'll also add significant latency to your requests. The caches on disk will always be full, and your disk IO will increase across the board. My personal favorite filter was the CSS merger which pulls various CSS resources into a single file. My favorite feature that always let me down was the "prioritize critical CSS" filter which (in theory) inlines CSS needed for above-the-fold content to display immediately. It never worked reliably for us, and broke our CSS more times than I can count. We always went back every few months to try it and always came away disappointed.

ngxpagespeed does not play well with caching (it must be enabled on the outer-most node) as it relies on realtime metrics collected via JS from served pages to make decisions about content, caching, inlining, and more. It also doesn't work well for SEO without significant manual tuning as it rewrites content URLs (I hear there is a way around this on Apache, but not on nginx) to pass back information to nginx, appending .pagespeed.xxxxx to your non-HTML URLs, including images that will be picked up by Google's bots. If you disable pagespeed later, all these will be broken. There's also no guarantee that these links will remain valid across pagespeed versions or if you enable/disable certain ngxpagespeed modules/filters, though I can't say I've been bitten by that (solution: you need to hack your nginx configuration to always include a Link...canonical header in your outgoing requests).

There are open issues galore regarding HTTPS and ngxpagespeed - it's an ongoing battle to make it play nicely with HTTPS upstreams for caching. It also basically proxies all requests made to your site back to your site once more so it can cache and optimize them, adding an entire roundtrip to initial or uncached requests. By default it won't cache HTML, so all HTML pages get proxied an extra time. There's an option to disable this for static resources by loading them from disk instead, but good luck getting that to play nicely with multiple upstreams and overlapping paths taking advantage of rewrite rules.

In the end, it just wasn't worth it for us. We've configured our webapp to pull in, minify, and inline its own (entire) CSS on first page load (about 20 lines of code w/ the Yahoo minify library doing the crunching), then configured nginx to reduce latency (http2, ssl_buffer_size, ssl session caching, smart keepalives, gzip, ssl_cipher optimizations (hint: bigger isn't better), proper expire headers, MTU optimization, etc) and the results have been better than what ngxpagespeed was giving us.

Sorry for how unstructured this comment is, I've been remembering stuff as I go along. By all means, ngxpagespeed is an awesome effort. As a primarily non-web developer, I think this is what browsers and http servers should do by default: act as a compiler of sorts for your content and find and implement optimizations where possible because your job isn't to figure out how to minimize network requests but rather to write code that works. However, it's the early days of "web compilers" and the intelligence and logic is far from being any good just yet. Just like 30 years ago no compiler could come close to even an average developer's hand-crafted (not even tuned!) assembly, that's how I see the state of "optimizing" proxies today. Give it another decade or two, I suppose :)