Posted by: Will Morgenweck
1/3/2012 2:39 PM
 One of my favorite features in DotNetNuke 6.1 is the new Client Resource Management capabilities. This is a feature that I wanted to see as part of the core a few years ago. As a commercial module developer and DotNetNuke website owner, I was constantly keeping track of overall page output with each DotNetNuke release. DotNetNuke 6.0 introduced several new components that greatly improved the user interface, but unfortunately also added more to the overall page size. We knew we needed to get better control over the number of resources needed for each page and we knew it needed to be done for DotNetNuke 6.1.
As a few of you know, we did find a few issues with the Client Resource Manager after the initial release. Thanks to some great feedback from our community, the Client Resource Manager is ready to make your website load much faster. How much faster? Well, since all websites are different, including DotNetNuke websites, the performance improvements really depend the skins, containers and modules that you use.
Knowing that there are many different factors that can affect page performance, I needed to come up with a baseline method to measure the client side performance across different versions of DotNetNuke. I also needed to use a common tool that would score the a web page based upon typical browsing characteristics. My testing conditions were as follows:
- Clean installs of DotNetNuke 4.9.5, 5.0.0, 5.6.2, 6.0.0 and 6.1.0
- Windows 7 64-bit/IIS 7.5
- Firefox 8.0
- Plain Skin (compatible with all DNN Versions tested)
- YSlow
We had three main goals we wanted to achieve with Client Resource Management. First, we needed to make sure that Client Resource Management API was compatible with existing modules and skins. Our second goal was to reduce the overall number of HTTP requests per page load. Finally, we wanted to reduce the size of JavaScript and CSS files as much as possible. Fortunately, YSlow made it very easy to capture the information I needed to see how each version of DotNetNuke performed.
The Results
YSlow Scores
Higher numbers are better.
 Total Number of Requests
Lower numbers are better.
 Total Request Payload
Lower numbers are better. Measured in Kilobytes.
 Page Load Speed
Lower numbers are better.
 Still Room for Improvement
If you look at the Page Load Speed results you can see that we have some room for improvement. However, in order to improve page load speed we will need to continue to improve the Request Payload. This means we will need to become more intelligent in the way we load CSS and JavaScript files. As a framework, we need to make sure we are only loading the resources that are necessary for the current page request. Client Resource Management is helping us get there, but the next step is to see if we can further optimize our core files such as default.css.
Coming in Part II
We’ve posted several blogs and wiki entries explaining how to use the Client Resource API, but that isn’t really helpful for site administrators that are trying to improve their site performance. In my next entry I’ll explain how to make sure Client Resource Management is enabled and what to look for from skins and modules that are affecting the client side performance of your DotNetNuke website.
|