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.
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.
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&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:
- Perform the first two steps of the below mentioned description. (Copy content class & create a page based on the content class)
- 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.
- Call the preview of the page > press F5 ..maybe more than once
Now it’s sure that the page is in the page cache. - Open the RDCMS.log file in the just mentioned folder.
- 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.
- 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.
- Delete all references to all CSS/JS files. (No it’s not enough just to write comments around the code ;-))
- 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.
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
- Step 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.
- Step 2: We create a page based on this copied content class. This should be done in a testing area of the project
- 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!)
- 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”/>
- Decide where on the Management Server you would like to store the CSS/JS files. (e.g.: c:\inetpub\wwwroot\myWebSite\css\)
- 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)
- 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 Render Tags 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.
manuelschnitger
We prefer putting the layout files on the live and editorial server, because it enables us to use our own deployment process, we don’t have to fiddle with image elements and we can use git as a version control system (of course the whole HTML/CSS development process with all of its files has to be managed through a version control system). And we can use the CMS to manage content – not layout. It is a pain to use the CMS to handle “css templates”, because CSS changes and you cannot just upload a new/changed css file into the cms, because this would break image elements.
Regarding the mentioned benefits of using css templates:
Deployment: At first you have to create HTML and CSS, then you have to copy the CSS and all images to the CMS, create/change the template, add image elements to it and upload the images. You have to do the last step at least two times – in your test and prod cms. It’s faster to just copy the css/images folders to both machines.
Administration: Just put your CSS/images into properly named folders.
Tidyness: Your deployment process is broken, when it contains “too much” stuff on the server. This can happen using the CMS or when copying the stuff. Just use rsync (or a similar tool) in the wrong way and the server is filled up with no longer needed pictures. But the “preferred” way to fill the server with unused images is to keep the in the CSS files. And then also the CMS will not remove them, because the templates contain the images elements. So Tidyness must begin at the designers level. Designers should only deliver files which are used.
Versioning: Branches anyone?
Link Management: Correct. The CMS helps building the correct paths for you. But where do we possibly store layout files? In folders like “/styles” or “/images”. There’s not very much which can go wrong here. And the CSS files should take care of themselves and load the images, so everything you should care about is setting up the correct paths for CSS and Javascript _once_ in a header template (or the header of the page framework template).
Backup: There are tons of stuff which belong to projects, like databases, the php configuration and other things. Layout files are just a small fraction and whenever something goes wrong, you have to look at the whole situation. Putting back some files out of a version control system should be less work than trying to fix broken or empty files because of some publication errors ;).
But overall it’s a matter of taste and what you prefer in your projects. During the last decade, we tried several different approaches to deal with layout files and now use the method which gives us the fastest method of page creation, the fastest reaction times for the editors and the best way to deal with version control and the integration of CSS changes. Whatever you choose for your project will also depend on what your customer or the customers’ IT prefers. For example, some prefer to keep everything in the cms (which means: css templates) because it allows them to create easier backups (they can grab the cms export and can be use, that this contains “everything”). As a side-effect, this also means that changes in CSS files require at least an hour to put them onto the two cms servers…
First of all thanks for the feedback!I totally agree with you. There are pros and cons regardess which way someone chooses. I prefer the way described in my post because I like the idea of having erverything in one place. No other tools or functionality just the Management Server
Regarding the time it takes to publish modified files I have to say, that a full publication of all CSS files for different project variants (HTML/HTML_DS/SAP/Print) takes very short time. In the Best Practice Project there is a specific area where just CSS files are stored and when the implementation has been finished and just a few modifications have to be made then it just takes a few seconds and everything is updated in different environments. But at the end…everyone chooses the approach she/he is most happy with.
This is the most comprehensive article regarding management of CSS and JS files in MS so far!
Not only covering existing best practices, but also put the pros and cons to discussion.
the only time I use the ‘old skool’ method of adding JS/CSS within Media elements, is when i need to tweek or make changes to styling and layout of the site – but am unable to access the Production website directly.
its not uncommon for organisations/companies to have IT policies in place that restrict developers from accessing production environments (unless they go through a detailed change management process). this method enables me to bypass this if changes need to go up ASAP for a project.
good point about there being no ‘best practise’ when it comes to CSS/JS.. the type of project determines which method you should use.