kyle added....

To answer @paulirish's earlier question (https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1765361) about defer quirks, look at how "DOMContentLoaded" behaves across IE, Chrome, and Firefox in the defer test.

In IE9 and Chrome15, the DOMContentLoaded event is held up (blocked) and not fired until after the scripts run. In FF, however, the DOMContentLoaded event is not held up, it fires right away, and the scripts start executing after it. That's a giant inconsistency across modern browsers, and one of the reasons why I don't think defer is sufficient.

Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-defer

To give more context to the above list of defer issues:

1. defer doesn't have any meaning in dynamic script loading. But it doesn't need to, because of the new "ordered async" (async=false) that IS spec'd and now in almost all browsers' current releases. What's confusing though is that you have to use defer when you're dealing with markup, and async=false when you're dynamically creating script elements. The latter would make you assume you could/should use async in markup, but that's not going to work because order is not preserved -- unless of course you happen to not care about order.
2. this is now proven (partially documented) by this video: http://www.screenr.com/icxs To save you from having to watch it, though, IE9 and Chrome15 both block the DOMContentLoaded event (aka, "DOM-ready") until after all the defer scripts finish, whereas FF8(nightly) does not block the event. I'm willing to bet there are other browsers which fall on both sides of that issue, as well, as the spec seems a bit confusing on this particular point (at least in my reading).
3. It seems from some older blog posts that at one point, inline script blocks could have defer set on them, and browsers would respect that. http://hacks.mozilla.org/2009/06/defer/ However, as that video above clearly illustrates, none of the current browsers respect that, and in fact, reading the spec, defer is NOT defined for inline script blocks. That makes it uber-difficult to convert an existing set of script tags (some external, some inline) to use defer, if those inline blocks are relying on ordering (almost always they are).
4. I don't have much evidence of this, but I know a guy who's done a bunch on this, and I'll ping him to get some more specifics. I stay far the hell away from document.write(), but some unfortunate souls have to deal with that reality (aka, "nightmare").

I made a test which seems to confirm the following:

In FF, however, the DOMContentLoaded event is not held up, it fires right away, and the scripts start executing after it. That's a giant inconsistency across modern browsers, and one of the reasons why I don't think defer is sufficient.

http://dl.dropbox.com/u/513327/domload_defer.html (load and reload it in Firefox 5 and then load in Chrome)

Chrome 12 results: expected: number; got: number;
Firefox 6, 5, 4, 3.6 results: expected: number; got: undefined;
Firefox 3.5, 3.0 results: expected: number; got: number;

Update: I removed the Cuzillion tests on visual rendering blocking because they were invalid.

Isn't blocking the visual rendering only supposed to occur with non-defered scripts? What would be the advantage of defer then? I'd say all is well with how FF 3.5+ and Safari handle it. Safari 4 and sorts blocking may just be indication that they don't recognize a defer-attribute yet.

In regards to DOMContentLoaded event being triggered too early, maybe the following manual DOMContentLoaded triggering technique may be of interest for a fix: http://stackoverflow.com/questions/942921/lazy-loading-the-addthis-script-or-lazy-loading-external-js-content-dependent-o

if( document.createEvent ) {
 var evt = document.createEvent("MutationEvents"); 
 evt.initMutationEvent("DOMContentLoaded", true, true, document, "", "", "", 0); 
 document.dispatchEvent(evt);
}

@Schepp

In regards to DOMContentLoaded event being triggered too early, maybe the following manual DOMContentLoaded triggering technique may be of interest for a fix

I think that might cause problems with some handlers as it's generally assumed DOMContentLoaded is only fired once.

FWIW:

[22:36] <matjas> is there a point in using @defer when you only use a single <script> and it’s at the bottom, right before </body>?
[22:36] <Hixie> not really
[22:38] <matjas> not really or not at all?
[22:38] <matjas> what is the point?
[22:39] <Hixie> there's no point that i can think of
[22:39] <Ms2ger> Being fancy! :)
[22:39] <Hixie> there are some subtle minor differences, but nothing useful i don't think

Source

Are the logical next steps to:
a) define and agree on the test cases?
b) define and agree on the testing methodology?
c) create solid test pages
d) do the testing

