Tag Archives: mod_pagespeed

While investigating a serious performance issue over the last 24 hours I discovered an issue whereby some of our CSS files were being combined but were not being rewritten by mod_pagespeed. After much hair pulling, far too many hours spent in front of curl, vim, less and friends, I finally tracked down the solution. I added a ModPagespeedLoadFromFile directive for every CDN domain and now all our resources are being properly rewritten.

I think, but I’m not sure, that mod_pagespeed tries to retrieve from the same domain as the request arrives on. So if you’re rewriting resources from example.tld onto cdn.xmpl.tld, when the request arrives at mod_pagespeed with a Host header of cdn.xmpl.tld, mod_pagespeed tries to look up every resource on the cdn.xmpl.tld hostname, instead of doing a reverse lookup through the ModPagespeedShardDomain directive.

Interestingly, this only seemed to affect our primary CSS file. Our print.css and javascript appeared to be unaffected. Strange. Very glad I can put this one to bed.

Here’s the slides (pdf) from the presentation last night. I’ve pulled out a couple of the more useful code sections below. Any questions, or if you want any links not in the slides, let me know in the comments.

The first line rewrites static resources via a custom origin CDN, the second shards those resources between 2 or more CDN hostnames. We have a CloudFront distribution setup on cdn1|2.dmn.tld that uses domain.tld as the origin. No other config required.

We’ve been running mod_pagespeed for a few weeks now. The results appear to be very positive in our tests. However, Google Analytics hasn’t shown any conclusive improvement in performance. When we compare mod_pagespeed against bare apache, page load times improve by around 1 second, but GA shows erratic results.

I think our traffic is too low for GA to get consistent results. We have set the page speed sample to the maximum 10%, but even then we’re not getting enough data to provide an accurate picture. That’s my guess. We’re running boomerang on all page loads, however, we’re still working on how to analyse the data to get useful statistics from it.

The stock mod_pagespeed install leaves out a couple of big improvements that are low risk. We tweaked the config by enabling the following filters:

We don’t have any data, but my feeling is that enabling the collapse_whitespace and remove_comments made a big difference. It reduced our HTML page size considerably, although the effect was offset by the inlining of smaller images. We also enabled the ModPagespeedLoadFromFile option to load our static assets directly from disk. Not sure how much difference it makes in practice, but it seemed like a low risk, sensible option.

We also used the ModPagespeedMapRewriteDomain and ModPagespeedShardDomain options to rewrite static requests onto a CDN. More about that in a later post.

Sysadmin friendly

The biggest advantage of mod_pagespeed from my perspective as the sysadmin was that it required zero changes to the application. That was a big win for us because it meant no code changes and no developer time. For example being able to combine, minify and CDN enable all our static assets with a couple of changes to the apache vhost config without a single code change was superb.

At first I thought mod_pagespeed had increased our time to first byte by around 200ms, but that turned out to be a myth. It’s hard to tell exactly, but it looks like it adds maybe 20ms to our time to first byte. That’s a very reasonable trade off for the advantages.

Conclusion

From a sysadmin perspective, mod_pagespeed is great. It applies across all the pieces of our application (we had to disable it for some with ModPagespeedDisallow). If I have time I’ll look into writing our own custom filters to insert things like boomerang, but that’s a longer term nice-to-have, not a core requirement.

Bottom line, after my initial scepticism, I can recommend mod_pagespeed if you want to easily reduce your roundtrips and CDNify your static assets at the server level rather than the application level. Big thanks to the mod_pagespeed developers who appear to be ultra responsive on the mailing list.

Following my last post about CloudFlare, I ran some further benchmarks in response to the feedback from their team. Here’s the summary:

CloudFlare only combines our Javascript, not our CSS files, despite what it said on the tin (the site has been updated, when we signed it said JS & CSS)

This only happens on some user agents on some operating systems, CloudFlare will not give me a list of user agents.

On browsers where this is enabled, we see a marked improvement, where it’s not, we see no gain or a small loss.

Graphs

I ran two sets of tests (using only browsers where RocketLoader is enabled).

Conclusion

We probably won’t implement CloudFlare across all our sites. I might still experiment on one of our higher traffic sites now that we’re running boomerang and gathering real user data to compare. However, the black box nature of CloudFlare fundamentally leaves me feeling uneasy.

The product appears to be in beta, which wasn’t clear when we signed up. I thought it was a polished product ready for production use. But much of the support chat is about RocketLoader being in beta, no list of user agents at this time, etc.