Posts Tagged ‘javascript’

Using mod_concat to Speed Up Start Render Times

Aug ‘08 1

The most critical part of a page’s load time is the time before rendering starts. During this time, users may be tempted to bail, or try a different search result. For this reason, it is critical to optimize the <head> of your HTML to maximum performance, as nothing will be visible until it finishes loading the objects inside.

One easy way to speed up rendering during this crucial time is to combine your CSS and JavaScript, saving the performance tax associated with every outbound request. While easy in theory, in practice this can be difficult, especially for large organizations.

For example, say your ad provider wants you to include their script in a separate file so they can make updates whenever they choose. So much for combining it into your site’s global JS to reduce the request, eh?

mod_concat makes combining shared libraries easy by providing a way to dynamically concatenate many files into one.

See mod_concat in Action

We created a couple test pages to show the benefits here. In our first example without mod_concat, we see a typical large scale website with many shared CSS and JavaScript files loaded in the <head> of the HTML. There are scripts for shared widgets (two of them video players), ad code, and more that typically plague many major web sites.

You can check out the Pagetest results here, and check out the time to start render (green bar):

pagetest waterfall with mod concat disabled

In the test page, we have 12 JavaScript files and 2 CSS files, a total of 14 HTTP requests in the <head>. I have seen worse. The green vertical bar is our Start Render time, or the time it took for the user to see something, at 4 seconds!

We can see that the time spent downloading is typically the green time, or the time to first byte. This happens on every object, simply for existing! A way to make this not happen, is to combine those files into one, larger file. Page weight (bytes) stay the same, but Requests are reduced significantly.

Let’s take a look at our Pagetest results of a second example with mod_concat enabled.

pagetest waterfall of music page with modconcat enables

Notice our the number of Requests went from 14 to 5, and we saved 1.5 seconds! We probably could have made an even faster example by moving to just 2 requests (one for CSS and one for JS), but the speed win here is clear.

How mod_concat Works

mod_concat is a module for Apache built by Ian Holsman, my manager at AOL and a contributor to Apache. Ian gives credit in the mod_concat documentation to David Davis, who did it while working at Vox, and perlbal.

The idea is straightforward, and you can pretty much figure out how it works by viewing the source code of our second example:

<link rel="stylesheet" type="text/css" media="screen" ←
	href=",common.css" />
<script type="text/javascript"  ←
<script language="javascript" type="text/javascript" ←
<script type="text/javascript"  ←

You can see in the highlighted code above that a single request is referencing multiple files, and the server is returning the concatenated version. The URL takes the following format:,directory/filename2.js,filename3.js

Let’s break it down.

The first bit should be straight forward, it’s the host name.

Next comes the optional path to the files. This is important, because you can’t concatenate files above this directory if you include it. However, it allows you to optimize a bit so you don’t need to keep referencing the same path for files below this directory.

The ?? then triggers the magic for the files that come next. It’s a special signal to Apache that it’s time to combine files!,

If the file is in the current directory, you can simply include it next, followed by a comma “,”.,directory/filename2.js,

If you need to go a bit further in the directory hierarchy, you can do that too.,directory/filename2.js,filename3.js

You can include as many files as you wish as long as they fall within the same server directory path defined early on in your optional/path/.

Performance and Caching Considerations

mod_concat uses the Last-Modified date of the most recently modified file when it generates the concatenated version. It should honor any max-age or expires Cache Control headers you set for the path in your server or htaccess configuration.

If you have a far future expires or max-age header, to bust the cache you will need to rename one of the files or directory names in the string, and then the user will download the entire concatenated version again.

Because mod_concat is an Apache module, performance is near instantaneous. Performance is improved further still if the server happens to be an origin point for a CDN, as it gets cached on the edge like an ordinary text file for as long as you tell it to, rarely hitting your servers.

Same Idea, Different Platforms

For regular folks like myself who don’t have the ability to install Apache modules with their hosting provider (cough, Lunarpages, cough), mod_concat is not the best option. The idea of concatenating JavaScript and CSS has been implemented on other platforms, and I will briefly call out those I found in my brief Googling – feel free to list more that you know of.

Rakaz’s PHP Combine Solution

Niels Leenheer of has a nice solution for PHP. Niels writes:

Take for example the following URLs:


You can combine all these files to a single file by simply changing the URL to:


Niels takes advantage of Apache’s Rewrite rules as such to make the combine PHP script transparent to the template designer:

RewriteEngine On
RewriteBase /
RewriteRule ^css/(.*\.css) /combine.php?type=css&files=$1
RewriteRule ^javascript/(.*\.js) /combine.php?type=javascript&files=$1

This is nice because it keeps the PHP script and HTML template separate from each other, just like mod_concat.

Ed Elliot’s PHP Combine Solution

