The Effect of Multiple JavaScript Files on Page Load Time

One of the problems that you may encounter when you add new features to your site is that you run the risk of slowing down the page load time. Before adding anything to your site, there are a couple of things you should check out. Even if you aren’t considering adding anything, you may want to take a look, just to see what’s what.

First, take a look at Web Site Optimization. In the interest of disclosure, this is a client of mine for Movable Type Consulting, so I’m not a completely unbiased observer. But the site is a good one. You can use their free web site analysis tool to see how long it takes your page to load. A quick look tells you how long it takes the items on your page to load – HTML, images, scripts, styles and the like. What’s even better is that you get a good look at how long it will take not just on your high-speed connection, but how long it might take on a slower connection as well, and some basic tips to speed things up. I’ll talk about that more in a minute.

If you have installed the Firebug extension, you can do something similar for your JavaScript files. Just click over to the Net tab, and it will show you how long it takes to load all those scripts that you’ve plugged in to add one feature after another. It would be really cool if you could see the length of time it took to load files such as the stylesheets and other HTTP requests made by the page, but at least at this point, you only get the scripts. It’s better than nothing.

Typically, you will see a number of files loading, but it really depends on what you have on your page. Including something like Google AdSense will result in at least two files – one called show_ads.js and another called graphics.js. If you have more than one ad block on your page, then you will actually load show_ads.js once for each ad block. If you use Google Analytics, you will have a script named ga.js or urchin.js. One of the worst offenders is probably Kontera – though I use them here, they load six different scripts to run their context ad network. You may have a JavaScript framework, which could be as small as a single file or as large as a whole set of files, depending on the framework you have chosen.

Anyway, you get the idea. The point is that the more files you load, the longer it takes. Naturally, the larger the file, the longer it takes to load – but people tend to forget that the more files you open, the longer that can take too. For instance, the three Google AdSense files only take up about 14K, but they take about 155ms to load (on average – these can be cached as well, so load times can vary). Meanwhile, you might think that the 54K Kontera file would take longer than the much smaller Google files, but in reality, it only takes about 78ms – much, much faster (unfortunately, the other five Kontera files eat up the difference – they take about the same amount of time as the three Google files).

What I’m getting at is that your browser has to make a connection for each of these files, and the overhead for that connection is often what takes the time. The content that is being loaded may not be too large – the script files on the home page here only account for about 91K (which admittedly is probably too high), but it shouldn’t take long for that to load if it was in one file. Because it takes 10 individual requests, it took 624ms the last time I checked. That’s just insane, and it seems like people don’t pay it much attention every time they add another widget to their blog.

Many of these pieces of script take longer and longer to load. Some are downright hogs. Recently I’ve taken steps to try and minimize this as much as possible by combining smaller JavaScript functions into a single, site-wide library, packing that, and then serving up the single file. For packing JavaScript, I typically use Dean Edwards’ Packer. I’ve seen others, but this one seems to be well-regarded, and it does a quick job at doing what it’s supposed to – compressing the JavaScript and making it usable, without breaking anything along the way. For a couple of bytes here and there, I’m just not willing to break usability, and I’m less worried about the savings of bandwidth than I am the load time. Being able to put the content into the single file has really cut down on load time – you’d be amazed at the improvements. Now if we can just get some of these third-party folks to quit making so many calls to different scripts, it would really help. One of the Kontera libraries is 86 bytes. 86 bytes! That’s just crazy.