Combining Resources - Speed Week, Day 3
Improving the overall load time of a web page is one thing but a big factor in the user's perceived speed of a site is is how long they have to wait before something even starts to appear. How long are they left staring at a blank white space before your pretty site design even begins to render?
So it's useful to know that the <body> of the page will not appear until everything in the <head> has been loaded!
With this in mind take a look at this grab of the Firebug Net panel for the developerWorks site:
The bits in red I've added. Stuff above the red line forms the head. Below it is the body. Obviously.
Notice anything different about the grey bars of the time-line above and below the line? Above the line the files load in serial, whereas below the files (mainly images) load in parallel.
While the browser can try and load multiple images at once it can only load JavaScript files in the head one at a time! The reasons are obvious and I believe (and will assume for this blog entry) that the same is true of CSS file. Let's concentrate on JavaScript for now though.
It follows that the less code you load in the head the faster the page will appear. If you can, it's an idea to limit files loaded to only those needed and to get rid of any redundant code. However, assuming you can't and that all the code is needed there's still performance gains to be had.
Because of the way HTTP works there are overheads involved in every file request. Because of this it's faster to load a single 100KB JavaScript file than it is to load ten 10KB files. This is especially true if you catch the server on a busy day where it's struggling to answer all the requests it's receiving from different clients. As soon as you get a reply it's best to make the most of it download all the code in that one GET request than try and make nine more GET requests and wait for an answer each time.
So, what I'm suggesting is you have a combined.js where you put all the code from your JavaScript files. The same goes for CSS files. It might make sense to us as developers to have an ajax.js and a search.js but it means nothing to the user or browser to distinguish between them. Before you make the site design live combine the code and maybe even minify it.
Skip to the 
You can subscribe to an individual
Minifying JS libraries is definitely worth the effort, but don't forget to check your JS libraries first for syntax errors. I always use JSLint for that task.
In a web app I manage we use a lot of images and JS libraries. Lately, we've gained a lot of performance increase by caching images more aggressively on the user's client. This can be achieved by adding values to the HTTP response header. Chris Linfoot talks about this here: {Link}
Two notes about this method:
1. It won't influence first time visitors (which is what your current project is all about).
2. Think about what will happen if you update a library. Since the expiration headers are set, your end users won't automatically receive the updated file (only after a page refresh or after the resource is expired). We've solved this by adding a version to the path in which the resources are stored.
Cheers,
Mark
Minor point Jake - the PMH.js actually occurs in the body on that site.
Jake are you coming to ILUG in May?
It's amazing what i can learn with this "week speed tips". Thanks for sharing Jake.
A (may be a stupid) idea came to me :
Why not put the call for some of your JS files (like field controler) right next the body tag ?
Peter. Good point. Notice, however, that the browser still loads it in series with the JS files from the head and not inline with the images.
Michael. No.
Julien. See reply to Peter above. Not sure if it would work and if if did then you'd have to be sure that the functions weren't needed by any user interaction that might be possible before the onload event fired.
Great tips as usual!
Looking at the output from the Firebug Net panel, how do you determine that the PMH.js occurred in the body instead of the head?
You don't - look at the DOM (html tabe of Firebug), or view source.
Jake makes a good point in responding to Julien - if your js can wait for the onload event, moving them to the body is an option to speed things up.
Another speed-related option using the headers approach that Chris outlines is using gzip to compress JavaScript. This is pretty much standard practice now if you're running your site on Apache, but in Domino it's only possible on a limited basis. If your .js files aren't dynamically generated, though, it can be done, and a .js file that's been minified and gzipped is typically one tenth its original size. Full details on this approach available here:
{Link}
I use the gzip compression for static js on my domBulletin project, quite easy
For dynamic zip in domino, it's there but hidden. Go to the names.nsf of the server, in designer, and unhide the gzip section (I thiink it's on the web server tab, bottom).
I think it's going to be officially supported in 8.0.1 from what I heard at LS 2007
PS: do not forget also about domino server side caching (command cache)
I have used <a href="http://alex.dojotoolkit.org/shrinksafe/">ShrinkSafe</a> with much success on my Javascript.
On another note, I never host my javascript, or css on my domino box. I have an Apache box with compression turned on to host that up. It makes a huge difference.
Very interesting.
So far I've never noticed that files were loaded sequentially in the head section whereas they are loaded simultaneously in the body section.
That answers a lot of questions I'm wondering for ages.
I know the number of threads may vary (and btw that you can specify your own with FF), but do you think this is a common behavior among browers, or just a FF one ?
As well as the fact that the body only displays once the files specified in the head section loaded ?
YoGi. Not sure which other browsers have a setting for the number of requests made at once, but, as "webmasters", it's hard to imagine ever relying on the users having it at anything other than default.
Douglas Crockford, in his talks on YUI Dev Theatre, also suggested that all js files be sourced as close to the end body tag as possible for the same reason. IE remove them from the head completely.
Jake : actually my question was about the fact that resources are loaded sequentially in the head and simultaneously in the body across the browsers, not about the number of simultaneous threads (or if it's customizable) ;)
YoGi. Are you asking if all browsers behave in the same way? I'm not sure but I assume the do - in fact have to.