Something that's become a bit of a strange obsession of mine recently is site optimization for speed. I've worked on a few web projects in the past few years and one of the main things that I've learned is that performance is as important as functionality. It's easy to build a site that works and then declare the job done - far more difficult to make it perform and scale properly. I tend to use this site as a bit of a sandbox for experimenting with what works and what doesn't. Which is probably why bits of it are broken a lot of the time.

There's a whole bunch of different things that can be done, some of which are worth doing, and others aren't. Some also take up a lot of effort, others less so. The easy stuff is what most people know - compression and caching lifetime. If you get these right, you're probably most of the way there to getting good performance out of a particular codebase. For image compression, one of the most important things I found was that image quality isn't half as important as a lot of people think. When I was building the images for this site, I was trying to make them look as good as possible. These images are just pointers! Navigational aids that make the site more pleasant to use. No-one's going to spend more than a couple of seconds looking at them, so no-one's going to care that there's a slight bit of dithering on the blue in a particular area. Realising that, I managed to cut the size of one of the sprites from 70KB down to about 20KB. Doing that sort of thing everywhere can add to up to a big saving.

For text compression, there's a number of approaches. Webservers and browsers have supported gzip for quite a while now, and it's remarkably effective. Yahoo think that gzip reduces the size of web content by 70% can be used by 90% of the browsers out there. Good stuff. But on top of that, there's more. I use a nice app called Minify that can take a collection of javascript or CSS files and serve them up over a single request. You take a hit on the first request, as the php concatenates the files and strips out anything unnecessary, but it gets cached on the server side after that. Yahoo again reckon that minifying before gzip'ing can save another 5% on size. It's also less work for the webserver and browser to do, as the uncompressed data is smaller.

On top of that, there's a couple of extra things that can be done. If there's a lot of images, serve them from multiple subdomains. The browser can then put in lots of simultaneous requests across these different subdomains and load the complete image set faster. Pagespeed and Firebug are absolutely invaluable for messing around with this sort of thing.

However, all of this is useless unless the application code works well. I moved from Apache/CGI to Lighttpd/FastCGI a while back and saw some progress, but a little itch tells me that it could be better. There's a couple of things I need to investigate which may improve speed a bit. I may even ditch Perl as a platform (Oh No!) and do a rewrite in something like Java. Just wait for this to break again :)

2 comments

So, in my previous entry, one of the things I mentioned was around putting static web content on a separate subdomain. Having done this myself, I created a subdomain for this site to serve up CSS and JS content and called it res.growse.com. It seems that this has been causing problems over the past few weeks with my secondary DNS providers.

If you care or understand about such things, read on. If not, the end point is that I think I've fixed it, but bear with me.

I use Everydns.com as my secondary DNS people. They're wonderful. More importantly, they're free. However, for the past few weeks, they've been serving up NXDOMAIN responses to DNS requests for res.growse.com. I spent a while troubleshooting this, only to find out that the IP address that they request zone transfers on a regular basis is different to the IP address they use to do the initial transfer. I could delete and then add my domain on their site, and watch in my log the initial transfer succeed, because that IP address was permitted. What I didn't know was that future requests come in on a different IP, so they were being denied. This change seems to have happened back in March, if this tweet is anything to go by.

Everydns.com doesn't have anything on their site about this change though. In fact, in their FAQ, under "What IP does everydns.net use to request my zone?", 71.6.202.218 isn't listed.

So there it is. If you use them, keep an eye on your AXFR requests and make sure they're not failing. Or just allow anyone to transfer your zone, if you don't care who has it.

2 comments