Slash your page load times with output caching

A recent project that we’ve launched has been struggling with page load times as the site becomes increasingly popular. We have a three part optimization plan to slash the load times - Server side optimization, client side optimization and AJAX optimization. I originally designed this site to be heavily AJAX reliant, with all the user specific content to be served out of a separate webservice tier via AJAX and all the essentially static content to be served out of the CMS. 

 

Today I’m going to cover how we tackled the server side performance. For this project, we chose Umbraco v4 as the CMS platform. Although Umbraco ships with some caching  options, there are still substantial gains to be made. Umbraco offers caching on a per control basis which gives you the ability to selectively cache certain components. As I mentioned earlier this project has been developed to have no user or context variations per unique page which means that we can blanketly cache the entire page using .net Output Caching. Output Caching occurs at a very early stage in the request lifecycle, which offers lightning fast response times to cached pages. 

 

Implementing Output Caching in Umbraco for the first time has proven to be troublesome. The first pitfall that we’ve uncovered is that the default rewriting module which ships with Umbraco – URLRewritting.net, does not work with output caching. We replaced URLRewritting.net with Microsoft’s Url Rewrite Http Module and we were up and running. We also noticed a slight performance improvement switching rewrite modules which is always a plus.

 

Usually there are numerous ways to implement asp.net output caching but the only reliable way we have found is through creating a custom HTTP module which evaluates the HttpContext Items which are set by Umbraco to determine which pages to cache. 

 

Since we are using Url Rewritting for the majority of the content, the requested URL for the rewritten content does not match the underlying Umbraco page’s URL. Luckily the HttpContext contains and item named “umbOriginalUrl” which contains the Umbraco page’s URL. So now that we know which Umbraco page has been requested we can access the properties of the document where we have specified our server and client side caching options. 

 

These document level options include:

• Enable output caching
• Output cache duration
• Expires header
• No Store header

 

Our custom Http Module now controls all the above settings and it’s fully controlled on a Document Type level within Umbraco. The end result is static file like performance from our heaviest pages.