Can SlickStack include the Google PageSpeed module for Nginx?

[sunwarior]

Can the following module be added to Nginx? Thanks. https://developers.google.com/speed/pagespeed/module

[jessuppi]

Hello @sunwarior and thanks for your suggestion. As far as I'm aware, the PageSpeed module has not really been maintained during the past few years, I see on their GitHub repo most of the commits are from 3-5 years ago:

https://github.com/apache/incubator-pagespeed-ngx

I've also always found it strange that the instructions pull code from a "private" URL, instead of the public repo:

https://www.modpagespeed.com/doc/build_ngx_pagespeed_from_source

Anyway back to the question, we've thought a lot about supporting Nginx modules in SlickStack, and I don't think it will be a priority at this point in our evolution. The reason is that it would require custom compiling of Nginx and modules, inevitably leading to a lot more problems, errors, and confusion... look at the complexity involved in this tutorial:

https://www.linuxbabe.com/nginx/compile-the-latest-nginx-with-ngx_pagespeed-module-on-ubuntu

Since one of our main objectives is maintaining a LEMP stack that is extremely easy and reliable, supporting Nginx modules would conflict directly with that goal. And I also expect that Nginx core features will continue to evolve faster than third party modules, too, meaning that updating Ubuntu/Debian packages is all that would be needed to stay ahead of the curve.

Plus, I've just never seen any good case studies showing that third party modules provide significant performance gains for the WordPress stack in general. I think security modules (.e.g. https://github.com/littlebizzy/slickstack/issues/74) are probably a more justifiable consideration than speed modules, but since many of those features are heading to "the edge" with proxy/CDN services like CloudFlare and WAF firewalls these days (which we encourage using), even those are questionable for SlickStack's purposes...

If you (or anyone) has further information please feel free to comment --

[activeyossi]

Was thinking to implement the page speed for its images modules to help compress and optimize images combined with Nginx. Seems like all image compression is blocked leaving the original images quite large (used imagmagick to compress manually)

[jessuppi]

@activeyossi As I tell people often, cropping images is 99% more effective than compression, which has become really a lazy man's attempt at automating the performance of images on their website.

The "quick fix" to image cropping is using a CDN that can automatically generate srcset source code:

https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images https://blog.cloudflare.com/announcing-cloudflare-image-resizing-simplifying-optimal-image-delivery/

CloudFlare Pro does this, for example. Personally, I have never relied on multiple image sizes, however, and generally use a single image of decent dimensions and load it responsively via CSS. If your image is already a decent size, then compression can be helpful for a bit more optimization, which your CDN should also do as well.

Relying on WP plugins for this is rather self-defeating: https://www.reddit.com/r/Wordpress/comments/ez7une/image_compression_plugins_are_a_bloated_pointless/

I usually will crop to a good size, and compress images prior to uploading them to WordPress using either Photoshop's "save for web" function and/or third party applications like TinyPNG, JPEGmini, etc.

And lastly, the PageSpeed module is poorly maintained and does not help if your images are not cropped to a good size, so it's just adding bloat to your stack to "feel good" without addressing the main issue, being cropping.

We will probably never support the PageSpeed module for these reasons, or any other Nginx modules. I don't want to assume users have a CDN, but PageSpeed doesn't help much anyways.