Re: "Packing on the Web" -- performance use cases / implications

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 01:21:17 UTC