Intent to Ship: Subresource Loading with Web Bundles

[Hayato Ito]

Contact emails:

hay...@chromium.org, deno...@chromium.org

Explainer:

https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md

Specification:

https://wicg.github.io/webpackage/subresource-loading.html

Summary:

Provides a new approach to load a large number of resources efficiently using a format that allows multiple resources to be bundled, Web Bundles.

Note that the scope of this "Intent to Ship" is only v1, which is explained in our long term plan. We have been conducting the Origin Trial for v1 features. Given that the outcome is promising, we’d like to ship v1 as MVP in order to mitigate the risk of "develop everything and ship them all at once".

After shipping v1, we'll explore v2, designing and implementing missing key features, eg. cache-aware WebBundles. There are several proposals, such as Bundle Preloading (discussion), Bundle Dependencies, and others. We continue to explore this area to identify a missing Web Platform primitive in order to serve large Web Apps in a cache-efficient way with Web Bundles.

Blink component

Blink>Loader>WebPackaging

TAG review: https://github.com/w3ctag/design-reviews/issues/616

TAG review status: While the status of the review is open, we have addressed the concerns raised in the discussion. In particular, we plan to explore the designs in v2 as explained above. Additionally, if a concern with the extension part continues to be an issue, we aim to address it in v2 as well.

Risks:

Interoperability and Compatibility:

No interoperability and compatibility risk has been identified. This is purely a feature addition. A browser which doesn’t support this feature should load subresources from the network, as usual.

Gecko: No signal (issue)

WebKit: No signal (ML)

Web Developers:

Google Ads (use case) (origin trial participant)

> Web bundle serving is a major overhaul of how GPT requests and renders ads, built on top of a new browser API which we have been designing with the Chrome team.  It offers large loading performance improvements and security and privacy relative to safeframe rendering:

• Performance improvements by fetching multiple Ads creatives in a single request.

• Enhance privacy: Creative contents can no longer be read or modified by the publisher or others in the publisher's JS context. Creatives can no longer read or modify each other.

Ergonomics

This feature can be used to improve loading performance by fetching multiple resources in a single request. If a browser doesn’t support this feature, a request should be served from a network as usual.

`HTMLScriptElement.supports("webbundle")` can be used for feature detection as well.

There are several tools and plugins available for packaging Web Bundles.

Security

Received approval for Security and Privacy in our launch bug. We had addressed a security concern for the usage of <link> elements. The API now uses <script> elements. We ship only <script type=webbundle>.

Debuggability

Developers have the ability to test this functionality on their pages by opening DevTools and selecting the Network tab. This allows the DevTools to represent Web Bundles and the resources that originate from it being attributed to the Web Bundle (link).

Is this feature fully tested by WPT?

Yes (link).

Tracking bug

crbug.com/1082020

Launch bug

crbug.com/1306701

Estimated milestones

M102

Links to entry on the Chrome Platform Status https://chromestatus.com/feature/5710618575241216

--

Hayato

[Kenji Baheux]

A quick clarification ✔️ to avoid confusion 😕 or needless agitation 🥵:

This hardening of read/write access is only meant for code originally present on the page, not code coming from user extensions.

In other words, extensions can see and operate on ads served in this manner. 

In particular, extensions can still act upstream of these ads requests as is typically the case (e.g. directly acting on the scripts that drive these requests).

The goal for this particular use case is to improve users’ privacy and security by preventing non-user controlled/added code from peeking into, or making malicious changes to, ads that were served by another party, with better or neutral performance (see the TAG review for more details and analysis).

I hope this is clear and useful 🙏🏼 🙇.

[Hayato Ito]

Thanks for the clarification.

Yeah, I think it's up-to each browser, however, it is worth clarifying that extensions in chrome are able to see and operate on subresources in Web Bundles.

See https://bugs.chromium.org/p/chromium/issues/detail?id=1155402 for details.

--

Hayato

[Titouan Rigoudy]

Hi there,

Has anything changed between the OT and this launch?

Cheers,

Titouan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_10M-CYuWz%2BE__id-e7jey0kA6J-ayF8qy8wdPgzeSZZA%40mail.gmail.com.

[Hayato Ito]

Thanks for the question. Responses inline below.

On Tue, Apr 19, 2022 at 6:29 PM Titouan Rigoudy <tit...@chromium.org> wrote:

Hi there,

Has anything changed between the OT and this launch?

A good question.  No behavior change between the OT and this launch.

Thanks! 

--

Hayato

[slightlyoff via Chromestatus]

Microsoft would like to see this ship ASAP. LGTM1

[Otto van der Schaaf]

As a maintainer of mod_pagespeed, I would love to see this ship.

[Jeff Kaufman]

Thanks, Otto!  As someone who used to work on mod_pagespeed I wanted to give a bit more context on how web bundles improve on what is possible for automatic site optimization tools like mod_pagesped:

1. Combining many small images into a single file otherwise requires spriting (with css to identify which area of the image you want for each usage) and mod_pagespeed's ability to do that automatically (sprite_images filter) is limited.  It needs to understand the site's css and the publisher needs to have already set their css up to minimize the changes required.  With bundles it is much simpler: you put all the tiny image files in the bundle, and you rewrite the URLs to point into the bundle.

2. Combining many small css or js files into a single file (combine_css, combine_js) requires hacks to prevent invalid css or js from breaking the rest.  It's reasonably common that publishers will have <link rel=stylesheet href=invalid.css> that doesn't parse, and if you blindly concatenate with other css you will change the layout on the page. Since automatic site optimization tools like mod_pagespeed want to make the site load faster without making any changes to how the site looks, that isn't acceptable.  Same issue with js.

3. Today you need to have separate files for combined images, css, and js.  With web bundles there can be just one.

Jeff

[Daisuke Enomoto]

Hello

I am sharing the feedback from the Origin Trial with 12 participants:

• 10 of them responded "Extremely likely" to "How likely are you to keep using this feature?" 

• Qualitative feedback:

• "I'm very excited about the CSP interpretation change rolling out in M92"

• "looking forward to the CSP fix!"

• "I'm very glad you're working on this!"

• "This feature is great! I'd love to see it fully launch"

Daisuke

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45f97f97-7db0-42ee-bea8-d01ddb344ba6n%40chromium.org.

[Ben Mathwig]

Microsoft has a strong interest in seeing this feature ship. We believe that sub-resource bundling is opening the door to a new way of shipping and delivering offline web applications, changing the traditional definition of “web application”.

Here are some ways Microsoft products can take advantage of this:

PowerApps

Microsoft PowerApps allows a developer to author an application and deploy to iOS, Android, and the web. The first two platforms allow applications to be deployed and used when the device is offline, but the latter is currently not “installable” on the device. Web bundling could unlock the capability for a web application to be “installed” on a device to operate offline.

Office Online

Office productivity web applications are a perfect example of applications that could benefit from a packaged bundle of application resources. Combined with local storage APIs, this could help developers reach communities that have little to no network connectivity.

 

While there have been concerns brought up by the community, we welcome the opportunity to collaborate on addressing these issues in the next iteration of this project. We feel confident we can resolve them in a way that preserves the integrity of the open web.

Ben Mathwig
Senior Product Manager
Microsoft Edge Web Platform

[PhistucK]

Not that I am against, but does this unlock previously locked opportunities in the specific examples you just mentioned?

You could have used a service worker and cache things in order to get the same thing, combined with progressive web applications for installability.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/81ea3aac-58c3-4a77-941a-b647c03b2edfn%40chromium.org.

[Ben Mathwig]

>>  You could have used a service worker and cache things in order to get the same thing, combined with progressive web applications for installability.

This is true, but I think ergonomics of an encapsulated page/application make it easier to reason about for very large applications. Maintaining the service worker and the cache at scale can become a barrier to entry for some developers and applications.

[Alex Russell]

There are high-scale operational challenges to distributing content optimally in many scenarios (e.g., Store packaged first-run or out-of-the-box-experiences) that need more than what Service Workers alone can provide. We are positive about this technology because it can help address those problems and open up new product opportunities (that we cannot say more about).

Best Regards,

Alex

[Chris Harrelson]

LGTM2

Web bundles team: thank you for your thoroughness in responding to concerns raised in the TAG review, Mozilla standards position, and various offline conversations. I also appreciate those who weighed in on the thread with additional sites that would use this feature, and the multiple use cases mentioned.

At first, I was concerned about the risk of not achieving eventual interoperability, because of the limited data from experimenting sites and mixed or possibly negative signals from other browser vendors. The additional data mentioned above, on top of the existing ads-related use case from the original intent, and coupled with my belief that the team will continue to invest in standards in this area, leads me to conclude that this feature is worth shipping now.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e6886f3-b5e6-4818-9edd-0acb9364e745n%40chromium.org.

[Yoav Weiss]

LGTM3

I was similarly convinced by the team's efforts and by various folks chiming in that this has a good chance of reaching eventual interop on its own. The use cases this tackles span origin isolation, delivery and performance (despite the lack of cache awareness in the current version), and I'm hopeful that this would be an important stepping stone on which future improvements will be built. Thanks!!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8RF%2B8r8xgiMjvfkg71%2BJEw1J5JfdzTptnYJTSRt9T5AQ%40mail.gmail.com.

[Hayato Ito]

Thanks all, for your support and the LGTMs.

I appreciate the API owners, the Mozilla folks and the others, who reviewed this feature carefully and gave us the advice to make this feature interoperable and be an important step on future improvements on the Web Platform.

I'll continue to invest in standards. Thanks!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWvwR71_22zF5DR-iSr6ozfUbHR%2BOxLMcvQ70iap%3DsoVA%40mail.gmail.com.

--

Hayato

[Joe Medley]

Is this shipping in 105? Please add that to the status entry.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_3sQTfJW%3DTLS7s5SAsFM6ZHzkGooB%3DK3u4q_D9Qf4gmfQ%40mail.gmail.com.

[Daisuke Enomoto]

Hi Joe,

This feature is shipping in 104. I updated the chromestatus entry.

Thanks for pinging.