Speed on a budget - how Media UK hosts our website

Another RAJAR radio listening figures release generally means a lot of extra traffic to Media UK. So, how do we cope with the additional load on our servers, without spending oodles of money? If I was advising you on how to run a website so that it was fast and cheap, here's what I'd tell you:

Never serve any static files yourself
Your main website - www.mediauk.com in this case - should only be used to serve one file: the (dynamically-generated) HTML.

Stylesheets, graphics, and other things should be on a different website. Every, single, call to your main website should be returning pure HTML. View the source of Media UK's front page, and you'll see that every static file is being served from c1.muk.fm, c2.muk.fm or c3.muk.fm. These addresses, which actually point to the same place, are served by Amazon CloudFront, and go nowhere near our server infrastructure.

Why c1/c2/c3? Most browsers won't download too much at the same time from the same server. By distributing the calls over these different servers, we can fox your browser to download more at the same time, therefore your page appears faster.

Why muk.fm? We use a subdomain of muk.fm, rather than mediauk.com, to avoid every request being accompanied by a mediauk.com cookie. In Media UK's case, this cookie contains Google Analytics data and other things that we don't care about when serving static files.

Use third parties where possible
Media UK's RSS feeds are served via Feedburner, for example, to avoid extra load on our own servers. (We could serve those via muk.fm as well, but Feedburner has other benefits). This means that every call to Media UK's RSS feeds are handled by Feedburner, and not Media UK's infrastructure. RSS feeds can be significant traffic.
We use Google's Font API, and Google's cache of jQuery, since other websites do this too, and the chances of being in a user's cache is high: as well as ensuring there's no additional calls to our own server infrastructure.

Keep database queries down on your popular pages
The main content of the Media UK front page is generated from a number of fairly costly database queries. We assemble the page once every ten minutes, and currently save it as one flat object in the database. The Twitter updates on the right-hand side go one further: stored as a flat file which is simply included on the page load.

Use the power of caching
Your browser will store information automatically, and not bother to request all of it every single time. When loading the Media UK front page, many of the items - the CSS file, the magnifying glass for the search box, the logo - won't have changed, so the browser simply checks they haven't changed and doesn't bother downloading anything further. Requesting the front page today at 6.11pm, the logo, for example, says it was last modified yesterday at 11.00am - so my browser has done nothing more than check this and then use the local version of the logo that already exists.
Media UK also instructs your browser - or your ISP - to cache the entire web-page for 60 seconds. This is useful in corporate situations where three or four users might use the website at the same time.
We also local caching ourselves for Facebook signin information. On logging in, we copy your Facebook information to our local database, rather than request it on every pageload. This significantly speeds up page load times.

Media UK could be faster: particularly with directory pages, which are complex and comparatively slow. It's certainly a work in progress. But we hope that the way we've authored the site means that we can cope with heavy increases in traffic: which sometimes happen just when you don't expect it.