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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alex Russell-4
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 <[hidden email]> wrote:
On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]> wrote:
On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]> wrote:
On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Travis Leithead-2

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:[hidden email]]
Sent: Thursday, January 15, 2015 3:47 PM
To: Ilya Grigorik
Cc: Mark Nottingham; Yoav Weiss; public-web-perf; [hidden email] 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 <[hidden email]> wrote:

On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]> wrote:

On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]> wrote:

On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]> 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

 

Reply | Threaded
Open this post in threaded view
|

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

Alex Russell-4
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 <[hidden email]> 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:[hidden email]]
Sent: Thursday, January 15, 2015 3:47 PM
To: Ilya Grigorik
Cc: Mark Nottingham; Yoav Weiss; public-web-perf; [hidden email] 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 <[hidden email]> wrote:

On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]> wrote:

On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]> wrote:

On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]> 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

 


Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2
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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
Sent: Thursday, January 15, 2015 3:47 PM
To: Ilya Grigorik
Cc: Mark Nottingham; Yoav Weiss; public-web-perf; [hidden email] 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 <[hidden email]> wrote:

On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]> wrote:

On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]> wrote:

On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]> 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

 



Reply | Threaded
Open this post in threaded view
|

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

Nottingham, Mark
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.

(WARNING: USER AT KEYBOARD UNDER INFLUENCE OF JETLAG)


> On 16 Jan 2015, at 1:43 pm, Ilya Grigorik <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, January 15, 2015 3:47 PM
> To: Ilya Grigorik
> Cc: Mark Nottingham; Yoav Weiss; public-web-perf; [hidden email] 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 <[hidden email]> wrote:
>
> On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]> wrote:
>
> On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]> wrote:
>
> On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]> 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
>
>  
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2
On Sun, Jan 18, 2015 at 10:10 PM, Nottingham, Mark <[hidden email]> 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.

 
 
> On 16 Jan 2015, at 1:43 pm, Ilya Grigorik <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, January 15, 2015 3:47 PM
> To: Ilya Grigorik
> Cc: Mark Nottingham; Yoav Weiss; public-web-perf; [hidden email] 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 <[hidden email]> wrote:
>
> On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]> wrote:
>
> On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]> wrote:
>
> On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]> 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
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

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

Marcos Caceres-4



On January 20, 2015 at 7:40:36 AM, Ilya Grigorik ([hidden email]) wrote:

> On Sun, Jan 18, 2015 at 10:10 PM, Nottingham, Mark  
> wrote:
>  
> > Well, I'm liking this a lot more than the current proposal. What's the
> > intersection with ? 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.

Yes, this is also my impression; they have different purposes. I'm aware the name "web manifest" leads to confusion.  

Reply | Threaded
Open this post in threaded view
|

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

Martin Thomson-3
In reply to this post by Alex Russell-4
On 15 January 2015 at 15:46, Alex Russell <[hidden email]> wrote:
> 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?

I like the idea, but I keep being told by people here that this whole
"packaging for the web" thing is not a performance feature, but a
usability one.  This rather emphatically establishes it as a
performance feature.

There seems to be a disconnect somewhere.  Maybe these are independent
directions to pursue.

(To preempt the risk of re-invention, here's a useful link:
https://tools.ietf.org/html/rfc6690  Don't let the context confuse
you.)

Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2

On Tue, Jan 20, 2015 at 10:46 AM, Martin Thomson <[hidden email]> wrote:
I like the idea, but I keep being told by people here that this whole
"packaging for the web" thing is not a performance feature, but a
usability one.  This rather emphatically establishes it as a
performance feature.

Martin, are you commenting on the original or the new proposal that removes payloads from the package? FWIW, I think the new proposal (just the URLs of resources, no payloads), removes the performance concerns and defers them to the transport layer (where they belong)... which leaves us with just usability - e.g. a single URL for sharing/distribution of some bundle of files.

ig

Reply | Threaded
Open this post in threaded view
|

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

Martin Thomson-3
On 20 January 2015 at 14:15, Ilya Grigorik <[hidden email]> wrote:

