Re: Executing script-inserted external scripts in insertion order

On Sun, Oct 17, 2010 at 9:31 PM, Getify <getify@gmail.com> wrote:
> ?> Can you provide examples of sites that break?  It's easier to reason
>>
>> about concrete broken sites than about these things in the abstract.
>
> I've provided several examples earlier in this thread of sites that will
> break either with the Mozilla change (ordering) or the Webkit change (not
> fetching invalid mime-type scripts). Briefly:
>
> http://zappos.com
> http://blog.getify.com
> http://flensed.com

See my previous email.  Perhaps tonyg would be willing to re-test
these sites to see if we can reproduce the breakage.  Have you see the
breakage yourself using a nightly build, or are you just assuming that
it will happen?

I tried a WebKit nightly cut at r69918 on 17 October 2010.  I went to
Zappos, found a nice pair of red running shoes, and added them to my
cart.  Is there something specific I should do to produce the issue?

>> Isn't this what defer does?  I guess you're saying it's not
>> performance-oriented?
>
> `defer` tells the browser to wait until the DOM is finished before executing
> the scripts. Yes, it does eventually execute them in order, but pinning
> scripts' execution to the DOM is where it fails to meet the performance
> optimization mark as desired.

There's a trade-off between performance and predictability.  Defer is
predictable.  Async is performant.  You're asking for a middle ground,
which might be useful.  However, you'll probably get better
performance if you just concatenate all your dependent scripts into a
single network request and use async.

> It's also unclear if `defer` scripts delay
> *download* until after the DOM (some tests in some browsers suggest so) or
> just execution, which would be even less "performance-oriented". Moreover,
> it's also unclear if `defer` scripts being injected long after DOM would
> still maintain order, etc.

I'm not sure why these things are unclear.  They do maintain order.
It's clearly more performant to fetch them ahead of time.  If some
user agents don't do those things, I'd recommend that they change to
do that.

>> I believe tonyg said that he thought the proposed change would slow
>> down a bunch of real-world web sites that use script-inserted scripts
>> to achieve parallel loading in existing browsers.  Generally, folks
>> aren't going to be that exciting about slowing down web sites.
>
> Here's why I assert that the change in question will NOT slow down existing
> sites for IE/Webkit: because I'm arguing that I think it makes sense
> compat-wise for browsers (and spec) to implement `true` as the default value
> for `async`, but *only* on script-inserted scripts. Of course, that makes
> the default opposite of what how it defaults to `false` on parser-inserted
> scripts, which might seem odd at first glance but I think is logically
> defendable upon examination.

That seems like an independent question from whether we fetch scripts
with non-executable MIME types.  How does that solve Firefox's
problem?  Why would they be able to implement that but not implement
what the spec currently says?

On Sun, Oct 17, 2010 at 9:48 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/18/10 12:36 AM, Adam Barth wrote:
>>> No, because that defers the scripts to onload.  The goal here is to
>>> execute
>>> a set of scripts as soon from now as possible, but in a particular order.
>>
>> I believe defer doesn't wait until onload.  It just wants for parsing
>> to be finished
>
> Fair, it defers to DOMContentLoaded.  Which still introduces an undesirable
> ordering dependency on parser-created scripts, if nothing else.
>
>> That's seems like a good balance of performance and predictability.
>
> Good for whom?

For authors.  It's much easier to author pages that use defer than
pages that use async because you don't have any race conditions to
worry about.  Everything happens at a predictable time and you get
better performance than if you didn't use defer.

If you want to go as fast as possible, then you should use async, but
you're going to have to be careful to manage dependencies between your
scripts and between your scripts and the DOM.

>> There was a proposal to make non-async script-inserted scripts have order
>> relative to themselves
>
> Yes.
>
>> There was a proposal to have async have different semantics on parser- and
>> script-inserted scripts.
>
> Also yes.  This proposal was a refinement of the "make non-async
> script-inserted scripts have order" proposal.
>
> The third proposal was to require in-order execution of script-inserted
> scripts, period.  It sounds like you're unwilling to do that; fine.
>
>>> 2)  I'd be interested in mention of actual sites that are slowed down by
>>> the
>>> changes in question (esp. the one where async is just allowed to apply to
>>> script-inserted stuff.
>>
>> Well, every site on the Internet that uses more than one
>> script-inserted script without an async attribute.
>
> And in which the timing at which the scripts run matters in a meaningful way
> (in that, say, the scripts aren't just loading API), right?

Sure.  Scripts that are meant to do something, such add add
functionality to the page.  That functionality won't be available
until the scripts execute, which we'd like to do as soon as possible
without breaking the page.

>> The proposal was to add an ordering dependency between these scripts.
>
> There have been three proposals.  At least one doesn't add such a dependency
> by default, but DOES allow the page to add it if desired.

Isn't that the one that's been withdrawn?

>> This has been advocated by web performance experts for a while.  For
>> example, read this article:
>>
>> http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/
>
> I'd love to, but all it says is:
>
>  Error establishing a database connection

Hum...  Steve's blog was up a moment ago when I posted that email.  Oh
well.  He basically goes through all the ways of executing
non-blocking scripts that were feasible in April 2009 and recommends
using script-inserted script elements.

> In any case, given your objections so far I think I'm on safe ground in
> saying that either you're not evaluating Henri's proposal to make async work
> on script-inserted scripts, or you misunderstood the proposal...

I'm happy to look at a proposal fresh if you'd like to explain it in
an unambiguous way.  AFACT, async already works on script-inserted
scripts, both in the spec and in the WebKit implementation.  However,
it's possible I'm confused about which proposal you're currently
advocated for.

Adam

Received on Monday, 18 October 2010 05:00:45 UTC