Living with mod_pagespeed

A few weeks ago we implemented mod_pagespeed on a couple of websites to automate some speed optimisation techniques. At the time it seemed like a no brainer to roll it out onto a few of our servers and speed up a large number of our clients’ websites.

I thought the new module would be something we could install and forget about, but it hasn’t been so problem free.

Things Break

Google’s mod_pagespeed has a library of filters that do some weird and wonderful things to a website and when first setting up mod_pagespeed there are three configuration levels to make things simple.

• PassThrough – Essentially a do nothing setting
• CoreFilters – Enables around 14 filters, some which may break a part of your website
• OptimizeForBandWidth – Doesn’t really enable any filters, but does some cleanup without altering filenames which many filters can do

At Bronco we enabled the Corefilters options and sure enough in the intervening weeks we’ve discovered issues on websites caused by one or more of these filters. In most cases the solution has been to determine the problematic filter and disable it within the .htaccess file or on other occasions we’ve just switched off mod_pagespeed for that specific website; this has mostly been a “I don’t have time to figure this out right now” solution.

In retrospect enabling the OptimizeForBandwith may have been the best option but we’ve experienced very few breakages compared to the number of websites we host and of those problems none have been critical to the running of the website.

Development Challenges

Building and editing websites with mod_pagespeed has been a little more challenging for the development team, in fact it’s a bit of a pain in the backside compared to how things were before. The problems we’ve experienced all centre on mod_pagespeed caching much of the website.

To start if we’re making changes to any website where mod_pagespeed is running on the server we have to switch off the module via the .htaccess file, remembering to turn it back on again after we’ve finished with any changes. This is so if we have to make and test multiple changes we can do so without the module getting in the way.

But even when we switch the module back on it won’t refresh the cache with the changed files, instead it will revert to the files already stored within its cache which really isn’t helpful. It’s similar to the way a browser will cache files and in that situation we often have to ask clients to clear their cache before attempting to view changes.

The problem with mod_pagespeed is it’s not as easy to clear its cache, you need to do it through the command line and to be honest you’ll not find me going anywhere near command line on a server for fear of killing all the websites on the server.

Instead we rely on a technique of renaming the file so that mod_pagespeed thinks we’ve actually changed the file we’re using. The technique also works for clearing browser caches when the client may not know how to clear their own cache.

While renaming the actual file itself is one way to do this it’s far easier to use a querystring instead. So on a regular website you might find the following code:

<link rel="stylesheet" href="/inc/css/screen.css">
<script src="/inc/js/jsOnload.js"></script>

And to fool mod_pagespeed and a browser into thinking the files are different we add a simple querystring to the end of the filename:

<link rel="stylesheet" href="/inc/css/screen.css?v=2">
<script src="/inc/js/jsOnload.js?v=2"></script>

Simple. But updating multiple version numbers of multiple files throughout a website can be something of a hassle. So with PHP we can create a single variable and append this to our file references.

<?php
$version = 2
?>
<link rel="stylesheet" href="/inc/css/screen.css?v=<?=$version?>">
<script src="/inc/js/jsOnload.js?v=<?=$version?>"></script>

Now we only have to update one number in one line of code, located somewhere we can easily access and we only need to do this at the point we turn mod_pagespeed back on.

Mod_pagespeed: A good thing?

So implementing mod_pagespeed can break websites and it can add extra overhead to the development process but if developers only did what was quickest and easiest for us then the web would be massively overbloated and unusable for huge numbers of people.

Of course it’s a bit of a pain at the start and you have to get your team up to speed on the impact mod_pagespeed will have on the development process but I do think the advantages outweigh the problems.

That being said mod_pagespeed won’t be the ideal solution in all situations. We possibly jumped in a little quicker than is prudent and other companies will have to research and test more than we have but I’d definitely recommend developers and server administrators take a look and see if the benefits outweigh the issues in your situation.