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

I did not explain this in more detail because I did not want to hijack this
thread to discuss SPDY prioritization. But we've indeed considered
situations like you've mentioned. Please refer to
https://groups.google.com/d/topic/spdy-dev/-d9Auoun4HU/discussion. But your
insight that in many situations it's not better to interleave response
data, as would be done by separate TCP connections, is indeed spot on.

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.


Just to be clear, you mean that script-part1.js completes before
script-part2.js which completes before script-part3.js, right?


>
> 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's more complicated than what you indicate here. We discuss this in our
SPDY/4 prioritization proposal and also in the aforementioned discussion
thread.

Also note that, even though Adam didn't mention it in his initial email,
correct prioritization is one motivation for this proposal, since it tries
to remove the necessity of using an <iframe> instead of a normal <script>,
since certain browsers (like Chromium) will assign different priorities
here:
https://code.google.com/p/chromium/source/search?q=DetermineRequestPriority&origq=DetermineRequestPriority&btnG=Search+Trunk.
I wrote up a more detailed discussion of this topic in
https://insouciant.org/tech/resource-prioritization-in-chromium/.


>  - Maciej
>
>
> > Generally speaking, a browser will map
> > a single resource request to a single stream, which would prevent chunked
> > processing by the browser without multipart/mixed. One could imagine
> > working around this by splitting the single resource into multiple
> > resources, and then relying on SPDY priorities to ensure sequential
> > delivery, but that is suboptimal due to having limited priority levels (4
> > in SPDY/2, 8 in SPDY/3), and many of them are already used to indicate
> > relative priority amongst resource types (
> >
> https://code.google.com/p/chromium/source/search?q=DetermineRequestPriority&origq=DetermineRequestPriority&btnG=Search+Trunk
> > ).
> >
> >
> > On Mon, Dec 3, 2012 at 1:40 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >
> >> On Mon, Dec 3, 2012 at 10:14 PM, Adam Barth <w3c@adambarth.com> wrote:
> >>> The HTTP server would then break script.js into chunks that are safe
> >>> to execute sequentially and provide each chunk as a separate MIME part
> >>> in a multipart/mixed response.
> >>
> >> Is it expected that SPDY will take much longer than getting this
> >> supported in all browsers? Or am I missing how SPDY will not address
> >> this problem?
> >>
> >>
> >> --
> >> http://annevankesteren.nl/
> >>
>
>

Received on Tuesday, 4 December 2012 06:44:46 UTC