Improving Secondary Asset Loading Time for an ATG Application

Now that we covered improving the performance of serving the HTML from the JSP, we need to tackle the bigger problem of all of the secondary assets and media that the page loads to display correctly. This includes images, Javascript, CSS, Flash, videos, etc…

The reason that these secondary page assets are so critical for page performance is two-fold. First, there are many more of them for each page than the single HTML file. This means more HTTP connections have to opened and closed, more files have to be transfered from the server to the user’s computer. This takes a lot of time. Second, most of these assets tend to be static, they don’t change very often. This means we can cache them.

Reduce the number of assets

The first thing we need to do is to try to reduce the number of secondary assets which need to be loaded. You can try to simplify the page design to require less assets, reduce the number of images used, replace images with text (which is more accessible and search engine friendly anyhow), etc… Also reducing large files like videos and Flash files can make a significant improvement on page load times. Personally, for things other than video players and similar things, I strongly dislike the use of Flash. There is an impressive amount of rich interface and interaction that can be created using DHTML and AJAX. It generally performs better, loads faster, and is easier to make search engine friendly.

Another approach is to try to combine multiple CSS or JavaScript files into a single CSS file and a single JavaScript file. However, this makes managing the CSS and JavaScript during development much more difficult, especially if you’re using 3rd party CSS or JavaScript files or libraries. So I don’t do that. There is a great taglib which solves this problem for you. pack:tag. This tag library allows you to reference multiple JavaScript or CSS files from your JSPs. It then merges the files together and optionally minify and gzip compresses them. This allows you to develop and maintain CSS and JavaScript files which are organized logically by functionality, and yet only serve a single, minified, gzip compressed, JavaScript or CSS file to the end user. This can be a huge benefit. For instance the BestBuy Televisions page we used as an example before references 23 external JavaScript files. Reducing that down to 1 minified file would dramatically increase the performance of the page.

While we’re talking about JavaScript, try to put the JavaScript references at the bottom of the page, this reduces the time the browser waits before rendering the DOM tree. And you should also put the CSS scripts inside the head of the HTML document.

We can also reduce the number of images we request by using CSS Sprites. This is method of putting a number of small images into a single large image and referencing the images based on the coordinates. The downside is that you have to manage/edit the images within the single large image file. The upside is you can dramatically reduce the number of HTTP requests for images to build the page.

Reduce file sizes

We need to also reduce file sizes, if we can. Images, Flash files, video files, etc… should all be examined to ensure they are encoded for the minimal size possible and to still maintain the quality needed.

Caching files

Now that we’ve reduced the number of files that need to be loaded, and ideally their size, the next step is to reduce the number of times they need to be loaded. Your basic website will use the same general CSS file(s) and maybe a few commonly used JavaScript files, the same widgets and design images on almost every page. The default behavior is for the browser on the end user’s computer to request those files each time a new page is loaded. This is obviously wasteful. By setting the appropriate HTTP headers in the response with a file, you can tell the browser to cache the file for some period of time, and not request it again. This lets the subsequent pages use an image or CSS file that is loaded from the end user’s computer (memory cache or hard disk cache), which is much faster. Many times those files can be safely cached for days or weeks, which means every time the end user returns to your site, the pages load rapidly.

If you’re using ATG on DAS, you can use this ATG pipeline Servlet I create to set the cache related headers easily. If you are using JBoss as your application server then you’ll want to look at this cache header managing Servlet filter that I wrote.

Summary

At this point the user’s browser should be requesting fewer, smaller secondary assets to display the webpage, and should only be requesting them once (per expiration time period-week or day). Not only does this make pages load much more quickly, but with the use of caching the static content on the browser, you’ve dramatically reduced the number of HTTP requests that hit the server, thus freeing up your web application cluster to handle more users and page requests on the same hardware. Plus it reduces your bandwidth used, which can save money.