> On Tue, Jan 20, 2015 at 10:46 AM, Martin Thomson <[hidden email]>
> wrote:
>>
>> I like the idea, but I keep being told by people here that this whole
>> "packaging for the web" thing is not a performance feature, but a
>> usability one.  This rather emphatically establishes it as a
>> performance feature.
>
>
> Martin, are you commenting on the original or the new proposal that removes
> payloads from the package? FWIW, I think the new proposal (just the URLs of
> resources, no payloads), removes the performance concerns and defers them to
> the transport layer (where they belong)... which leaves us with just
> usability - e.g. a single URL for sharing/distribution of some bundle of
> files.

I refer to the new suggestion.  This new proposal is an incomplete
replacement for the incumbent proposal.

>From discussions at Mozilla, the primary advantage of packaging was
the usability issue.  In fact, there seems to be a moderate amount of
antipathy toward addressing performance problems using bundling.  For
one, bundling encourages patterns we've been actively discouraging.

Your and Alex's proposal removes some of those concerns, which makes
it a definite improvement.  That's not an endorsement though.

Reply | Threaded
Open this post in threaded view
|

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

Yves Lafon
In reply to this post by Ilya Grigorik-2
On Thu, 15 Jan 2015, Ilya Grigorik 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

Well, HTTP2 is using a dependency graph now, how about this manifest be a
serialized version of it? It could help in the case of an HTTP/1.1 client
talking to an HTTP/1.1->HTTP2 gateway/cache to do prioritization.

But one use case of the package format was to be able to send the whole
package instead of the first URL. In your proposal you still have to
generate all requests.

> + 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 <[hidden email]>
> 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 <
>> [hidden email]> 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:[hidden email]]
>>> *Sent:* Thursday, January 15, 2015 3:47 PM
>>> *To:* Ilya Grigorik
>>> *Cc:* Mark Nottingham; Yoav Weiss; public-web-perf; [hidden email] 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 <[hidden email]>
>>> wrote:
>>>
>>>   On Tue, Jan 13, 2015 at 3:35 PM, Alex Russell <[hidden email]>
>>> wrote:
>>>
>>>   On Tue, Jan 13, 2015 at 2:18 PM, Ilya Grigorik <[hidden email]>
>>> wrote:
>>>
>>>  On Wed, Jan 7, 2015 at 8:25 AM, Mark Nottingham <[hidden email]
>>>> 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
>>>
>>>
>>>
>>
>>
>

--
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves


Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2
On Tue, Jan 20, 2015 at 3:56 PM, Martin Thomson <[hidden email]> wrote:
On 20 January 2015 at 14:15, Ilya Grigorik <[hidden email]> wrote:
> On Tue, Jan 20, 2015 at 10:46 AM, Martin Thomson <[hidden email]>
> Martin, are you commenting on the original or the new proposal that removes
> payloads from the package? FWIW, I think the new proposal (just the URLs of
> resources, no payloads), removes the performance concerns and defers them to
> the transport layer (where they belong)... which leaves us with just
> usability - e.g. a single URL for sharing/distribution of some bundle of
> files.

I refer to the new suggestion.  This new proposal is an incomplete
replacement for the incumbent proposal.

Can you elaborate on what the missing components are?
 
From discussions at Mozilla, the primary advantage of packaging was
the usability issue.  In fact, there seems to be a moderate amount of
antipathy toward addressing performance problems using bundling.  For
one, bundling encourages patterns we've been actively discouraging.

Yes, exactly same concerns here. Bundling response bodies introduces far too many issues and perf pitfalls.

On Wed, Jan 21, 2015 at 2:07 AM, Yves Lafon <[hidden email]> wrote:
On Thu, 15 Jan 2015, Ilya Grigorik 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

Well, HTTP2 is using a dependency graph now, how about this manifest be a serialized version of it? It could help in the case of an HTTP/1.1 client talking to an HTTP/1.1->HTTP2 gateway/cache to do prioritization.

This is a slight tangent, but I believe we need to (a) teach fetch() API to communicate dependencies to the net stack, and (b) we need to surface fetch-settings attribute (or some such) on elements to allow for this in declarative markup as well. With (a) and (b) in place, we can "serialize" the dependency graph via vanilla <link> and fetch() calls. 

With that in mind.. *Alex/Jeni:* can you elaborate on why or why not <link rel=import> as I outlined above [1] is not sufficient to express a "package"? It seems like it provides all the necessary pieces already, plus more...
 
But one use case of the package format was to be able to send the whole package instead of the first URL. In your proposal you still have to generate all requests.

