Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Meta] A long term plan for subresource loading #648

Open
13 of 19 tasks
hayatoito opened this issue Apr 9, 2021 · 8 comments
Open
13 of 19 tasks

[Meta] A long term plan for subresource loading #648

hayatoito opened this issue Apr 9, 2021 · 8 comments

Comments

@hayatoito
Copy link
Collaborator

hayatoito commented Apr 9, 2021

Hi folks!

Let us share the current status and a future plan about Subresource Loading with Web Bundles.

Last update: Apr 2022

Status

  • We're doing an origin trial in Chrome (M90 - M101). Landing page.

If we don't find any significant issue in OT and this feature is promising, as the next step, we'll work on addressing any
blocking issues or support feature requests, considering feedback from OT, so that we can ship
MVP (v1).

Tentative plan (No ETA):

Note: The following mentions only features. Any standard works or other tasks are not included.

v1

MVP, which proves that bundling multiple resources improves the loading performance than loading multiple resources separately using web native bundling format.

We consider MVP should be shipped with these features.

v2

To cover more wider use cases, especially improving cache efficiency of each resources.
There are several proposals in this area and we'll explore this area in v2.

v3 (Strawperson ideas, which are not triaged well yet)

  • Resource Hints with webbundle
    • <link rel=prefetch-for-navigation href=”//example.com/nextpage.wbn” page=”//example.com/nextpage.html”>
    • Needs a concrete proposal.
  • Content Addressable Bundles

We'll try to keep this plan up-to-date.

@hayatoito
Copy link
Collaborator Author

We've split the previous explainer into the core part and the extension part (PR #645).

@littledan

We've heard that you would work on Resource Batch Preloading proposal.

We are wondering how the current core part is close enough so that Resource Batch Preloading can be explained based on the current core part (with v1 features).

If you find something which might make it difficult for us to have a Resource Batch Preloading proposal, we'd appreciate your feedback!

Regarding syntax, we've not decided anything about a new <script type=xxxx>....</script> syntax. It would be nice that we can have a good syntax which can be used either in v1 or Resource Batch Preloading proposal without much difference. We'd appreciate if you have any ideas!

Thanks!

@littledan
Copy link
Contributor

This outline and layering looks good to me. Here is my view of next steps on my side (to rephrase what I wrote in WICG/bundle-preloading#21):

  • Now that the IETF WPACK WG has adopted the bundled responses format, a new repository will be created for the bundle format. IETF WPACK WG will schedule an interrum meeting to discuss further format issues that you listed above. I am available to help @jyasskin with this repository if needed--I think it could be useful to include some of the text in the resource-bundles repository there.
  • The "resource bundles" repository will transition to being the "batch prefetching" repository, to house the subset-based loading technique, now that the format is developed elsewhere. @cjtenny and I plan to work on the core proposal and have a document to share in a week or two. We apologize for our delay. This document will contain all concrete API surface details.

The API I was picturing looks quite similar to your Chromium design doc with the exception of the cache name, which I asked you about in a doc comment. What was the motivation for using a named cache, rather than having these simply be entries in the main HTTP cache?

@horo-t
Copy link
Collaborator

horo-t commented Apr 15, 2021

The API I was picturing looks quite similar to your Chromium design doc with the exception of the cache name, which I asked you about in a doc comment. What was the motivation for using a named cache, rather than having these simply be entries in the main HTTP cache?

It is because the prototype CL is using Cache Storage to store each resources. If we will use the HTTP cache, we don’t need this cache name field.
But there are some benefits of using Cache Storage. The web developers can manipulate the resources in the cache using Cache Storage APIs. And also we already have good DevTools support for Cache Storage.

@ShivanKaul
Copy link

This is a little late, but some feedback on the plan:

  1. Are there use cases apart from the WebBundles for Ad Serving #624 use case enabled by the UUID scheme? That just sounds bad overall for the web - "The ad JS can render an ad by setting the src of an iframe to a resource that's inside the bundle, but nothing on the client can read or modify the ad HTML because the resources are opaque." This is exactly the fear articulated in https://brave.com/web-standards-at-brave/3-web-bundles/ and Correct / real URLs should be enforced, to avoid breaking adblockers #551
  2. Subsetting via preloading as in https://github.com/WICG/bundle-preloading/ sounds much better for letting the client decide which resources it might not want to fetch (both for caching and content blocking and just overall preventing unnecessary bytes from being downloaded). I'm very disappointed that that is not making it into v1.

Please let me know if I'm mistaken in my understanding, it's hard keeping up with the several documents related to Web Bundles/WPACK.

@hayatoito
Copy link
Collaborator Author

Thanks for the feedback!

Re 1:
#623 has a proposal using <iframe opaque>-ish, however, it seems no one is actively working on that. It seems we need a person who drives an alternative idea.

Re 2:
That's surely targeted in v2. We hope we can cover more wider use cases there.

@jeffkaufman
Copy link

jeffkaufman commented Nov 11, 2021

Re 1: from an ads / #624 perspective, something similar to subresource bundles where extensions were able to read/modify the ad HTML would be completely fine. The goal is to isolate ads from (a) other ads and (b) JavaScript and running in the context of the publisher page.

@ShivanKaul
Copy link

ShivanKaul commented Nov 11, 2021

For 1: The concern is that the way these UUIDs will be generated is by the web bundle toolchain, meaning that every resource, even if it's the same across different websites, will have a unique (by definition) ID. I get that current bundler tools can do that as well, but this is standardizing and incentivizing that practice and the use of literally unique identifiers is unprecedented (afaik). #623 sounds like a much better approach (and I share the concerns articulated over there as well).

For 2: it's good that it's in scope, but what is the fallback option here if a server refuses to acknowledge the proposed Resources header and always sends the entire bundle because they don't want to change infra again? Seems like the most client-friendly approach would be to do it in v1 along with the rest of the push towards subresource bundle loading instead of trying to fix things later on, given what is at stake here is clients downloading unnecessary bytes which hurts exactly those users whose needs we should be prioritizing.

@hayatoito
Copy link
Collaborator Author

Thanks.

For 1:

Re #623, tt seems there is no activity for a year. Can we expect we have a progress on that?

Re UUID approach, we're not aware whether there is any particular concern, technically or theoretically, on using UUID.
We'd appreciate if someone has a particular practical concern of using UUID, which is hopefully actionable for us.

For 2:
A good question. I think Bundle Preloading's Backward compatibility section explains that well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants