Hi Joe,

I have been working on adding style sheet combination and compression for the 40 Fingers Stylehelper skin object, but it is still not finished.
I planned that for the 3.0 version, but I have had way to much work the last half year to finish it.
I have plans to release the skin object as module too, but a configuration module is a good idea, thanks.

---

as long as css and script files depend on modules used on certain pages only, combination does not really make sense (or you result in page specific larger downloads)

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

>> Chris Hammond: "Ideally, all of this would be handled at an API level..."
Agreed.

>> Sebastian Leupold: "as long as css and script files depend on modules used on certain pages only, combination does not really make sense"

Actually, although the issues around css and javascript differ a bit, it does still make sense.

css:

• Common plus page/module specific- minimally, it makes sense to combine the css that's used on every page.  
  Then, only the additional css that's specific to each page/module will need to be requested.  E.g. On this site, the front page makes 13 css file requests.  Based on a highly unscientific click-through of other parts of the site, it looks like at least 5 of those (default.css, skin.css, container.css, portal.css, TabStrip.css) are used on every page.  Those 5 could be combined into 1, the file would be ~15K and you'd be down to 8 css requests for the home page and 2-5 requests for others.  Plus, you get the benefit of browser caching that common css so likely only need to load it once.
• All css? - If the site's not too diverse, it's possible that most, if not all, css files can be combined into a single file (even if some of the css is not used on every page - although it would of course need to be tested).  And, again, you get the benefit of browser caching so likely only need to load it once.  Whether that's the best option would of course depend on how large the files are.  E.g. The DNN front page has ~31K of css.
• API - If it's done with an API that's flexible enough, you could use a hybrid approach using any combination of the above.  I believe the tool i mentioned above (squishit) does just this, automatically, and caches it for future use.

Javascript - 

• Is different from CSS for 2 reasons 
    1) While css is site-specific (it's unlikely you'll use the same css as another site), the exact-same javascript libraries ARE used on different sites.  
    2) Most browsers stop rendering when they reach a <script> tag.  This is tags which request javascript libraries should be moved to the bottom if possible.
  
  As a result:
• Use a CDN when you can - DotNetNuke already supports this for jquery.   Commonly used javascript libraries (e.g. jquery) should be loaded from a CDN (if available) - NOT combined with other local javascript.  Why?  Because it's likely that the library is already on the users system because they've visited another site that already loaded it from the same CDN (assuming you're using goggle).
• Common plus page/module specific - That leaves just your custom javascript - with needs that are similar your CSS.  i.e. You'll likely have some that is common to all pages (e.g. if you use a javascript menu) and some that is page/module specific.
  
  Again, I believe a tool like squishit can handle these use cases and cache them for later requests.