On Page Speed Service
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; signup here).
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
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.
Posted at 21:18:15 BST on 31st July 2011.