Categories
Announcements Speed

Our Case for Retiring ModPagespeed Support

As part of our move to the “cloud” for our High-Performance customers (more details on that later) we’re retiring support for Google’s ModPagespeed/CynderHost Optitune. While we understand that for some users, this may seem like a poor decision, we’re explaining our rationale in hopes of clarifying things.

ModPagespeed

First off – what is ModPagespeed?

Initially developed for Apache, and later ported to NGINX, Pagespeed performs various site optimizations on the fly. Specifically, we use it for:

  • CSS and JS concatenation
  • CSS and JS modification, comment and whitespace stripping
  • Add HTTP/2 Push headers
  • Asynchronize AdSense and Google Analytics
  • Resize certain images to fit viewport size
  • Perform image compression

The initial aim of our implementation was to improve PSI scores of sites hosted on our network, as well as overall site performance.

Having said that, over the past year, we’ve gathers hundreds of thousands of data points, and come to the conclusion that deprecating Pagespeed is the better way forward towards faster websites.

Issue with Pagespeed

Pagespeed entails serval caveats:

  • Latency issues when combined with Brotli Compression levels exceeding 9 (Source)
  • Adds ~20 ms of latency whenever pages are loaded to account for HTML rewriting
  • Certain compatibility issues with various plugins
  • Use of a “Pagespeed Beacon” (which can be disabled) recommend for accurate image resizing statistics
  • A major hit to scalability of sites
  • Inconsistent optimizations when used with caching

Benefits of Pagespeed

While the optimizations above may seem important, most of them align with out-of-date or legacy deployments and standards.

  • Minification was initially used as the HTTP/1 protocol only allowed 5 concurrent file downloads, so loading multiple stylesheets/assets were inefficient. This was resolved in HTTP/2, which is supported by all major browsers, composing of roughly 97% of the browser market share.
  • Both AdSense and Analytics have been using asynchronous code loading for many, many years now.
  • HTTP/2 Push is a very infrequently used protocol with little tangible benefit, according to our own data, as well as data from Akamai.

From our data, the largest improvements reside in the reduction of page weight via image compression.

We found that the average page size was cut to ~80% of the un-optimized page size through the image optimization options we provided.

On paper, this seems significant. However, note:

  • As a tradeoff, Brotli levels 10+ can’t be enabled. Brotli lv. 10 provides significantly more efficient compression compared to 9 – this also impacts page weight, so when accounting for this, the difference is much less than a reduction to 80%.
  • Images aren’t optimized immediately – instead, they’re placed in a background queue the first time a page is loaded, and optimized in the background. The second time a page is requested, it’s rewritten to contain the optimized images. However, the first time a page is requested, it becomes stored in our caching layers. Subsequent requests are served directly to users, thereby never being passed to ModPagespeed and optimized. Because of this, we noticed only ~58% of requests were actually optimized.
  • Because of the way resizing is handled by Pagespeed, there were multiple different versions of every image being served. In turn, this resulted in lower CDN hits. While this is mitigated by intermediary caching layers, it’s a slight trade-off that further diminishes the actual performance. (This is also an issue with using srcset).

Ultimately, the minuscule benefits afforded by ModPagespeed weren’t worth keeping it. We also same no statistically significant difference in PSI scores during our A/B testing.

Therefore, we’ll be removing this component with our migration to cloud. We don’t expect any performance degradation, SEO impact, or noticeable PSI score impact because of this.

Instead, in accordance with best practices, we recommend storing pre-compressed versions of images. We recommend using reSmush.it, which will compress your media library on image upload. This allows for reduced disk space usage, consistent compressed image serving, and better scalability down the line.

As for the other optimizations previously provided by ModPagespeed

  • Script and style combining is largely unnecessary because of HTTP/2
  • HTTP/2 Push is also largely unnecessary, as some browsers have even considered removing support.
  • As long as you’re using a recent code snippet for GA and AdSense, they will be asynchronous by default
  • Any benefit afforded by minification will largely be counteracted by improved compression
  • Use proper srcset attributes to resize images dynamically for different screens.

If there are any questions or feedback, we’re available whenever you need us at support@cynderhost.com.

Leave a Reply

Your email address will not be published. Required fields are marked *