written by Manuel Schnitger, 11. July 2011
In this artice I describe ways how to improve the maintainance of CSS & JS files and how even the performance in SmartEdit can be enhanced with just simple modifications regarding the referencing of those files.
10 years ago web sites were mainly build using HTML and very little CSS & JS. The CSS and the JS code has partly just being kept within the main content classes….and that worked.
Figure 1: JS directly in the template code
Figure 2: CSS/JS using Media elements
Figure 3: JS implementation using references
Of course there were some variants of the second option. Some people created a reference to the page, some to the link the page was connected to.
But both approaches do have one thing in common: The pagebuilder of the Management Server has to load and parse the CSS/JS code. That is absolutely ok, when the amount of code isn’t that big, but today state-of-the-art websites normally use CSS & JS frameworks with thousands of lines of code. There is no clearly defined number of lines of code but it’s obvious that a page with less code can be handeled faster by the pagebuilder than a page that references 20 or more files.
So one reason to think about an alternative, is the performance of a page within the SmartEdit mode or the preview.
The code below is from our Community plattform “Solution Exchange“. If we would stick to the above mentioned option a and b then over 20 Media elements or pages would be loaded and parsed when a user clicks on just one link in SmartEdit or in the preview of a page.
Another disadvantage of option a and b is that it’s not that easy to make changes to the styles and the JS code. Using Media elements would mean that the changes have to be done outside the system and then the files would have to be uploaded again and again. Using option b is a bit better as changes could be made within the template editor, but the template editor is just a template editor….not a proper development environment for CSS and JS.
Conclusion until now: If your web site uses lots of small CSS/JS files or maybe just a few bigger ones then it’s a good idea to somehow provide them outside the Management Server. Speeds up the performance and makes it easier to make changes.
If you just want to exclude the CSS/JS files just for performance reasons then please check if it’s worth doing the below mentioned modifications. To check whether the performance improves there is a simple way:
Now you know how long it takes to load the page with and without the CSS/JS stuff and you can decide if it’s worth (in terms of performance) to do the modification.
Figure 4: RDCMS.log displaying when the client requested and the server responded
Ok, what we’ll do is hard code the paths to the CSS/JS files in our content classes. As the page builder doesn’t “know” code, it will not be able to follow the hard coded paths. Of course then the referenced files have to available under the referenced path. ;)
Last step: If everything works and the page looks good then the last step is to delete the formerly used media elements or any other elements which are not used any longer.
Ready with this part! Paths hard coded…. design still looks good! CSS/JS files can be changed directly in the file system with the tools we like! The changes in the code take immediately effect and are reflected in SmartEdit! And the editors are happy because even the performance is now better!
If you want to see, how the result looks? Download the Best Practice Project from SolutionExchange and have a look at the content class 0701 – css_include_set_std.
<reddot:cms> <if> <query valuea="Context:CurrentRenderMode" operator="!=" valueb="Int:2"> <htmltext> <!--Reference on the published page --> <link href="/production/myWebsite/css/myStyles.css" rel="stylesheet" type="text/css" /> </htmltext> </query> <query type="else"> <htmltext> <!--Reference on the editorial server --> <link href="/myWebsite/css/myStyles.css" rel="stylesheet" type="text/css" /> </htmltext> </query> </if> </reddot:cms>
So why not just finish the article here?
Because there are (at least) two different options where the files can be stored/placed. And as both options do have advantages as well as disadvantages I would like to describe them a bit more detailed. (Note: From my point of view there is no best practice. Where you store the files depends on the requirement of the project and the environment.)
Option A: You just put the files in the file system of the productional as well as of the editorial environment. Ready.
Option B: You create a content class per CSS/JS file > put the corresponding code into the content classes > replace the images with placeholders > create a page based on each of the content classes and publish the files into the corresponding folders in each environment.
Option B obviously sounds like more effort…. and it’s true: I takes some minutes in order to have the pages available in the Management Server. But there are also some advantages of this approach:
When you just put the files into the file system and make changes to the files then you have to copy the changed files to all locations (dev environment, qa environment, productional environment). When you use the option B, then you just have to make the changes in one file and transfer the modifications into the content class. After that you just publish the pages and the changed files are available in all environments.
When there are content class folders just to hold the content classes for CSS/JS files and if there is a clearly defined area in the project where the pages based on these content classes are located, then this can help to enhance the administration of these files. Furthermore you could use the template description in order to add helpful information such as “Main CSS – Used for all projects” or “Marketing CSS for microsite xy. Will be deleted after the relaunch!”
When the files are stored as pages within the Management Server project and the option “Live server cleaner” is activated, then you just delete the page in the project and after the next publication, the corresponding files will be deleted on all environments. That means: You always have exactly the files in the different locations that are needed. Not more, not less. (And of course, when having a defined area where the pages are located within the project, then the CSS/JS files are not published each time when an article is being published.)
Of course you could use tools like CVS, SVN, Team Foundation Server, Visual Source Safe and others in order to create versions of the CSS/JS files but not every stakeholder of a project likes to have yet another tool running on the machines. Furthermore there would be another tool to get used to.
If the CSS/JS files are managed manually then you as the project builder are responsible to insert the right paths to images or included files (e.g.: print.css). If you let the Management Server manage the paths then you can be sure that they are consistend and correct.
Last but not least you always have a complete backup of the CSS/JS files. Whenever the hardware is damaged or should be changed by other reasons you just say:”Tell me the IP address of the new location and I’ll make the project available just by publishing the whole site.”
Some people think that CSS/JS files are not content and should therefore kept outside the CMS. I agree with this but have to add that I think that those files are surely not content but still belong to the project.
But as written before: From my point of view there is not one best practice approach but many different ones that correspond to the requirements of the specific project.
All aspects of the decribed approach can be seen within the Best Practice Project that can be downloaded at SolutionExchange. If you would like to discuss this article then please do this via the forum of SolutionExchange.
Source: Handling CSS/JS
© copyright 2011 by Manuel Schnitger