• Internet
• 18.12.2018
• EN

Manuel Schnitger: Handling CSS/JS

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

When there was a bit more CSS and JS to manage, there were mainly two out-of-the-box features that were used to handle styles and JavaScript:

• CSS and JS files were put into Media elements. (That just worked when no images were referenced.)
• Based on the code of the CSS and JS files content classes were created > based on these content classes pages were created. And whereever the files were needed a reference pointed to the corresponding page/link.

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.

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
<script type="text/javascript" src="/solex/wco-forum.js"></script>
<script type="text/javascript" src="/solex/wco-global.js"></script>
<script type="text/javascript" src="/js/jquery.functionality.js"></script>
<script type="text/javascript" src="/js/jquery.cycle.min.js"></script>
<script type="text/javascript" src="/js/jquery.MetaData.js"></script>
<script type="text/javascript" src="/js/jquery.rating.pack.js"></script>
<script type="text/javascript" src="/js/jquery.select.js"></script>
<script type="text/javascript" src="/js/json2.min.js"></script>
<script type="text/javascript" src="/js/solutionexchange20110303.js"></script>
<script type="text/javascript" src="/fancybox/jquery.fancybox-1.3.0.pack.js"></script>
<script type="text/javascript" src="/fancybox/jquery.mousewheel-3.0.2.pack.js"></script>
<script type="text/javascript" src="/js/cufon-yui.js"></script>
<script type="text/javascript" src="/js/OfficinaSans.font.js"></script>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script src="http://platform.twitter.com/anywhere.js?id=vvHyWEE7XQTaOWsnwoW9EQ&amp;v=1">
</script>
<link href="/css/main20110303.css" rel="stylesheet" type="text/css"/>
<link rel="stylesheet" href="/fancybox/jquery.fancybox-1.3.0.css" type="text/css" media="screen" />
<link href="/css/solex_smartEdit.css" rel="stylesheet" type="text/css"/>
<!--[if IE]>
<link rel="stylesheet" href="/css/non_css3.css" type="text/css" />
<![endif]-->
<!--[if lte IE 7]>
<link href="/css/iefixes.css" rel="stylesheet" type="text/css" />
<![endif]-->
<link href="/solex/wco-forum.css" rel="stylesheet" type="text/css"/>
<link href="/solex/jquery-ui-custom.css" rel="stylesheet" type="text/css"/>

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.

• Q: Why is it faster when the CSS/JS files are excluded?
• A: Two reasons. A) The pagebuilder doesn’t have to handle/parse the files. B) The files can be cached by the client browser.

 

Before we start:

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:

1. Perform the first two steps of the below mentioned description. (Copy content class & create a page based on the content class)
2. Open the folder c:\program files\Opentext\MS\ASP\LOG\Common and delete all log files. If you’re not allowed to do that, just copy them into a new folder. You can then copy them back after the test.
3. Call the preview of the page > press F5 ..maybe more than once ;) Now it’s sure that the page is in the page cache.
4. Open the RDCMS.log file in the just mentioned folder.
5. Look for the log file entry that’s written when a (your) page is being loaded. If the log file is almost empty the right area is easy to find.
6. Compare the time when the client requested the page with the time when the server responded. The difference is the time that is being used to load the page.
7. Delete all references to all CSS/JS files. (No it’s not enough just to write comments around the code ;-))
8. Call the preview of the page again and afterwards check the entry in the log file. The new entry is now the time to load the page without loading the CSS/JS stuff.

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
 

Let’s start!

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. ;)

1. First of all we create a copy of the content class that contains the CSS/JS files. We could also create a copy of whole project but not everyone has unlimited projects licensed.
2. We create a page based on this copied content class. This should be done in a testing area of the project ;)
3. We call the preview of the page a hope that the design still looks good. Then we can be sure that the CSS is still found. (Should work as we didn’t make any changes!)
4. We figure out where in the template code the references for the CSS/JS stuff are and replace them with hard coded paths. Sample: <link href=”/myWebsite/css/myStyles.css” rel=”stylesheet” type=”text/css”/>
5. Decide where on the Management Server you would like to store the CSS/JS files. (e.g.: c:\inetpub\wwwroot\myWebSite\css\)
6. We copy the CSS/JS files from our productional environment to the folder mentioned in step 5. (Don’t forget to also copy other files such as images which might be referenced from within the CSS/JS files)
7. We call the preview of the page again and (hopefully) see that the page still looks the same after the modifications.

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.

• Q: What can you do, if the CSS/JS files shall be stored in folder abc on the editorial environment and in folder xyz on the productional environment?
• A: We can use RenderTags in order to check whether we’re on the published page or on the editorial environment.

<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:

Deployment
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.

Administration
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!”

Tidiness
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.)

Versioning
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.

Link Management
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.

Backup
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