Last week, we starting using a CDN on iispeed.com. After setting up the DNS for cdn.iispeed.com, it took us about 10 seconds to add the required line to IISpeed's configuration file, to enable rewriting of all css, js, and images and route them via the CDN:
That was all - it just works - great!IISpeed MapRewriteDomain cdn.iispeed.com www.iispeed.com
Our CDN uses a pull model, which means that the CDN will forward all requests that it does not have in cache to our webserver. Common problems when using a CDN are twofold:
- First, the CDN will only cache assets that broadcast that they are cacheable in the first place.
- Second, when the CDN has cached something, a manual purge has to be done to be able to propagate updates to the website. These purges are often limited to a fixed amount per period, and no guarantees are given to the speed at which they are processed.
So now, the CDN will keep the asset in cache for a year. If Page Speed detects a content changed, a completely new url will be generated - which makes content updates immediately visible to all end-users. It's like having your cake and eating it too.
The CDN should be able to proactively keep network connections open to our webserver, which eliminates time - no roundtrips are required to perform the initial connection setup.
Regarding our CDN: We need to sort one thing out: it seems that our current provider does not support any form of http compression, which is disappointing. We are running an A/B test to measure up - it would be nice to know if the CDN makes up for the lack of compression due to its geographical advantages. The results will be published in a few weeks on this blog as well, after which we might switch the CDN to one that does support gzip compression.
We have disabled the CDN for now - the page load times nearly doubled (see the image below). We are discussing this with our provider, and hopefully the CDN service can be improved.
Following a discussion on the problem seems to lie in IIS's default settings. With some tweaking, we got this to work - thanks @AkamaiRob!
Things are looking a lot better. Our GA measurements show that more then 1 second is shaved of the averaged total page load times!