New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Enhancements for working with JavaScript and CSS files in DNN 6.1

Client side performance is something that a lot of us in the web world feel passionately about, and recently I’ve had the pleasure of working on some very exciting DNN enhancements in this area. I'll lead with a fun fact: number of CSS/JavaScript requests in DotNetNuke 6: twenty-two. Number in DotNetNuke 6.1: eight. But, before I give you all the details, let me set the “client side performance” stage.

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:

  1. Reduce the number of requests to the server.
  2. Reduce the size of the files being requested where possible.
  3. Serve only resources that are actually needed on a given page.

It is with these goals in mind that we introduce a new Client Resource Management API in DotNetNuke 6.1. This is an API that allows for registration of both JavaScript and CSS files and helps provide us with ways to deliver websites with fewer requests and a smaller overall payload.

The Client Resource Management API

The new API allows an extension developer to register CSS or JavaScript resources safely (automatically prevents duplicate registrations) and easily (can use the API directly in code or a user control in ASCX markup).

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.

As mentioned earlier, an important aspect of client side performance is only loading the resources that are actually needed, and if we’re structuring our CSS or JavaScript with a nice separation of concerns in mind from the beginning, we’re better able to register only those files that are needed in a given scenario.

In addition, JavaScript and CSS files can be automatically minified during the combination process, thereby alleviating the need for developers to maintain two different versions of files, or rely on their build process to create minified versions.

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:

  1. 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.
  2. 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!


Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out