Client side performance
Client side performance is important because most of the time loading a page is spent on downloading resources and putting them together in the browser. Applications such as DotNetNuke, and the servers they run on, are generally extremely fast at serving up files. However the number of files that are served (and the size of those files) determines how quickly the site will actually load for a user.
So, how can we improve? In general there are three key components for improving client side performance:
- Reduce the number of requests to the server.
- Reduce the size of the files being requested where possible.
- Serve only resources that are actually needed on a given page.
The Client Resource Management API
The API also manages the dynamic combination of files so that fewer server requests need to be made. It has an intelligent caching scheme to promote excellent performance, and it supports versioning as well, so that it’s easy to ensure that new files are incorporated when they’re added dynamically (such as when you install a new extension).
These are some very exciting capabilities that along with helping achieve performance goals, also allow for an easier and more intuitive development process.
Improved extension development workflow
One of the most compelling benefits of the new API is that it allows an extension developer to decouple “overloaded” CSS or JS files and break them out into smaller logical files (e.g. one for the layout/structure, one for fonts and colors, and one for the menu, etc.) and not have to worry about that nice separation during the development experience turn into extra performance overhead during the user’s experience of visiting the site. After all, each of those files will be combined appropriately.
Additional technical details
If you’re interested in finding out more about the API and how it works, please visit our new Client Resource Management API page in the Wiki where the details are discussed in some depth. As of right now, the wiki will be the definitive place for information about the API.
Additionally, while it is not likely to do so, the API found in the beta is still subject to change prior to the final release.
We need your feedback!
The DNN 6.1 Beta is out, and we need your feedback. How can you help? Download and test the beta! Review the new API or test an upgrade in your development or staging environment. If you develop commercial or open source extensions, please install the DNN 6.1 beta and test your extension!
If you have a question or concern, please leave it here in the form of a comment. If you are testing the API and discover a bug or an oddity, please log it in Gemini and mention Client Resource Management in the ticket.
A couple of things to note while testing the new enhancements:
- If you're currently using the 40Fingers StyleHelper to unload files, I don't believe that will work any longer. I am investigating ways of enhancing this API with "unload" functionality for a future release, but the new API, at this stage, will frustrate any efforts to unload files and does not provide a new mechanism for unloading.
- Combining files may surface "dormant" issues with your CSS. For example, today I resolved an issue where a module.css file had an unclosed comment (i.e. /* .... ) at the end. While that is technically wrong, it doesn't cause any issues unless there is more CSS after it, and once we combined the files, there was. So double check your CSS comments! :)
The new enhancements in DNN 6.1 represent a very exciting first step in an improved client side performance story. DNN 6.1 represents getting the foundation layer (API) in place. We'll be taking advantage of the development work flows mentioned above to further refine the core framework's client side story over time, and as the community embraces the new API, we should see even large gains in real world sites. Enjoy!