Google PageSpeed module configuration and review

[Makoto]

NOTE: This is a review post for the PageSpeed web server module, not for the actual PageSpeed service by Google

Now that ngx_pagespeed has improved a bit, and since I've seen a few members discussing the module recently, I've decided to give it another chance. I've spent several hours toying with the configuration and testing the results of various filters. Overall, I still don't find PageSpeed to be worth the hassle. There are a number of reasons for that.

The idea/concept behind PageSpeed sounds pretty nice.

It has filters that rewrite your forums HTML output. It can collapse whitespace, rewrite your CSS/Javascript and so on. These basic filters alone can shave around ~18KB off my forums board index. That sounds pretty good, right? Maybe, except that it doesn't even really matter when you factor in gzip compression.

Before PageSpeed,

Original Size: 197.76 KB
Compressed Size: 36.4 KB
Data Savings: 81.59%

After PageSpeed,

Original Size: 179.65 KB
Compressed Size: 35.94 KB
Data Savings: 79.99%

So in the end, those filters haven't even saved me a single kilobyte. (Granted, 200KB is still pretty bloat, this is just for demonstration purposes.)

The second major feature PageSpeed offers is the ability to rewrite images.

There are a number of reasons I don't like the concept behind this.

• Overhead. Having to rewrite all of your forums images on-the-fly is expensive. There are settings that help you mitigate the initial overhead of needing to rewrite all of your images on startup, but it's still an expensive task.
• Lossy. Converting all of your forums images to webp format on-the-fly when the users browser supports it can, in some cases, considerably reduce the file size of those said images. Even when the users browser does not support webp, it can still rewrite jpeg's and png's in a variety of ways. The trade-off here is that doing this is still lossy, sometimes very much so.
• Storage. You will have to store a cached copy of all converted images on your forum. If you're running your pagespeed cache on a tmpfs (as outlined further down), this can eat up a decent bit of your available memory, especially for moderate to large sized forums.

To provide an example, this is a comparison of a basic lossy jpeg background (used in the Carbon Blue template) before and after the WebP filter was applied to it,
JPEG (34.3KB) - WebP (5.3KB)
You will need to use either Chrome of Opera to view the WebP image

This is what I would consider an example of a bad lossy re-compression. The JPEG used was already pretty lossy. The WebP filter made it much more so, even if it did offer a notable reduction in file size. However, to be fair, really negative results like this don't seem to be common.

So here's a somewhat better example, showing the difference between a lossless PNG before and after.
PNG (800KB) - JPEG (120KB) - WebP (80KB)
Again, you will need either Chrome or Opera to view WebP images

WebP can (arguably) offer superior compression and quality to JPEG when used correctly. But even after explaining all of that, I really think WebP tries to solve a problem that doesn't exist. Even if WebP can offer superior results to JPEG as far as lossy compression goes, not only is it a technology that only Google Chrome and Opera support, but it's really not that big of a difference and you're still sacrificing quality for those results.

I'm against using PageSpeed for rewriting images in general. You lose quality and most people today have a fairly modern connection anyways. Shaving some kilobytes off your forums HTML output and photos will offer a negligible benefit for most people. It's better to simply learn how to make proper use of caching headers for your forums static content.

When using PageSpeed, all of your site's rewritten content has to be stored in a cache folder on your filesystem. If you're using a standard HDD and have a moderately active site, this might be a painful overhead. For optimal performance, I have PageSpeed's cache folder mounted with tmpfs.

tmpfs   /var/cache/nginx/pagespeed_cache/       tmpfs   rw,size=2G,noexec,nodev,nosuid,uid=nginx,gid=nginx,mode=0700 0 0

Lastly, you can find a good overview of PageSpeed's available filters here.

outline_css seems like it could be a rather nice filter, but not with the way it currently functions. My first impression on it was that it would externalize large blocks of inline CSS into cachable CSS files globally on the forum. It does not. Instead, you will have different externalized CSS files for every single page on your forum, making this filter almost completely useless. It will actually be determinantal to performance.

(For documentation purposes, this is the configuration used during testing. It's not perfect or properly tuned. I don't really recommend using it as is.)

    # Needs to exist and be writable by nginx.
    pagespeed CreateSharedMemoryMetadataCache "/var/cache/nginx/pagespeed_cache" 25600;
    pagespeed FileCachePath /var/cache/nginx/pagespeed_cache/;
    pagespeed MessageBufferSize 100000;
    pagespeed LoadFromFile "https://example.com/uploads" "/path/to/uploads/";
    pagespeed LoadFromFile "https://example.com/public" "/path/to/public/";
    pagespeed LoadFromFile "https://example.com/screenshots" "/path/to/screenshots/";
    pagespeed LoadFromFile "https://example.com/cache" "/path/to/cache/";
    pagespeed RewriteLevel PassThrough;
    pagespeed EnableFilters convert_png_to_jpeg,rewrite_images,strip_image_color_profile,strip_image_meta_data,recompress_jpeg,recompress_png,sprite_images,convert_jpeg_to_webp,combine_css,collapse_whitespace,lazyload_images,insert_dns_prefetch,local_storage_cache,convert_meta_tags,fallback_rewrite_css_urls,flatten_css_imports,inline_css,inline_import_to_link,inline_javascript,rewrite_css,rewrite_javascript,rewrite_style_attributes_with_url;
 
    # Fine Tuning
    pagespeed FileCacheSizeKb           512000;
    pagespeed FileCacheCleanIntervalMs  10800000;
    pagespeed LRUCacheKbPerProcess      4096;
    pagespeed LRUCacheByteLimit         24576;
    pagespeed UseNativeFetcher          on;
    resolver                            8.8.8.8;
 
    # Ensure requests for pagespeed optimized resources go to the pagespeed handler
    # and no extraneous headers get set.
    location ~ ".pagespeed.([a-z].)?[a-z]{2}.[^.]{10}.[^.]+" {
      add_header "" "";
    }
    location ~ "^/ngx_pagespeed_static/" { }
    location ~ "^/ngx_pagespeed_beacon$" { }
    location /ngx_pagespeed_statistics { allow 127.0.0.1; deny all; }
    location /ngx_pagespeed_message { allow 127.0.0.1; deny all; }

So again, all in all, I'm not really a big fan of PageSpeed. Ensuring optimal server performance and reducing latency (which is the goal behind SPDY and QUIC) are really the best ways to improve your forum load times.

[Dmacleo]

I did see a gain in time to first byte using it but also think the gains are offset by needing the extra space for progressive images and etc. it really seemed to be a wash and just tuning nginx compression levels/etc was simpler and more useful.

[maddog107_merged]

thanks for the writeup, was looking into this

[Dmacleo]

disregard posted in error, sorry