Ed’s solution for combining CSS and JavaScript is less flexible from a front-end template designer’s perspective, as you’ll need to touch PHP code to update the files being merged together. However, the advantages I see to his take on the problem are:

  • He masks the actual file names being combined, and
  • A new version number is automatically generated to automatically bust the cache

For folks who don’t mind digging into PHP, the above benefits may be worth the effort. I especially like the cache-busting, as it allows me to put a far future expires header without worrying if my users will get the update or not.


Finally among the PHP scripts I found is PHPSpeedy. Also available as a plug-in for WordPress, PHPSpeedy appears to get the job done like the others, with the added benefit of automatic minification.

This might be useful for folks, but I’m the obfuscator type and promote that for production build processes. I’d love to see a safe obfuscator like YUICompressor written in C so we could turn it into a module for Apache.

Lighthttpd and mod_magnet

For users of Lighthttpd, mod_magnet can be used to do the concatenation. It appears similar in nature to Rakaz’s solution, though I will leave it to you to dig in further as it seems to be fairly involved. This blog post by Christian Winther should help get you started.

ASP.Net Combiner Control

Cozi has developed an control to combine multiple JS and CSS into a single file, and includes a cool versioning feature much like Ed Elliot’s script. It’s very easy to use; you simply wrap the script with the control tag in the template:

<WebClientCode:CombinerControl ID="CombineScript" runat="server"><script src=" ←
	script/third-party/jquery.js" type="text/javascript"></script><script src=" ←
	script/third-party/sifr.js" type="text/javascript"></script><script src=" ←
	script/third-party/soundmanager.js" type="text/javascript"></script><script src=" ←
	script/cozi_date.js" type="text/javascript"></script></WebClientCode:CombinerControl>

It then outputs the following code at runtime:

<script src="../Combiner/Combiner.ashx?ext=js ←
	&ver=59169b00 ←
	&type=text%2fjavascript ←
	&files=!script'third-party*jquery*sifr*soundmanager*!script*cozi_date*" ←

The only problem I see with their approach is that since the output file has query parameters, Safari and Opera won’t honor cache control headers as it assumes it is a dynamic file. This is why simply adding ?ver=123 to bust the cache is not a good idea for those browsers.

Java JSP Taglib – pack:tag

Daniel Galán y Martins developed a combine solution for Java called packtag. It follows in the spirit of PHPSpeedy and provides additional optimizations such as minification, GZIP, and caching.

It’s not obvious from the documentation what the output of the combined script looks like, but in a flow graphic it seems to include a version number, which would be cool.

The code to do the combination goes right in the JSP template, and looks like this:


CSS can be combined too. The syntax appears to be quite flexible:


As you can see this idea has been implemented in many languages, some with additional innovations worth considering, so if you can’t leverage mod_concat, at least use something similar as the benefits are well worth it.

Final Thoughts

mod_concat is a performant, cross-language, high-scale way to build concatenation into your build process while maintaining files separately. While it lacks automatic versioning (Ian, can we do this?), it provides a clean way to dynamically merge JS and CSS together without touching a bit of server-side code, and it works across server-side languages.

One feature I’d like to see added is a debug mode. For example, if the code throws an error it may not be apparent based on line number what file is having issues. Perhaps the filename could be included in comments at the start.

Remember, improving the time to start rendering the page is critical and you should focus on this first. With tools like mod_concat and the others mentioned here, there should be little excuse to implement this into your routine. Little pain, a lot to gain.


Beating Blocking JavaScript: Asynchronous JS

Jul ‘08 23

MSN is now implementing a technique for loading JavaScript in a way that doesn’t stall the rendering of the document. They use Dynodes, a technique I also recommend for loading functionality on demand so it only consumes bandwidth when it is needed.

JavaScript Blocks Everything

To see the problem, view a Pagetest waterfall report of pretty much any website today, or see this recent run of Notice that 1 second is spent downloading and executing JavaScript, one at a time.

waterfall graphic of aol javascript blocking rendering

One by one, folks! This is how all browsers load JavaScript (unless the defer attribute is used in IE) when called from your standard HTML <script> element.

However, viewing a waterfall report of MSN, we can see that they call 3 JavaScript files (dap.js, hptr.js, and hp.js) asynchronously, and allow the subsequent CSS files to load right away.

waterfall graphic of msn javascript not blocking

Had their scripts loaded in the standard way, dap.js, hptr.js, and hp.js would delay the page for 1.4 seconds!

Loading JavaScript Asynchronously

MSN is using standard DOM functions to create and append a script element to the HTML document’s <head> element. This technique, originally coined as Dynodes, is encapsulated in a JavaScript loader, much like the one used by JS frameworks such as Dojo.

