Skip to Content

Improve performance of your web application by minimising CSS and JS

h2. Background

We released a web shop (  ( using SAP CRM 2007 late last year and recently implemented a number of improvements to the site.  One area of focus was performance – how can we improve this without adding more hardware?  


The first step was to analyse responses from the server (I used httpwatch  ( and identify the time consuming requests.  From this, I noticed a large number of CSS and JS files requested.

We had a number of custom developed and standard SAP CSS and JS files.  For each to be retrieved, a time costly request is sent and the file is downloaded.  It is possible to improve this process by:

1. Minification – this removes unnecessary characters (such as line breaks and spaces) from a file to reduce its file size.


2. Combination – merging multiple files into 1 reduces the number of HTTP requests made

Combining multiple files into 1

3. Compression – This further reduces the size of the file and the data required to be download

Compressing files for quicker transfer


The above can be achieved manually, by utilising tools such as  ( for minification,


for combination and Winzip  ( for compression.  However this is a maintenance nightmare as it needs to be repeated whenever changes are made.


A preferred option is to leave the files as they are and dynamically minimise via java code.  It is possible to write your own, but why do that when someone else has done all the hard work already? 


is a serverside static-resource compressing JSP-Taglib. It creates ad hoc compressed JavaScript or CSS in memory or in a file.  Import this into your project and include into your code and you have dynamic CSS and JS minimisation.

To implement I followed the



1. Download the pack:tag archive from  ( and unpack the file to e.g. packtag

2. Copy packtag/files/packtag-x.y.jar into your web-applications WEB-INF/lib directory from the packtag/files/web.xml into your /WEB-INF/web.xml

4. Restart Web AS

To use the Pack:Tag taglib in a JSP:

1. Declare it first:

<%@ taglib uri=”” prefix=”pack” %>

2. Now you can pack JavaScript by using the following tag:

<pack:script src=”/js/myJavaScriptFile.js”/>

3. Accordingly for Cascading Style Sheets:

<pack:style src=”/css/myCascadingStyleSheet.css”/>

4. You can combine resources simply by listing them up:

<pack:script><br />   <src>/js/myJavaScriptFile.js</src><br />   <src>/js/mySecondJavaScriptFile.js</src><br /></pack:script>

If the files do not behave appropriately after minimisation, try different methods of compression.  It is possible to change


in web.xml.

So… the results

HTTP Watch result before minimisation

0.1. After minimisation

!|height=91|alt=HTTP Watch results after minimisation|width=700|src=|border=0!</body>

You must be Logged on to comment or reply to a post.
    • Yes, I do not see why it could not be applied to Portals.  I am yet to test it, so its effectiveness depends on the amount of CSS and JS minimsation achievable.
      • My concern in Portal case, is that most of JS and CSS are not controlled by you, and even from what I saw from this packtag, it only applies to JSP, in the portal there is a lot of AbstractPortalComponents, Web Dynpro and KM Components, where you don’t have control.

        What would be great, was a kind of “reverse proxy” tool in Portal Server, that before sending response (HTML) to the client, parses  element, get JS and CSS Files locally, merge them, and change the response (HTML) in order to include a single file for each type (JS and CSS). These single files would be cached locally on the server, for future requests.

        Thanks & Regards,

    • Hi,
      Well, ZIP (well GZip in fact, because it’s a stream and not a file) does not suppress comments you put in your Javascript code along with spaces and line breaks, for instance.
      You can still apply GZip after the minification process.
      Besides, there are several HTTP requests because there are different parts (images, CSS, Javascript) to get from possibly different locations, so there is not a single response but several.
      Best regards,
      • Agree, that’s exactly the point where is the bottleneck do Portal, too many request to JS and CSS files, even if they are GZIP, they are too many, in most cases, the same file is requested more than once, even if for second requests don’t need to be downloaded, there is always a round trip to the server.

        I really hope this can be improve soon, I think there are a lot to improve and can be improve.

        It could be an idea to reduce the number of request, merge files, ..,, apply some functionalities to Portal Page Builder and iView base framework. For example, when in the same page there is iViews of the same type (same portal application) and they are in “mode” embedded, it should be possible, at least by iView parameter, “say” that the second and thrid iViews, should not include standard JS and CSS files (only the first will request them), or the Page Builder could be enough intelligent, and apply it this logic, so we do not run the risk of removing the first iView and forget to activate in one of the other iViews.

        • I understand what this is doing, in such way it can improve performance due less hits for resources on server.. it is handy, no doubt about it. However, if you have a well-designed application you won’t have an excessive number of js or css being part of one html. I also saw that most of the files are jQuery stuff, jQuery also makes available a complete packed lib for prod. use..

          But I’m not saying that this was not useful information, I just think that sometimes you could solve this issue by not having it at the first place.

          • In our case, we combined a number of non-SAP solutions together to deliever the requirements for the web shop.  Those solutions were delivered with a preconfigurd css and js file configurations.  They were left as original as possible to aid with maintenance in the future.

            I hear what you are saying and yes, it is possible to design an application that will not use multiple js or css files, however if not logically separated, it makes readabilty (and maintainability) near impossible (try reading a minified file!).

      • Yes true that there are several HTTP requests for CSS, JavaScript, images etc. Using HttpWatch I could see this when trying to assess performance for a transaction iView (tCode = IH03) and noticed this problem. I think this is something that SAP has to address because we don’t have control over this feature.