Skip to Content

h2. Background

We released a web shop (http://www.hamperking.com.au  (http://www.hamperking.com.au)) 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?  

Investigate

The first step was to analyse responses from the server (I used httpwatch  (http://www.httpwatch.com/)) 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.

Minification

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 http://compressor.ebiene.de/  (http://compressor.ebiene.de/) for minification,

Notepad

for combination and Winzip  (http://www.winzip.com/index.htm) for compression.  However this is a maintenance nightmare as it needs to be repeated whenever changes are made.

Solution

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? 

*Pack:tag*

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

documentation

:

1. Download the pack:tag archive from http://sourceforge.net/projects/packtag/  (http://sourceforge.net/projects/packtag/) and unpack the packtag-x.y.zip 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=”http://packtag.sf.net” 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

configuration

in web.xml.

So… the results

HTTP Watch result before minimisation

0.1. After minimisation

!https://weblogs.sdn.sap.com/weblogs/images/35446/tn_HWresultspost.jpg|height=91|alt=HTTP Watch results after minimisation|width=700|src=https://weblogs.sdn.sap.com/weblogs/images/35446/tn_HWresultspost.jpg|border=0!</body>

To report this post you need to login first.

16 Comments

You must be Logged on to comment or reply to a post.

    1. Victor Yeoh Post author
      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.
      (0) 
      1. John Travolta
        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,
        John

        (0) 
    1. Guillaume GARCIA
      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,
      Guillaume
      (0) 
      1. John Travolta
        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.

        (0) 
        1. Daniel Ruiz
          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.

          (0) 
          1. Victor Yeoh Post author
            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!).

            (0) 
      2. Sharath Reddy
        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.
        (0) 

Leave a Reply