- From: Ilya Grigorik <igrigorik@google.com>
- Date: Thu, 15 Jan 2015 18:43:48 -0800
- To: Alex Russell <slightlyoff@google.com>
- Cc: Travis Leithead <travis.leithead@microsoft.com>, Mark Nottingham <mnotting@akamai.com>, Yoav Weiss <yoav@yoav.ws>, public-web-perf <public-web-perf@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Jeni Tennison <jeni@jenitennison.com>
- Message-ID: <CADXXVKpbE4saUc_s5ShLtbSExr8-UGBSKOe2ey31xQjxJwORbg@mail.gmail.com>
A bit of handwaving on pros/cons of a ~manifest like approach: + Single URL to represent a bundle of resources (sharing, embedding, etc) + Fetching is uncoupled from manifest: granular caching, revalidation, updates, prioritization.. all of my earlier issues are addressed. + You can make integrity assertions about the manifest and each subresource within it (via SRI) + No complications or competition with HTTP/2: you get the best of both worlds + Can be enhanced with http/2 push where request for manifest becomes the parent stream against which (same origin) subresources are pushed + Works fine with HTTP/1 but subject to regular HTTP/1 HoL concerns: use sharding, etc.. all existing http/1 optimizations apply. + Compatible out of the gate with old servers, new servers can do smart things with it (e.g. CDN can fetch and preload assets to edge) Also, Alex I asked you this earlier, but I don't recall why we ruled it out... Wouldn't rel=import address this? E.g... <link rel="import" href="/lib/brand.pack"> >--- contents of brand.pack ---< <link rel=preload as=image href=logo.png integrity={fingerprint} /> <link rel=preload as=stylesheet href=style.css integrity={fingerprint} /> <link rel=preload as=javascript href=module-thing.js /> ... <link rel=preload as=javascript href=https://my.cdn.com/framework.js /> <script> if (someDynamicClientConditionIsMet()) { var res = document.createElement("link"); res.rel = "preload"; res.href = "/custom-thing"; document.head.appendChild(res); } </script> >------< It feels like we already have all the necessary components to compose the desired behaviors... and more (e.g. dynamic fetches in above example). ig On Thu, Jan 15, 2015 at 5:20 PM, Alex Russell <slightlyoff@google.com> wrote: > That had occurred to me too. Maybe once major impls rip out AppCache > support.... > > On Thu, Jan 15, 2015 at 5:05 PM, Travis Leithead < > travis.leithead@microsoft.com> wrote: > >> Reminds me of: >> >> <html manifest=”/lib/manifest”> >> >> >> >> …in that you get a list of resources to cache for the application. Not >> quite the same, but conceptually similar. Perhaps we could avoid creating a >> new separate concept, and reuse/extend this manifest? I’m sure someone else >> has probably already considered this—apologies for coming in late to the >> discussion. >> >> >> >> *From:* Alex Russell [mailto:slightlyoff@google.com] >> *Sent:* Thursday, January 15, 2015 3:47 PM >> *To:* Ilya Grigorik >> *Cc:* Mark Nottingham; Yoav Weiss; public-web-perf; www-tag@w3.org List; >> Jeni Tennison >> *Subject:* Re: "Packing on the Web" -- performance use cases / >> implications >> >> >> >> Ilya and I had a chance to chat this afternoon and he had a brilliant >> idea: what if there were a preamble section that allowed the package to >> simply be a hint to UA to start fetching a list of (not-included) resources? >> >> >> >> This would let you invoke one with: >> >> >> >> <link rel="package" href="/lib/brand.pack"> >> >> >> >> Note the lack of a "scope" attribute. >> >> >> >> The contents of "brand.back" wouldn't be a resources, but instead is a >> list of URLs to request. This would let a site reduce the number (and >> repetition) of <link rel="prefetch"> tags in the first (crucial bytes). >> This could be done by using the preamble section >> <http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html> of the package >> to include a structured list of URLs to preflight. >> >> >> >> Thoughts? >> >> >> >> >> >> >> >> >> >> On Wed, Jan 14, 2015 at 2:19 PM, Ilya Grigorik <igrigorik@google.com> >> wrote: >> >> On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <slightlyoff@google.com> >> wrote: >> >> On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <igrigorik@google.com> >> wrote: >> >> On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <mnotting@akamai.com >> > wrote: >> >> This doc: >> http://w3ctag.github.io/packaging-on-the-web/ >> says a number of things that about how a Web packaging format could >> improve Web performance; e.g., for cache population, bundling packages to >> distribute to servers, etc. >> >> >> >> tl;dr: I think its introducing perf anti-patterns and is going against >> the general direction we want developers to head. Transport optimization >> should be left at transport layer and we already have much better >> (available today!) solutions for this. >> >> >> >> I'm going to leave comments inline below, but I think your read of this >> is far too harsh, forecloses meaningful opportunities for developers and >> UAs, and in general isn't trying to be as collaborative as I think those of >> us who have worked on the design would hope for. >> >> >> >> Apologies if it came across as overly negative. Mark asked for >> perf-related feedback and that's what I'm trying to provide.. much of which >> I've shared previously in other threads and chats. I do think there are >> interesting use cases here that are worth resolving, but I'm just not >> convinced that a new package streaming format is the right approach: lots >> of potential pitfalls, duplicated functionality, etc. My comments shouldn't >> rule out use cases which are not perf sensitive, but I do think it's worth >> considering the perf implications for cases where it may end up being >> (ab)used. >> >> >> >> ---- some notes as I'm reading through the latest draft: >> >> >> >> (a) It's not clear to me how packages are updated after the initial >> fetch. In 2.1.1. you download the .pack with a CSS file but then request >> the CSS independently later... But what about the .pack? Wouldn't the >> browser revalidate it, detect that the package has changed (since CSS has >> been updated), and be forced to download the entire bundle once over? Now >> we have duplicate downloads on top of unnecessary fetches. >> >> >> >> The presence of the package file is a hint. It's designed to be >> compatible with legacy UAs which may issue requests for each resource, >> which the UA is *absolutely allowed to do in this case*. It can implement >> whatever heuristic or fetch is best. >> >> >> >> That doesn't address my question though. How does my app rev the package >> and take advantage of granular downloads, without incurring unnecessary >> fetches and duplicate bytes? I'm with you on heuristics.. I guess I'm >> asking for some documented examples of how this could/should work: >> >> >> >> a) disregard packages: what we have today.. granular downloads and >> caching, but some queuing limitations with http/1. >> >> b) always fetch packages: you incur unnecessary bytes and fetches >> whenever a single resource is updated. >> >> c) how do I combine packages and granular updates? Wouldn't you always >> incur unnecessary and/or duplicate downloads? >> >> >> >> In general, all bundling strategies suffer from one huge flaw: a >> single byte update in any of its subresources forces a full fetch of the >> entire file. >> >> Assuming, as you mistakenly have, that fetching the package is the only >> way to address the resource. >> >> >> >> I didn't assume that it is, I understand that the proposed method is >> "backwards compatible" and that UA can request granular updates for >> updating resources.. but this takes us back to the previous point -- is >> this only useful for the initial fetch? I'd love to see a good walkthrough >> of how the initial fetch + granular update cycle would work here. >> >> >> >> (b) Packages introduce another HoL bottleneck: spec talks about >> ordering recommendations, but there is still a strict ordering during >> delivery (e.g. if the package is not a static resource then a single slow >> resource blocks delivery of all resources behind it). >> >> >> >> Is the critique -- seriously -- that doing dumb things is dumb? >> >> >> >> I'm questioning why we would be enabling features that have all of the >> highlighted pitfalls, while we have an existing solution that doesn't >> suffer from the same issues. That, and I'm wondering if we can meet the >> desired use cases without introducing these gotchas -- e.g. do we need the >> streaming package at all vs. some form of manifest~like thing that defers >> fetching optimizations to the transport layer. >> >> >> >> (c) Packages break granular prioritization: >> >> >> >> Only assuming that your server doesn't do something smarter. >> >> >> >> One of the great things about these packages is that they can *cooperate* with >> HTTP/2: you can pre-fill caches with granular resources and entirely avoid >> serving packages to clients that are savvy to them. >> >> >> >> Can you elaborate on the full end-to-end flow of how this would work: >> initial package fetch for prefill, followed by...? >> >> >> >> Would the UA unpack all the resources from a package into individual >> cache entries? Does it retain the package file itself? What's the process >> for revalidating a package? Or is that a moot question given that >> everything is unpacked and the package itself is not retained? But then, >> how does the UA know when to refetch the package? >> >> >> >> As an aside: cache prefill is definitely an interesting use case and >> comes with lots of gotchas... With http/2 we have the push strategy and the >> client has ability to disable it entirely; opt-out from specific pushed >> resources (send a RST on any stream - e.g. already in cache); control how >> much is pushed (via initial flow window)... because we had a lot of >> concerns over servers pushing a lot of unnecessary content and eating up >> users BW/data. With packages the UA can only make a binary decision of >> fetch or no fetch, which is a lot less flexible. >> >> >> >> Your server can even consume packages as an ordered set of resources >> to prioritize the sending of (and respond with no-op packages to clients >> for which the package wouldn't be useful). >> >> >> >> Does this offer anything extra over simply delivering individual >> resources with granular caching and prioritization available in http/2? >> >> >> >> From what I can tell, the primary feature is that the client doesn't >> necessarily know what all the resources it may need to download are... For >> which we have two solutions: http/2 push, or we teach the client to learn >> what those resource URIs are and initiate the requests from the client >> (regardless of http version). >> >> >> >> ig >> >> >> > >
Received on Friday, 16 January 2015 02:44:56 UTC