W3C home > Mailing lists > Public > public-html@w3.org > October 2010

Re: Executing script-inserted external scripts in insertion order

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 17 Oct 2010 21:36:06 -0700
Message-ID: <AANLkTinPFNCYVQzucf0dNyTWwbmJadBtwedbD1ncxndj@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Getify <getify@gmail.com>, public html <public-html@w3.org>
On Sun, Oct 17, 2010 at 9:13 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/17/10 11:59 PM, Adam Barth wrote:
>> Can you provide examples of sites that break?
> He already did earlier in this thread, no?

Sorry, Tony's having trouble getting his email through to the list.
He looked at (some of) the sites listed before and didn't see any
problems.  Maybe we need to study them in more detail.

>>> I think it even further underscores the need for a spec change (that all
>>> the
>>> browsers can agree on) which gives a reliable and straightforward answer
>>> to
>>> "parallel-load-serial-execute" use case in a performance-oriented and
>>> feature-testable way.
>> Isn't this what defer does?
> 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, which is considerably earlier:


That's seems like a good balance of performance and predictability.
The scripts are loaded in parallel, but executed in order relative to
each other and relative to inline / external scripts in the document.

>>> Since Webkit has made this change that is in a non-compat way with
>>> existing
>>> content, are they willing to support the proposed change as a
>>> feature-testable addition (to spec and the browsers) that provides an
>>> answer
>>> to the use-case?
>> 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.
> 1)  Which change(s) are we talking about here??  There are at least 3
> mutually exclusive proposed changes at this point, I think.

Honestly, I'm lost w.r.t. all the proposals.  There was something
about an ordered property that I never understood.  There was a
proposal to make non-async script-inserted scripts have order relative
to themselves (and possibly relative to other things).  There was a
proposal to have async have different semantics on parser- and
script-inserted scripts.

> 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.  The proposal was
to add an ordering dependency between these scripts.  This has been
advocated by web performance experts for a while.  For example, read
this article:


In many situations, the Script DOM Element is a good choice. It works
in all browsers, doesn’t have any cross-site scripting restrictions,
is fairly simple to implement, and is well understood.

Received on Monday, 18 October 2010 04:37:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:06 UTC