Thursday, August 13, 2009

Speeding up content delivery on the Radio NZ website

We've made a few changes to the way content is served on

1. The first is that all static content is now served from a separate domain ( We are using Nginx for this task because it is faster and more light-weight than Apache.

One benefit is that the browser can make more connections to the site for downloading page elements in parallel.

The second reason we used a completely different domain (instead of a sub-domain such as is that it is cookie-less.

The browser does not send any cookies with requests for this static content. If it was on a sub-domain, then any cookies for the domain would be sent with each request. In the case of our home page, this added about 6k to every page request.

One of the NZ sites I tested while working on this has 65K of cookies sent for static assets on the home page. Someone has to pay for that wasted bandwidth.

2. The expiry date of static content is set one year in the future, and assets are marked as Cache-Control: Public.

This tells any application that the content passes through (including the end-user's browser) that the content can be cached, and that it won't expire for a year.

Intermediate caches (like the ones most ISPs have) are more likely to keep a copy of the assets and pass them on instead coming back to our servers. The browser will also check the content in its local cache and only fetch items that have expired.

The net effect is fewer requests for static assets. The makes for less bandwidth used by the client, and less bandwidth paid for by us.

Initial tests show that browsing between two recently visited pages (or pages that are cached locally) is about 100% faster than before the changes. Pages that are not already cached are about 15% faster due to nginx serving files more efficiently and the gzipping of our HTML content. Previously we did not gzip html content because of the relatively high server load, but nginx seems to be able to do this without any impact.

In fact, the overall server load has been reduced by about 10%.

For those who are interested, browse around the site with the Firebug Net tab open and watch how the content loads. You'll notice two things. The first is that subsequent visits to the page only get the main page and the two analytic scripts. The second is that the page fully renders quickly, even though the browser is still getting content. This was achieved by careful placement of the CSS and JS files in the HTML markup.

The site now gets a YSlow 'A' rating (excluding the CDN test, which is not relevant to us).


Duncan Robertson said...

Fantastic result with 10% lowering of server load. Well done!

Hayden said...

nice job, just curious why you didnt go down the smushit route?

Richard Hulse said...

We already take a lot of care with images, and running over the homepage typically yields less than 5% improvement or around 1k.

We will eventually get there I suspect - we just had other priorities for this cycle of improvements.