johngirvin.com

Google recently launched mod_pagespeed, an add-on module for the Apache web server that automatically applies many web page loading speed optimisations. I’ve had a chance to trial mod_pagespeed on a Debian server, and this is what I found.

Installation was trivial as a pre-built binary package for Debian is available for download. One quick restart of the Apache process later and mod_pagespeed was operational.

The pagespeed module operates as a series of filters, modifying the content on-the-fly as it flows through the web server process to the end user. Filters broadly fall into the same categories as the Best Practices and can be enabled or disabled individually. As with any automated procedure, it’s possible the transforms will break existing code and Google freely admit this in the documentation, therefore only the “safest” filters are enabled by default.

It’s no magic bullet though. If you’ve done any work to optimise your web serving, or used the Page Speed or YSlow tools, then you will probably have already gained most of mod_pagespeed’s potential benefits. Compression, caching, image optimisation, minification and concatenation of external CSS and Javascript resources are all techniques commonly applied by webmasters concerned about their sites’ performance. However, the benefit of mod_pagespeed is that it automates these procedures and applies a few extras – such as stripping whitespace and comments – that are a pain to do otherwise.

A few further, more esoteric filters are available to help strip out those final few bytes. For example, removing quotes and redundant attributes from the markup. These are among the risker operations though, and the benefits are small in comparison.

On my own, low traffic sites, mod_pagespeed seems to work well enough. I have run in to a few niggles however.

The first thing to watch out for is that the default mod_pagespeed loading configuration (/etc/apache2/mods-enabled/pagespeed.load on Debian Lenny) automatically loads the mod_deflate gzip compression module as well, if it’s available. If you have mod_deflate disabled, for example if you’re running an application level cache that compresses content itself (such as WP_Super_Cache for WordPress), this unexpected activation can result in wasteful double compression and high CPU usage on your server.

Another detail to be aware of is that mod_pagepseed is a server wide change that will apply to all sites served by Apache. There’s no way to trial run it on one virtual host, for example, so caution and testing are advised (as with any configuration change to production servers!).

Server memory usage is the other main problem I’ve had. My VPS runs Apache in prefork mode, and mod_pagespeed increases the resident size of each Apache process by about 10Mb in my experience. With mod_pagepseed running my server has run out of memory a few times, something that had never happened before. It may be possible to resolve this problem by tuning module parameters but I need to investigate further.

Finally, URLs for resources generated by mod_pagespeed are complex and can contain some characters you don’t usually see. This caused problems for some of my sites that I had configured to only accept requests containing a restricted range of “safe” characters in the URL. The mod_pagespeed generated URLs are perfectly valid, so this was entirely my problem and not the module’s, but it’s still something to be aware of.

mod_pagespeed is a convenient tool for webmasters wishing to optimise their pages, especially those with a number of sites to maintain. A number of large web hosts are rolling out the module across their many thousands of client sites, for example, but this is as much work as rolling it out for one. The gains it realises are real, but will vary depending on content and how much work has already been done to optimise each site it affects.

The proof of this pudding is definitely in the eating, I recommend you (carefully) try mod_pagespeed for yourself.

Related Posts

No related posts.