The performance script loader

LABjs (Loading And Blocking JavaScript) is an open-source (MIT license) project supported by Getify Solutions. The core purpose of LABjs is to be an all-purpose, on-demand JavaScript loader, capable of loading any JavaScript resource, from any location, into any page, at any time. Loading your scripts with LABjs reduces resource blocking during page-load, which is an easy and effective way to optimize your site's performance.

LABjs by default will load (and execute) all scripts in parallel as fast as the browser will allow. However, you can easily specify which scripts have execution order dependencies and LABjs will ensure proper execution order. This makes LABjs safe to use for virtually any JavaScript resource, whether you control/host it or not, and whether it is standalone or part of a larger dependency tree of resources.

Using LABjs will replace all that ugly "<script> tag soup" -- that is all the <script> tags that commonly appear in the <head> or end of the <body> of your HTML page. The API is expressive and chaining, to let you specify which scripts to load, and when to wait ("block"), if necessary, for execution before proceeding with further execution. The API also easily allows inline code execution coupling (think: inline <script> tags).

Loading LABjs dynamically

It's been asked several times before: "How would I load LABjs itself dynamically, to save on the blocking load of LAB.js (~2k gzip'd)?"

The best practice is to load it via a <script src="LAB.js" async></script> tag.

LABjs & User-Experience

In addition to loading scripts in parallel, scripts loaded through LABjs no longer block page resource downloads (images, CSS). This will generally lead to significant decreases in page-load time (often 2x - 3x faster). However, be aware that this will lead to a different user-experience, in that your page resources may now arrive and display before your scripts arrive and process. If you are using behavioral JavaScript to style/modify your page, the users may now see a "FUBC" (flash of un-behaviored content) -- a quick glimpse of the raw content before JavaScript takes over and attaches style/behavior to the content.

You should think about this user-experience in the design of your site before deploying LABjs. LABjs fits well into the concept of progressive enhancement, but it just makes the "progressive" part more obvious to users. If you have a significant amount of behavioral JavaScript styling your raw content, it can create a jarring or disruptive user-experience for the user. So, a simple way to address this is:

  1. In your main CSS of your page, hide (display:none or visibility:hidden) all content which will have drastic re-rendering by your JavaScript.
  2. In your JavaScript, make sure to re-display/unhide the content once it has been styled by your code.
  3. To take care of users who do not have JavaScript enabled, put a <noscript> block in the <head> of your page that unhides any content hidden by your main CSS -- essentially, undo the CSS hiding of content, since there won't otherwise be any JavaScript to do so.

By taking these 3 simple steps, you will effectively address the disruptive user-experience for JavaScript-enabled users, while still preserving proper display for the non-JavaScript crowd.

Contact me

Questions or Thoughts? Contact me @getify on twitter.