Tuesday, February 18, 2014

CDN + Google Page Speed Optimization = Awesomeness

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:
IISpeed MapRewriteDomain cdn.iispeed.com www.iispeed.com
That was all - it just works - great!

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.


This is where Page Speed comes to the rescue. The cache extending filter will embed a fingerprint of the content into the url, and serve the asset with a one year expiry.
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.

If all goes well, using a CDN should speed up content delivery for vistors on our website. iispeed.com is hosted in The Netherlands, and we expect that using the CDN should be especially noticeable for people that are far away. The CDN should cache contents at its remote edges, which should be closer to our visitor. Browsers should also be able to connect faster to the CDN's servers, as the required roundtrips should take less time due to the geographic advantage.
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.

Update 

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. 

Update 2

Following a discussion on the problem seems to lie in IIS's default settings. With some tweaking, we got this to work - thanks @AkamaiRob!

Update 3

Things are looking a lot better. Our GA measurements show that more then 1 second is shaved of the averaged total page load times!