Client side performance optimization adventures with the CdnSupport module

by: Joel Abrahamsson

On the project that I’m currently working on we have been putting quite a lot of effort on client side performance in order to provide the best possible experience for the visitors. We have been using the rules in the Best Practices for Speeding Up Your Web Site from Yahoo as a guideline and measured the results of our efforts with the Firebug plugin YSlow.

We have put stylesheets a the top, put scripts at the bottom and made both stylesheets and scripts external.

We have been combining images with CSS sprites and combining several javascript files into a single one to minimize the number of HTTP requests.

We have been minimizing javascripts with Packer, compressing images and keeping viewstate usage to an absolute minimum to make the site lean bandwidth-wise.

A few of the other performance rules that we wanted to follow was to split components across domains, use a cookie-free domain for static components and add expires headers to components. While the previously mentioned performance optimizations that we did could, and should, be considered obvious steps in building a well-crafted site site with no or little cost in maintainability these three rules posed a challenge as abiding by them could have a steep price in maintainability.

Rewriting the URLs for static components to split the HTTP requests across multiple domains and have all static components loaded from a cookie-free domain would be a tiresome job and create problems for us when setting up development and staging environments as all static components would still be loaded from the live site. Adding expires headers could, on the other hand, easily be done by modifying the expiration time for static files in web.config but would mean that returning visitors browsers might not download the latest versions of javascripts, stylesheets, images or documents. A potential nightmare.

Luckily for us there was a simple and quick solution to these problems: the CdnSupport module described and downloadable here. The module rewrites all URLs that are referring to static components to change their hosts to that of a specified CDNs, or in our case just static.customerdomain.com. In other words, all we had to do was drop the assembly into our bin-folder and add a few lines of configuration and all of the URLs are rewritten for us.

Setting up development and staging environments now isn’t a problem as we can simply disable the module in their web.config files.

The CdnSupprot module also adds the change date of the file to the path which means that we don’t have to worry about returning visitors browsers not downloading new versions of static components when we add expires headers to them as, in the eyes of the browser, the updated files are “new” files that it haven’t downloaded before.

Conclusion, results and links

So far the CdnSupport module has worked like a charm. The only issue that I have with it so far is that it doesn’t rewrite URLs to javascript files that have been imported by a ScriptManager, but that might very well be due to some mistake made by me. If not, I’m sure the development team will fix that in future releases.

One does have to be a bit careful with what files the module is used for though. As it rewrites the URLs for these files visitors who request them at a later time because they have bookmarked them or found them through Googles image search engine might be disappointed to find that they are no longer there when the files have been updated and the path rewritten.

The result from our efforts have been very positive so far. The customers project manager has been getting spontaneous praise for the speed of the site from within her organization and we ourselves think that it loads very rapidly. As for YSlow the site is getting a C for the front page and a B for most of the other pages which contain less components.

So, thanks and hats off to Per Bjurström and whoever else is developing the CdnSupport module! 

On the subject of client side performance, make sure you check out Mats Hellström and Peter Sunnas presentation from the EPiServer Day and the links they mention. Maximizing Parallel Downloads in the Carpool Lane is another very interesting article on the subject which describes why it’s a good idea to distribute HTTP request across multiple domains.

25 May 2009

Tags:


    Comments

    1. Thanks for sharing. The ScriptManager remains unsolved..
    2. Will this only work for VPP folders. I have css and javascript files that do not use VPP.
    Post a comment    
    User verification Image for user verification  
    EPiTrace logger