farblog

I don’t usually bother with meta-posts (because if I did, most of this blog’s content would be about how I’d made some trivial change to something pointless). However, this is slightly more interesting than the usual: I’ve switched this site to Google’s Page Speed Service, currently being offered on a free trial basis (note: “pricing will be made available later”, so it won’t be free forever).

In a nutshell, this means that www.farside.org.uk now resolves to a proxy inside Google’s CDN rather than my (somewhat less reliable) Apache server hanging off a slow pipe to the internets. This proxy acts both as a regular caching HTTP/1.1 proxy, fetching and forwarding content held on my server, and also transcodes the output using something similar to mod_pagespeed, reducing the latency of the requests even further (see the list of rewriters for more details).

The obvious question is: why bother? (after all, it’s not like this blog gets a ton of hits — especially with the two-year gap between this post and the last one). Well, mostly because it makes things more reliable (and also a little faster). Most of my output (such as it is) is on my Google+ profile now, but this site is still useful (for me, and hopefully for others) as a way to record things so that I can find them later, or just to write down original research. Moving into Google’s CDN means that not only do people geographically distant from my server get faster service, but also that nobody needs to be bothered about what happens if my server (or connection) goes down for a short while. And that’s good for everyone, me included.

How about the caveats? (other than the obvious one: that it’s not in open signup mode): sure, there are quite a few limitations documented at the Page Speed Service FAQ. The most notable of those is that because it relies on a CNAME DNS record, you can’t use it for bare domains (explanation here). Also, you have to be able to create a TXT record on the domain for verification (in my case, in addition to the A record I’ve already added for Google Apps domain verification, and the HTML file I’d already added for… some other Google property :-/).

Otherwise, first off, it’s a caching HTTP proxy. That may be notable if you’re not used to having a proxy in the request path: it means that you can’t force your way past the declared cache lifetime. Roughly speaking, if the caching headers at the source say that a certain resource is cacheable without revalidation for N minutes, the proxy is allowed to keep serving that cached version during that period, whatever type of request you make. This can be a pain when trying to make changes to a stylesheet (for example), and discover that some fool (that would be me) has set the stylesheets to be cacheable for a week, because, no matter what you do, the Google proxies will send you the old version.

However, this is also nothing special: HTTP’s caching headers describe exactly what behaviour User-Agents and proxies may follow; the difference is that — with the exception of mobile carrier proxies — it’s just not that common for there to be a proxy between me and my website.

Secondly, there are some visible changes to the default caching behaviour to be aware of. For example, it looks like some resources — scripts, for example — are cached by default for five minutes, if the reference server doesn’t provide any caching headers.

Finally, the proxy will probably behave differently at the HTTP level to your current HTTP server. For example, I noticed that HEAD requests no longer reliably indicate the Content-Length or Transfer-Encoding that will be sent on a GET — and also that the proxy uses a different set of rules to my local Apache in deciding whether a resource can be sent compressed (in particular, while Apache appears happy to deliver compressed application/atom+xml content to anyone, Google’s proxy will only do so for a subset of User-Agents).

None of this seems like a big deal. The best part, though? If something goes wrong (or if it turns out to be too expensive later), I haven’t lost anything: I just switch the CNAME back so that www.farside.org.uk points directly to my server again, and I’ll be back where I started.