- From: Ilya Grigorik <igrigorik@google.com>
- Date: Mon, 19 Jan 2015 13:38:31 -0800
- To: "Nottingham, Mark" <mnotting@akamai.com>
- Cc: Alex Russell <slightlyoff@google.com>, Travis Leithead <travis.leithead@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Marcos Caceres <marcos@marcosc.com>, public-web-perf <public-web-perf@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Jeni Tennison <jeni@jenitennison.com>
- Message-ID: <CADXXVKoQT3MLNLnS_+587Pj97UgcKKf1ArfndEJPyD8Ng7havQ@mail.gmail.com>
On Sun, Jan 18, 2015 at 10:10 PM, Nottingham, Mark <mnotting@akamai.com> wrote: > Well, I'm liking this a lot more than the current proposal. What's the > intersection with <https://w3c.github.io/manifest/>? CC:ing Marcos. > Seems like they're independent mechanisms. From what I understand, manifest spec is geared towards an "installable application", whereas the packages we're describing here are simply arbitrary bundles of files.. For example, a JS module and its dependencies, a collection of images, or any arbitrary collection of files [1], and the primary value here is ability to provide a single URL to ease distribution, sharing, etc. [1] http://w3ctag.github.io/packaging-on-the-web/#downloading-data-for-local-processing > > On 16 Jan 2015, at 1:43 pm, Ilya Grigorik <igrigorik@google.com> wrote: > > > > 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 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 Monday, 19 January 2015 21:39:39 UTC