mod_pagespeed

1. It is an Apache module, so you can't use it with BOA/Nginx.

2. BOA already includes many mod_pagespeed-like improvements, either out of the box or with the help of recommended Drupal modules.

3. The (big) difference between Nginx and Apache is far more important than any extra benefits from mod_pagespeed.

See also:

http://drupal.org/project/wpo
http://drupal.org/project/bundlecache
http://drupal.org/project/advagg
http://drupal.org/project/css_emimage
http://drupal.org/project/imageapi_optimize
http://drupal.org/project/closure_compiler

re-opening this one, since http://ngxpagespeed.com/ngx_pagespeed_example/ is available

Also see
https://developers.google.com/speed/pagespeed/ngx

@attiks Thanks for the heads up!

there is an github repo for it.
https://github.com/pagespeed/ngx_pagespeed

Most of the front-end speed improvements promised by PageSpeed come from the too invasive to use them by default techniques like "Defer parsing JavaScript to reduce blocking of page rendering". Note that AdvAgg 7 already provides options to "Move JS to the footer" and "Add the defer tag to all script tags", but warns that this can easily break your site.

If you properly use AdvAgg and CDN with far future expiration option enabled, then you have already met all PageSpeed suggestions which are safe to apply, and the only left is "Defer parsing of JavaScript" - see our own D6 site results reported by PageSpeed Insights

Other things to consider:

1. PageSpeed moves all AdvAgg-like settings and features to the Nginx config level, so the site owner has no chance to configure anything, unless he can modify server level configuration or at least his site vhost, which is never the case in the Drupal multisite environment (so also in Aegir).

2. PageSpeed seems to be faster because no PHP backend is involved for optimization tasks, but PageSpeed still needs to get the content to parse from Drupal, so it improves things only on subsequent requests, never on the first (not cached) request, so it is similar to the imagecache-like AdvAgg behaviour.

3. Using Nginx to just serve cached static files generated/optimized by AdvAgg and Speed Booster is faster than rewriting/optimizing them on the fly. Yes, PageSpeed has its own cache, but it is used for resources only (images, css, js), and it optimizes HTML always on the fly! (and modifies cache related headers to make its tricks effective). It does have an option to use in-memory cache for metadata, to avoid disk based metadata cache.

4. Obviously, it further reduces your ability to control its behaviour, invalidate single cache entries etc, which is very handy when you develop on the theme level and you need to invalidate or only rebuild just a single aggregated bundle. You can't do that with PageSpeed.

5. PageSpeed doesn't read cached resources files from disk directly. Instead, it uses internal HTTP requests to fetch them, so it acts as a kind of extra web browser between visitor and the web server, which adds extra CPU usage. But since it never caches HTML (Speed Booster does that, thankfully), it will get extremelly busy under high traffic, optimizing HTML always on the fly, for each and every request.

Things to verify:

1. Does using PageSpeed on top of AdvAgg and CDN modules make any sense?
2. Will PageSpeed break things by rewriting cached files filenames and URLs?

Directive which may help to preserve Speed Booster and AdvAgg/CDN modules behaviour:

ModPagespeedModifyCachingHeaders off
More information: https://developers.google.com/speed/pagespeed/module/install#ModifyCachi...

Interesting discussions/resources:

https://groups.google.com/forum/#!msg/ngx-pagespeed-discuss/vzSq8XQPGmM/...
http://vpsboard.com/index.php?/topic/289-nginx-wordpress-php-fpm-fastcgi...
https://developers.google.com/speed/pagespeed/module/install#ModifyCachi...
https://developers.google.com/speed/pagespeed/module/system
http://blog.netdna.com/developer/nginx-performance-tips-with-the-google-...

But honestly, I see only minimal advantages and too many disadvantages, especially in the multisite (like Aegir) context.