On Mon, Dec 10, 2012 at 11:52 PM, Maciej Stachowiak <m...@apple.com> wrote: > On Dec 3, 2012, at 11:19 PM, Adam Barth <w...@adambarth.com> wrote: >> On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak <m...@apple.com> wrote: >>> On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) <willc...@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
