SPDY is a proposal from Google for making three major improvements to HTTP: compressed headers, multiplexed requests, and prioritized responses. Initial studies showed 25 top sites were loaded 55% faster. Server and client implementations are available, and some other organizations and individuals have completed server and client implementations. The protocol draft has been published for review.

FRAG

The idea behind this “document fragment” tag is that it be used to wrap 3rd party content – ads, widgets, and analytics. 3rd party content can have a severe impact on the containing page’s performance due to additional HTTP requests, scripts that block rendering and downloads, and added DOM nodes. Many of these factors can be mitigated by putting the 3rd party content inside an iframe embedded in the top level HTML document. But iframes have constraints and drawbacks – they typically introduce another HTTP request for the iframe’s HTML document, not all 3rd party code snippets will work inside an iframe without changes (e.g., references to “document” in JavaScript might need to reference the parent document), and some snippets (expando ads, suggest) can’t float over the main page’s elements. Another path to mitigate these issues is to load the JavaScript asynchronously, but many of these widgets use document.write and so must be evaluated synchronously.

A compromise is to place 3rd party content in the top level HTML document wrapped in a FRAG block. This approach degrades nicely – older browsers would ignore the FRAG tag and handle these snippets the same way they do today. Newer browsers would parse the HTML in a separate document fragment. The FRAG content would not block the rendering of the top level document. Snippets containing document.write would work without blocking the top level document. This idea just started getting discussed in January 2010. Much more use case analysis and discussion is needed, culminating in a proposed specification. (Credit to Alex Russell for the idea and name.)

@angus I had the same issue and i complete rewitten Labjs to use a observer pattern instead of .wait function. It also made my code less mesy..
lab.script(“filename.js”).wait().script(“filename2.js”)
lab.observe({
“filename.js”:function(){ alert(“done1”) },
“filename2.js”function(){ alert(“done 2”)}
})
.
vs
.
lab.script(“filename.js”).wait(function(){ alert(“done1”);}).script(“filename2.js”).wait(” alert(“done 2″)”;

@AngusC — yes, you have the same dependency issues you would have had if you had “script tag soup” with a dozen script tags. You have to make sure things load in proper order. LABjs allows you to do that, if you already would have known how to sort out your dependencies before using LABjs.

In fact, a call like this would automatically imply a “wait” (exeuction wise) after each script call, which makes it exact very much like regular script tags (in terms of execution, but without the bad blocking loading behavior):
.
$LAB.setOptions({AlwaysPreserveOrder:true})
.script(“script1.js”)
.script(“script2.js”)
.script(“script3.js”)
.script(“script4.js”)
.script(“script5.js”)
.wait(function(){ alert(“All scripts done”); });
.
In short, LABjs never claimed to make your dependency life easier… you should reduce the number of files you have if you want to do that (and improve HTTP stream utilization). But LABjs *does* I believe make the process of loading properly the scripts that you’ve worked out such dependency issues already.

@V1 — sorry you felt the need to entirely re-write LABjs. Wish we could have discussed your concerns prior to that drastic of a step. I understand if you weren’t a fan of the chaining API, but it offers an expressiveness that is quite popular (see jQuery for instance). In my opinion, LABjs’ approach is much cleaner and simpler than what you’ve shown. But I guess that everyone has their own opinions. Certainly LABjs’ way is *shorter*, that should count for something.
.
The observer pattern you showed is fine for what it does, but kind of runs counter to one of the main points of LABjs, which was to be able to have one “listener” function waiting for several scripts before it runs.
.
Pretty much every script loader on the planet is capable of doing one script to one callback… that’s easy. Where LABjs is different is the idea of loading 3 script files, that can load in any order, and then execute in any order as fast as possible (or execute one at a time if execution order dependencies were necessary), and then having one function “callback” that ran when all of them were done.
.
From what I see of your observer pattern suggestion, you’ve lost this ability and relegated your use of LABjs back to that of pretty much every script loader previously available. And in fact, I bet there’s a lot of “waste” still in there because you’re mooting one of its most important (and complicated) features.

Considering the simple fix for synchronous script loading is reduce the number of scripts in a page, it hardly seems like the number 1 issue. I think far too many script authors want to solve all their issues at the client, when it can be much more efficiently handled at the server and far less data need be sent to the client in the first place.

The biggest change that developers can make to browser peformance is to stop bogging it down with all that AJAX garbage. Page sizes of 600kb are routine, wasn’t AJAX supposed to help reduce bandwidth? Most sites can use vastly simpler pages and Web 0.1 techniques to get an almost identical UI.

The Ajaxian home page is nearly 900kb, with over 100kb of script. Whatever happened to concise, efficient code?

@getify – I didn’t say everything should be put into one script, I said that developers should “reduce the number of scripts in a page”. Seems your linked article agrees that this is the single most effective strategy for optimising the time script takes to load.

As you note, other optimisations are also available and provide further improvement. Guess you wanted to promote your product.

However, allowing an unlimited number of asyncrhonous script requests is likely to make things worse, not better. Therefore lobbying browser vendors in incorporate it as a performance boost should not be high on a competent developer’s wishlist, much less right at the top. Additional attributes for the script element to control when a script is downloaded are likely helpful, but browser vendors aren’t necessarily the best group to lobby. Try the HTML5 WG.

@RobG —
Notice, I didn’t bring up LABjs here. I simply responded to others making mention of LABjs (in a negative light) with clarifications. And then you chimed in and basically said that effective script loading (and by implication, LABjs) was not an important thing because all people had to do was the “simple fix” of reducing number of loading files. I still think this is an overly simplistic view of the topic — but that’s because I spend so much time researching and working on it.
.
And even though my conclusion (and many others) is that reducing file downloads is a very important part of page-load optimization, I also emphatically state that it’s only part of the picture — and that even if you have one or a couple of files, you STILL need more intelligently load them in most cases. You need a loader to do that right now. And LABjs is one option for that.
.
If you really feel like script loading strategies aren’t important, that’s fine, that’s your choice. But it’s been proven to be an area that has lots of problems and lots of potential to improve performance. And if it really was as “simple” as just concat’ing files, every site and framework on the planet would do it and we’ve have noone with slow sites.
.
But that’s not reality. I’m just part of the crowd that’s trying to advocate working to improve it, and I believe “improvement” will take a lot of different approaches all at once, including browser improvements *and* (at least for the time being) shim tools like LABjs to help the cases that aren’t yet solved.
.
I’m not “promoting a product”. Suggesting an open-source project which has hundreds of hours of work and has been vetted by some of the top minds in the performance optimizaion arena as *ONE* effective solution to a problem is a totally different thing. It’s really hard to get the word out about open-source projects that are not “products” and don’t have any marketing effort behind them. Pardon me for mentioning my project and discussing why I believe it has merits, as well as addressing any criticisms I hear.
.
In fact, in several places on my blog, I actually suggest that LABjs is part of a class of “smart loaders”. There are other options out there, that to varying extents accomplish the same goals. I just honestly haven’t yet found one which accomplishes all that LABjs does. So it’s naturally still my first suggestion. If I did find one that surpassed LABjs in an important and useful way, I’d not only promote *it*, but I’d also figure out how to draw inspiration from it and push LABjs further. THAT is what the open-source community is all about.