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)?" Since it gets asked fairly frequently, I threw together this little code snippet as a place to start.

Snippet to load LABjs itself dynamically

Some things to note:

  1. The size of the minified snippet is ~640b before gzip. This means you will be increasing the size of your HTML page by at least this much. That's not particularly a problem, but it is something to be aware of in terms of tradeoffs.
  2. My best guidance would probably be to use the snippet to load LAB.js dynamically on your first page load (landing page, etc), and then on all subsequent pages in your site, just load LAB.js normally with a <script> tag (since it should then load nearly instantly from cache).

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. If you like this project, you also might like to check out:

Related searches:
content script loading before execution
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.