@jdalton

I ran your DCL test page (http://dl.dropbox.com/u/513327/domload_defer.html) in IE9: expected: number; got: number;

The question is: What is our goal here (in regards to H5BP)? Upgrading all scripts which are already aligned at the document's end with defer? Even if we wouldn't have a DOMContentLoaded discrepancy between browsers we would not gain anything performance-wise. deferreally makes sense when you have like a stubborn CMS that cannot queue scripts for an insertion at the very end. But then again, you cannot generally auto-deferall scripts that you come across as they might contain a document.write or they are accompanied by some (officially) non-deferable inline-script. So the main problem is that even if all browsers would follow one standard, it will never be a no-brainer solution.

What we could do is do some tests just for fun and curiosity (which might be reason enough ;)

Isn't the visual rendering blocking/non-blocking that @jdalton reported expected? The report HTML on the Cuzillion page comes after the external script. So doesn't it make sense that it would be blocked without defer and not blocked with defer?

@robflaherty Good point. This:

…appears after the last <script> in the test page HTML, so it’s not really a test case of <script defer src=foo></body>.

If the defer attribute were defined that it should push the scripts to start executing immediately after it fired the DOMContentLoaded event (like it does in FF), then defer would be useful even at the end of the body, because drastically speeding up DOM-ready is quite effective in improving the "perceived performance" of a site, which makes users think the site actually did load quicker, even if it loaded slower overall.

As it stands, defer seems somewhat more useful in FF than in IE9 and Chrome15.

If "defer" is made the default, will developers get confused that their inline JS is processed before the deferred (external) scripts?

http://www.artzstudio.com/files/Boot/test/benchmarks/script.defer.html

Most sites have a need for inline JS, for example Google Analytics code, page specific initialization, etc.

• update looks like Cuzillion says this should work... :/
  http://stevesouders.com/cuzillion/?c0=hj1hfft2_0_f&c1=hj1hfft2_0_f&c2=hb0hfff0_0_f&t=1313075137650

Couple of other points... it may be worth noting that stylesheet downloading blocks DOMContentLoaded only if the stylesheet is followed by scripts. Adding defer changes this and causes DOMContentLoaded to fire before the stylesheet has finished downloading. Probably not a common scenario but I thought I'd mention it.

Example: http://stevesouders.com/cuzillion/?c0=hc1hfff2_0_f&c1=bj1hfft1_0_f&t=1313073628

Another thing to keep in mind when testing is WebKit's PreloadScanner, which prefetches scripts and runs in just about every real-world scenario. In more cases it's surely tangential but there may be some wacky test cases where it affects results.

I've just run across an issue where I'm loading jquery and jquery-ui in succession, using script tags with defer set on them. And in IE9, this is causing a script error, because apparently IE9 is executing jquery-ui before jquery, which throws the obvious error about "jQuery is undefined".

Has anyone else seen script@defer behave wonky in IE9? I tried it in IE10p2 and it didn't error, but I don't know if that's because it's a bug that was fixed, or if that's an accident of race-condition. Probably the former, but could be the latter.

@getify

can you run a couple of tests with the test page in some IE9 test nodes on Webpagetest.org and publish links to results here?
Txs.

@aaronpeters:

Here's my test page: http://test.getify.com/test-ie-script-defer/

Try that in IE<=9, you get "Fail!". Try it in any other browser-type, get "Pass!". Try it in IE10p2, get "Pass!".

Here's some results, as you requested, from WPT.org

(IE9-Fail) http://www.webpagetest.org/result/110823_TH_1D7F4/

(IE8-Fail) http://www.webpagetest.org/result/110823_PD_1D7F9/

(IE7-Fail) http://www.webpagetest.org/result/110823_RE_1D7FH/

(IE6-Fail) http://www.webpagetest.org/result/110823_JK_1D7FP/

(Chrome-Pass) http://www.webpagetest.org/result/110823_XE_1D7G1/

@getify

txs Kyle. Would love to get involved and participate in further, deeper research.
Will email you.

Fyi, the IE8 waterfall (only looked at this one) shows requests being aborted.
Here is info on why this happens: http://blogs.msdn.com/b/ieinternals/archive/2011/07/18/optimal-html-head-ordering-to-avoid-parser-restarts-redownloads-and-improve-performance.aspx

@aaronpeters:

yeah, the IE8 waterfall does indeed show the requests being canceled, which is inexplicable to me because the structure of the test document is exactly as the article you linked to prescribes (that is, the charset declaration is the first tag in the head, as it should be).

Moreover, the IE6,7, and 9 waterfalls do NOT show the canceled loads, so the canceled load is most likely not the culprit (although is certainly a performance concern).

Even in a canceled load/reload of a script, as the IE8 waterfall shows, one would still expect the browser to hold off on running the correctly downloaded script ("init.js") until it could re-request and successfully download the other two and run them. No matter how you slice it, not running them in order is a failure.

Order preservation is well-defined in the spec for defer -- there's no question that it should be preserving order. As far as I can tell, there is ZERO benefit to defer (as opposed to async) if it doesn't preserve order -- isn't that basically the whole point? So I consider this an example of a failed implementation of defer (long standing too).

If IE10 indeed has fixed this (it seems so, but not confirmed), I won't use defer until IE10 is in use by 95%+ of the IE users out there, so that's gonna be awhile, to say the least.

BTW, my suspicion (unconfirmed) is that maybe it has something to do with loading all 3 scripts from different domains. But I have no explanation as to why that would cause execution order to fail.

FYI, hang.nodester.org now allows you to pass content for testing, e.g. http://hang.nodester.com/test.js?2000&content=window.foo%20%3D%2042; (Thanks, @remy!) This is probably useful for future tests.

I’ve attempted to simplify @getify’s test case here: http://jsbin.com/mathias/inebat Oddly, it seems to pass for me in IE8. Did I do anything wrong?

Update: See @nicjansma’s explaination below. This test passes in IE8 because I didn’t use any code that triggers HTML parsing.

FYI: I'm now not convinced (entirely) that this is IE's fault. I put a console.log() at the top of both jquery, and jquery-ui (both hosted locally now) and they "run" in the right order, but the window.jQuery variable is not defined when jQuery-ui runs, as it should be. It suggests that somehow, some way, jQuery is delaying it's initialization of the window.jQuery variable reference. I can't explain it any further than that at the moment. If anyone has any bright ideas, please do share.

OK, this is officially one of the weirdest WTF's I've ever seen... Check this out (in any IE<=9):

http://test.getify.com/test-ie-script-defer/index-2.html

Look closely at the log box there. It says:

jquery.js top of the file
jquery-ui.js top of the file
ReferenceError: 'jQuery' is undefined
jquery-ui.js bottom of the file
jquery.js bottom of the file

In other words, it appears that IE is suspending execution of jQuery somewhere mid-file, switching over to execute jQuery-UI, finishing it, THEN switching back to jQuery to finish it. I'm really quite shocked at this. What happened to single-threaded "run-to-the-end" JavaScript?

clarification: i wrapped a try/catch around the entire contents of jquery-ui.js because of that "reference" error, so what's actually happening is that jquery-UI is stopping with the error almost immediately, being caught in the try/catch, and at least allowing the final console.log(...) in jquery-ui.js to run, so we see when that file itself is done running.

Side note on script-defer from a bit earlier in the thread... According to spec, script-defer is NOT defined for inline script blocks, contrary to popular belief:

http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-defer

The defer and async attributes must not be specified if the src attribute is not present.

That's what I was trying to say earlier in the thread. Race conditions can exist if you defer external scripts required by inline scripts.

With defer: http://www.artzstudio.com/files/defer-test/defer.html

Without: http://www.artzstudio.com/files/defer-test/normal.html

Yea, that's why I also stated "some (officially) non-deferable inline-script." <- no defer allowed :)

Kyle, maybe the bug you see results from the new Chakra engine being able, or trying to, execute multiple scripts in parallel on multicore machines. See:

http://technet.microsoft.com/en-us/library/gg699435.aspx

The new JavaScript engine takes advantage of multiple CPU cores through Windows to interpret, compile, and run code in parallel.

and http://msdn.microsoft.com/en-us/ie/ff468705.aspx#_cfperformance

The Chakra engine interprets, compiles, and executes code in parallel and takes advantage of multiple CPU cores, when available.

I'd guess that when you bind IE9 to only one single CPU-core everything will be back to normal. You do that by opening the Task Manager (Strg + Shift + Esc), go to processes, right click the corresponding IE9 process, chose "Set Affinity", uncheck all but one checkbox. Or see here:
http://www.addictivetips.com/windows-tips/how-to-set-processor-affinity-to-an-application-in-windows/

Okay, forget it. You get the bug not in IE9.

This is a known bug in IE9 that has been fixed in IE10.

In this case, after the page is done loading and IE starts to run the defer scripts, the first script, jQuery is run, and it starts building the .support object. During this time, it sets an .innerHTML, which (incorrectly) causes IE to think it needs to look for more defer scripts to run. IE starts executing the second defer script, jQuery UI, before the first script has completed, so the jQuery namespace isn't available.

@nicjansma -- do you have any link about that? never heard about this bug before. Also, are you aware/can you confirm that it affects all IE<=9?

I dunno about anyone else, but that bug pretty much seals defer's fate in my mind, at least for a long while. If using defer in markup breaks in IE<=9, apparently for any script which sets innerHTML in the way that jQuery does, then it means you can't use defer until IE<=9 don't matter anymore. For some, I'm sure that's "soon", but for others, that could be years.

Because my organization supports IE9 and I've been asked to look into this, I figure I should throw in a comment even if it's a year ahead. I just put together a test of this in an IE9 VM, and couldn't reproduce the issue discussed; in fact I'm currently considering simply universally adding the "defer" attribute to our scripts.
What could potentially be causing the difference in behavior is that anyone working on this issue is trying to find very, very large javascript files that will always take longer to load than the small script below (which requires the large). JQuery is a popular example, and I'm now wondering if that happens to be doing something that causes glitchy behavior to just IE9; changing the DOM being a possible candidate. My test script was a 1.5MB custom pre-built bundle of the dojo framework, and many AMD module definitions; it's likely that script doesn't do anything to the page until DOMContentLoaded, so it seemed to be working okay.
To try to isolate whether frameworks like jquery are actually specifically relevant to the issue, another test could just involve a 2MB javascript file that just contains many random characters, does nothing, and then sets a flag on window.

so it seemed to be working okay.

I wouldn't build my production strategy on such false assumptions, but YMMV. As far as I'm concerned, everything here about defer is still valid until IE9 stops being supported.

Even in IE10+, defer isn't fully reliable, as it will not work on inline scripts, which is unfortunately still a pretty common occurrence, even for just simple code like activating a social widget or GA tracking script, etc.

Didn't you just write this one earlier in the thread?
http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#attr-script-defer
"The defer and async attributes must not be specified if the src attribute is not present."

Any syncronicity between a defer+src script with an inline script (ie, something running a JQuery function) is coincidential, and undefined browser behavior.

I tend to think of inline scripts (as in, inline between pieces of content, not a single inline script in head that configures your libraries) as archaic deprecated behavior, like conditional HTML comments; , so I'm not surprised that having them in place breaks newer script-loading features.

Hello,

what is the difference between <script async=''async'' & <script async=''

None, really...they're both syntactically accepted because some HTML-writing programs don't follow the Boolean nature of attributes, and because it's required for valid XML.

Attributes like "async" or "disabled" don't actually require an equals sign. It's valid to write <script async> or . Anything inside the equals is pretty much ignored. When checking for those Booleans, JS code usually checks "element.hasAttribute(x)" rather than "element.getAttribute()", so even if it registers as an empty string, it will turn out true.

For posterity sake, let's not clutter up this thread with general support inquiries about web platform features. Please take this discussion to stackoverflow or some other forum where it's more appropriate, and remove the messages here.

An user reported the suggested fix didn't work for him. If other users could confirm this, the original post should be edited so that people who land on it are not misled ;)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had recent activity. Thank you for your contributions.