Re: Executing script-inserted external scripts in insertion order

?> Tony Gentilcore's reply to public-html bounced, so I'm quoting it here in 
full with his permission.
>> Re: Changing WebKit to preserve order for script-inserted external 
>> scripts.
>> In short, I believe that the current WebKit behavior results in the
>> best performance for current web content with no known major compat
>> problems.

To try and load scripts in parallel but control the execution order, we have 
only one trick available to us in Webkit (and IE)... "preloading". As I've 
explained in detail earlier in the thread, "preloading" is just a hack using 
non-standard tricks and is susceptible to complete breakage if the script in 
question is not sent with proper caching headers (over 70% of scripts 
estimated to have improper caching headers). *This is true EVEN if we 
switched to using the <link rel=prefetch> approach.*

Yes, loading in parallel and executing as soon as possible is "best 
performance" if there are *no* dependencies between the scripts, but there 
are LOTS and LOTS of sites and use-cases out there which do load things with 
dependencies between the scripts. They want to be able to load in parallel 
(for better performance) but still control execution order (to prevent 
breakage). See other recent messages in this thread for examples of that 
kind of usage.

>> Expanding on that, my opinion is that developers who don't understand
>> the intricacies of script execution order, typically use
>> parser-inserted scripts which preserve order by default. In my
>> experience working on Google web properties, developers turn to
>> script-inserted scripts only when they want a performance gain from
>> async behavior.

This assumption may have been true at Google... but it ignores the movement 
toward using sophisticated performance-oriented script loaders like LABjs, 
which are trying to make it easy (for any site on the web) to dynamically 
load scripts in parallel but preserve order for dependencies where 
necessary. LABjs is trying to hide most of this intricacies from the 
end-developer, letting them just use a simple ".wait()" in the change to 
indicate that execution order is important.

>> If we were to change the behavior of script-inserted external
>> script to preserve the order, I suspect we'd just take a perf hit with
>> no concrete compat benefit.

We're not asking you to CHANGE the behavior per se, but ADD TO the 
behavior... basically, we want *dynamically inserted* scripts to respect the 
value of the `async` property. If it's set to `false` (whether or not that's 
default is another issue), then dynamically inserted scripts should preserve 
order with each other. If it's set to `true`, then they should continue to 
work the way they already work in Webkit/IE.

Again, the question of which behavior is default is a separate issue. What's 
most important is that *both* `async=true` and `async=false` behaviors be 
available to *dynamically inserted scripts* so that dynamic script loaders 
like LABjs can use whichever behavior is needed.

>> Re: Prefetching scripts with type=text/cache.
>> As of http://trac.webkit.org/changeset/67245, WebKit is in compliance
>> with HTML5 and no longer hits the network for scripts it doesn't plan
>> to execute. <link rel=prefetch> should be used for prefetching.
>
> About prefetching: From the changeset you linked to, it seems to me that 
> WebKit trunk is now breaking existing LABjs and RequireJS in their ordered 
> modes.

I can verify this will in fact break LABjs for the use case in question.

To recap, the use case is: loading *in parallel* more than one script, at 
least one of which is from a remote domain, and needing to control the 
execution order of some or all of the scripts for dependency reasons.

--Kyle

Received on Friday, 15 October 2010 13:57:39 UTC