Yes, and I strongly believe that's the right behavior if the consumer of that package is a browser and/or any tool that can initiate fetches programmatically --  doing so allows it to perform granular fetching, caching, revalidation, prioritization, resolve duplicate sub-dependencies between subresources across different packages, ..., and so on. 

ig

Reply | Threaded
Open this post in threaded view
|

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

Martin Thomson-3
On 21 January 2015 at 10:28, Ilya Grigorik <[hidden email]> wrote:
> Can you elaborate on what the missing components are?

The ability to take a meta-resource and treat it as a single unit.
Packaging, basically.

If the intent is to improve the performance of various applications by
ensuring that a user agent has more information to use in deciding to
load the resources the application depends on, then the effort needs a
new name.

Yves is right to identify priority as a part of that.

Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2

On Wed, Jan 21, 2015 at 10:38 AM, Martin Thomson <[hidden email]> wrote:
On 21 January 2015 at 10:28, Ilya Grigorik <[hidden email]> wrote:
> Can you elaborate on what the missing components are?

The ability to take a meta-resource and treat it as a single unit.
Packaging, basically.

I believe this is still satisfied. The browser (and/or any other tool) fetches a single resource, which in turn triggers some cascade of background actions that fetch necessary subresources. 

Perhaps we just need a different name to describe this.. In effect, we're describing something like NPM's package.json [1] or Ruby's gemspec [2]. Except, I'm not even sure we need to define a new format for this, since an HTML page linked via <link rel=import> can deliver everything we need.

ig


Reply | Threaded
Open this post in threaded view
|

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

Martin Thomson-3
On 21 January 2015 at 10:54, Ilya Grigorik <[hidden email]> wrote:
> I believe this is still satisfied. The browser (and/or any other tool)
> fetches a single resource, which in turn triggers some cascade of background
> actions that fetch necessary subresources.

I'm talking about the use cases that .zip files satisfy, not that.  I
don't know why separating these is a problem.

I'm talking about having my NPM module as a single unit (without the
usual minification+concatenation mess we see for JS modules today), or
I want to email a web page to someone, that sort of thing.

Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2

On Wed, Jan 21, 2015 at 11:21 AM, Martin Thomson <[hidden email]> wrote:
I'm talking about the use cases that .zip files satisfy, not that.  I
don't know why separating these is a problem.

Looking at the cited use cases in [1]... 2.1, 2.2, and 2.3 do not need bundling and are *much* better handled by the UA fetching granular resources based on the description in the package/manifest. In fact, even for 2.4 it's not strictly necessary: the package contents can be downloaded into a folder without forcing bundling within the package request. I think we need to revisit the use cases and clarify their intent... 

Reply | Threaded
Open this post in threaded view
|

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

Nottingham, Mark

> On 22 Jan 2015, at 7:54 am, Ilya Grigorik <[hidden email]> wrote:
>
>
> On Wed, Jan 21, 2015 at 11:21 AM, Martin Thomson <[hidden email]> wrote:
> I'm talking about the use cases that .zip files satisfy, not that.  I
> don't know why separating these is a problem.
>
> Looking at the cited use cases in [1]... 2.1, 2.2, and 2.3 do not need bundling and are *much* better handled by the UA fetching granular resources based on the description in the package/manifest. In fact, even for 2.4 it's not strictly necessary: the package contents can be downloaded into a folder without forcing bundling within the package request. I think we need to revisit the use cases and clarify their intent...

+1.


--
Mark Nottingham    [hidden email]    https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

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

Ilya Grigorik-2
For anyone interested in following along: https://github.com/w3ctag/packaging-on-the-web/issues/23

On Wed, Jan 21, 2015 at 2:12 PM, Nottingham, Mark <[hidden email]> wrote:

> On 22 Jan 2015, at 7:54 am, Ilya Grigorik <[hidden email]> wrote:
>
>
> On Wed, Jan 21, 2015 at 11:21 AM, Martin Thomson <[hidden email]> wrote:
> I'm talking about the use cases that .zip files satisfy, not that.  I
> don't know why separating these is a problem.
>
> Looking at the cited use cases in [1]... 2.1, 2.2, and 2.3 do not need bundling and are *much* better handled by the UA fetching granular resources based on the description in the package/manifest. In fact, even for 2.4 it's not strictly necessary: the package contents can be downloaded into a folder without forcing bundling within the package request. I think we need to revisit the use cases and clarify their intent...

+1.


--
Mark Nottingham    [hidden email]    https://www.mnot.net/