No one likes to wait for a Web site to load.
Least of all someone doing some last minute birthday shopping for an expectant niece or nephew or the pressured husband that just realized tomorrow is his anniversary.
Shoppers have very little tolerance for slow loading retail Web sites, therefore, developers should do more to speed up site performance when possible.
YSlow Survey Demonstrates the Problem
I recently took a survey of 25 leading retail Web sites using Yahoo’s YSlow Firefox add-on. The tool measures site performance against 35 performance best practices. And of these best practices, I was most interested in HTTP Requests.
In my little survey, many leading online retail sites performed poorly. For example, when I ran the test, Borders received an overall YSlow grade of D and an overall performance grade of 66. But the site actually got an F for HTTP Requests. Improving this one area could have helped to pull up the site’s overall performance score, not to mention make it load faster when would-be shoppers surfed by to get a copy of Seth Grahame-Smith’s new tomb, Abraham Lincoln : Vampire Hunter or a DVD of Disney’s Up.
In my less-than-scientific survey, sites that made fewer HTTP requests generally had better YSlow scores and faster load times. Conversely, sites that made a lot of HTTP requests had poor scores and poor load times.
In fact, it takes almost an additional 8 seconds for the balance of the demonstration page to load.
There are several things that a site developer or designer can do, to minimize HTTP Requests and blocking, thus improving site performance.
And as Kyle Simpson wrote in his article Tame Those Performance Monsters in the March 2010 issue of jsmag, a single combined would not make sense when you were calling libraries like jQuery, which are better downloaded from optimized content delivery networks and which can be cached.
Without a doubt you’ll want to organize files—39 is too many, one may not be enough—but some combining should probably take place.
Other potential solutions (improvements) include techniques like XMLHttpRequests (XHR), wrapping scripts in iFrames, and using the defer attribute in script tags. But each of these techniques has limitations.
For security reasons, XHR requires that all of the scripts being loaded and the host page have the same domain, so it won’t work if a site needs to load jQuery.
The defer attribute, which is part of the World Wide Web Consortium’s HTML 4.0 Specification, essentially tells the browser to wait until the page is loaded before executing the enclosed script.
But defer is not supported in every or even most web browsers.
I don’t mean to dissuade you from using these solutions, but I want to introduce you to what I believe is a better one.
The LABjs Solution
Implementing LABjs is also pretty easy. You end up replacing mark up like:
With mark up like: