W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 7 Jan 2013 17:05:28 -0800
Message-ID: <CAJE5ia8bVT4MNjqTcDQ+=24=Ub2Pod7X1Kk9d9m5v6UixZ4Ayw@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: whatwg@whatwg.org, William Chan (陈智昌) <willchan@chromium.org>
On Mon, Dec 10, 2012 at 11:52 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Dec 3, 2012, at 11:19 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:
>>>> Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses
>>>> prioritized multiplexing of streams.
>>>
>>> It seems to me like SPDY could make this case work better:
>>>
>>> <script async src="path/to/script-part1.js"></script>
>>> <script async src="path/to/script-part2.js"></script>
>>> <script async src="path/to/script-part3.js"></script>
>>>
>>> Specifically the individual script chunks could be ordered and prioritized such that all of script-part1.js transfers before any of script-part3.js. That's harder to do with HTTP because the scripts could be loading on wholly separate HTTP connections, while SPDY will use one connection to the server.
>>>
>>> That being said, I do not know if SPDY will actually achieve this. Presumably it makes sense for it to serialize within a given priority level, at least a priority level that's likely to correspond to resources that are only atomically consumable, like scripts. But I don't know if SPDY implementations really do that.
>>
>> It also has disadvantage (3):
>>
>> ---8<---
>> (3) This approach requires the author who loads the script to use
>> different syntax than normally used for loading script.  For example,
>> this prevents this technique from being applied to the JavaScript
>> libraries that Google hosts (as described by
>> <https://developers.google.com/speed/libraries/>).
>> --->8---
>
> Yes, but I presumed that multiple script tags is less deviation than the iframe approach. Perhaps that is not the case. Note that in the case of systematically named parts, a single inline script could document.write() the relevant sequence of external <script> tags, if verbosity is the concern. But it would indeed be different.
>
> Do you expect the multipart idea would work with no syntax change in the markup currently embedding the libraries? If so, how? Content negotiation? UA sniffing?

Yes, using UA sniffing at first and eventually dropping support for old clients.

Adam
Received on Tuesday, 8 January 2013 01:06:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT