Here goes the analysis of Google's mod_pagespeed module.

Installation edit

The instructions are pretty straightforward. Because the experiment required a trunk version of the module, I had to build it myself instead of using a package. I used the configuration supplied by Google.

What it did in practice edit

I concentrated on mobile experience, hence this analysis is for MobileFrontend only. Here is the same page with and without mod_pagespeed (for bookkeeping, also with static copies):

The changes include:

  • 15kb of inlined and minified JS added to the page (both in <head> and at the bottom). The minification is more thorough than ours, it mangles all identifiers to 1-2 letters.
  • Most of content is removed, loaded later with JS.
  • People without JS are taken care for by the following in the <body>: <noscript><meta HTTP-EQUIV="refresh" content="0;url=''" /><style><!--table,div,span,font,p{display:none} --></style><div style="display:block">Please click <a href="">here</a> if you are not redirected within a few seconds.</div></noscript>. The message is briefly seen before a HTML-only version is loaded.
  • Some images are compressed, e.g. this JPEG is compressed from 9 to 6 kb.

Server-side performance impact edit

On the testing VM, this extension added ~100ms to cached request time.

Niceties edit

Page size is reduced tenfold, additional image reductions.

Problems edit

  • When I visited that page with Opera, I received a non-trimmed version of page content (though at least some other transformations were present), and no header to tell the frontend cache not to serve this content to other browsers (maybe it added a non-caching Cache-control in addition to the one we already output, but this doesn't make any difference in this situation), so this pretty much rules out any chances of using mod_pagespeed in out environment.
  • The handling of non-JS browsers is not transparent - furthermore, the URLs it redirects such users, like , are really hard to purge.

Conclusions edit

  • mod_pagespeed seems like a nice effort that auto-magically improves speed-related user experience.
  • It seems appropriate for small and medium-size sites, but not for our scale.
  • It is not compatible with our caching architecture.
  • We can adopt a lot of ideas from it:
    • More aggressive JS minification, using a third-party minifier
    • Better thumbs compression
    • Partial page views: while we played with per-section mobile reading, we haven't figured out how to do the HTML-only fallbacks cache-friendly.