We downloaded and formatted the HTML source code so you can have a closer look at it. Start on line 297 which kicks off a process to a function aptly named JS:


Note that it is passed in two URLs defined back on Lines 13-19:


The JS function kicks off a method that pulls down these two scripts. Take a look at line 130 to get to the heart of this technique:

var c=g.createElement("script");

The <script> element (c) is appended to the <head> element (p), as defined back on line 113.

MSN also appears to be closely monitoring the load of all the scripts called by JS, in case something happens during the process. Event handlers are set on readystatechange, error, and load to stop the polling process (fired every 100ms) once the script is finished.

Their code is quite obfuscated and difficult to follow, but you can look for the timeout function on line 125. There also appears to be an optional parameter to kill the process after a specified period of time.

JS Loader Prototype

We designed a JS Loader Prototype (not nearly as fancy as MSN’s) that illustrates the benefits of this technique, and tested behaviors in IE and Firefox.

In our prototype (we strongly suggest you view the source now), the code is organized into 4 sections:

  • JavaScript #1 and #2 are called from a <script> block in the <head> using our JS Loader function.
  • JavaScript #3 and #4 follow next, called by the JS Loader in a <script> block in the <body>.
  • JavaScript #5 and #6 are called after some text again by the JS Loader, from a second <script> block in the <body>.
  • Finally, #7 and #8 are loaded in the traditional, HTML <script> element fashion.

In Internet Explorer, the script files queued up normally and the screen was not blocked for any period of time (until #7 and #8). Notice a very short Start Render time in our test run at Pagetest, and JS loading as fast as HTTP1.1′s 2 connection per domain limit will allow it:

waterfall chart of js loader prototype in ie showing full asynchronous load

In Firefox, however, any content below the next inline HTML <script> section is blocked until the scripts from the previous inline HTML <script> section called by the loader are complete. You have to see it to believe it!

waterfall chart of firefox blocking until all js has download in each script block

Notice in the above chart, within each script block both JavaScript must fully load before the next script block is allowed to start processing. The takeaway here is to include as many JS Loader calls as possible in one script block.

We developed a workaround for this issue by including a timeout delay before calling the script. This allows Firefox to continue rendering like IE and Safari, and affords the fastest possible download. See the updated JS Loader Prototype for Firefox here.

waterfall of updated prototype showing that firefox no longer blocks other scripts

We put a longer delay on the first script (10 seconds) so you can see that Firefox no longer waits until the script block has completed before loading others. The important bit of code looks like this:

	// If you want to call IE and Safari straight up without the delay, uncomment this.
	// ('Firefox')) ? js = setTimeout("artz.create('"+url+"')", 0) : artz.create(url);
	js = setTimeout("artz.create('"+url+"')", 0);
	s = artz.ce('script');
	s.type = 'text/javascript';
	s.src = url;

You will be pleased to know that Safari renders much like IE, with the added benefits of 4 open socket connections!

waterfall shot of safari with 4 open socket connections

Hopefully the benefits to this approach are clear. With a large site like MSN faithfully using Dynodes for their scripts, it might just be the time to standardize on this approach.

Race Condition Challenges

Not so fast! (pardon the pun) There are some additional considerations we will need to think through when moving in this direction.

  • JavaScript functions in the external scripts may not be available when inline HTML JavaScript functions call for them.
  • Along the same lines, even if Script A is called before Script B, Script B may finish and execute before Script A.
  • DOM elements may not yet be available in the HTML should an external script need them to hook events, access data from, etc.

In tackling the above, we would first recommend following the Progressive Enhancement approach, and work to completely eliminate inline HTML JavaScript function calls. The external scripts can latch any events needed on to links, buttons, etc., once they are ready.

While race conditions may still exist, a way to solve this is using the setInterval function to initialize your functions where you know a race condition may exist.

function id(id){return document.getElementById(id)}

var oranges =
	init: function()
			alert('We have oranges!');
			// We may proceed with orange code!

oranges_init = setInterval("oranges.init()", 100);

We recommend using a period of 100ms to go easy on the CPU, and still feel instantaneous to users. To see this code in action, have a look at our ID Polling Prototype.


External scripts loaded that include the infamous document.write method executed by the script will cause problems with this technique. Be sure to wrap it in a function and call it from the HTML if you decide to head down this path. We hope that by now, you have thrown this ancient tool away.

Advertising vendors…this means you!

Final Thoughts

This technique has been on the back shelf for some time due to the tricky Firefox and race condition issues.

That said, if we are careful, and with MSN proving its value, now just may be the time to adopt Dynodes as a standard JavaScript loading practice.

Leave us a comment with your thoughts, questions, and concerns, and post links to implementations that leverage this!

Please index me, experiment!

“Chancho, when you are a man, sometimes you wear stretchy pants in your room. It’s for fun.” — Nacho