Web Bundles provide a new approach to load a large number of resources efficiently using a native format that allows multiple resources to be bundled together.
Web pages will declare that some of their subresources are provided by a Web Bundle served at a particular URL.
We propose the following <link>-based API:
This alternative will enable the browser to know which resources are found in the bundle in a more specific way, as well as communicate the needed resources to the server (at a later stage).
Prototyping will enable us to quantify the benefits and downsides of each approach.
Loading multiple resources requires multiple network round-trips and it's often slower than fetching a single resource. We'd like to explore an API for web pages to retrieve multiple subresources in one request with a native format, i.e. Web Bundles. We believe that a native format would allow the browser to further optimize resource loading since it would understand what the bundle contains.
Interoperability and Compatibility
N/A (prototyping phase)
The feature will be detectable via the regular relList mechanism (link), and on the browsers that don’t support this feature subresources will continue to load as usual, e.g. over the network or from the cache.
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Developers need to package their subresources in a Web Bundle in order to take advantage of this feature. Tools currently available are: Go, Rust, WebPack plugin, rollup plugin. We would love to discuss with authors of JS bundler to explore what it would take to provide a plugin that would package subresources as Web Bundles.
We’re having ongoing discussion on how the Bundle and individual resources in Bundle should respect CSP and other security features on the Web. The feature should also full respect the origin-based security principle of the web, and the claimed URL of the resources in the Bundle will be considered authoritative only if the origin of the resources are the same as that of the Bundle’s distributor origin, or are the unique ones that are based on the content, e.g. ni:///
We don’t know yet what would make sense in terms of DevTools debugging support. Prototyping will allow us to better understand the developer needs around this feature.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
Link to entry on the Chrome Platform Status
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_3CLCcZFJLggNn_NtdDj8DYtE0HF97JDUPO0ERbChSH_A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8PJseJ%2Boy%3D_OBuUNFmOzsipqL7BEya1O-1oKAgR0tTPg%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "WebPackage-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webpackage-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/webpackage-dev/CADk0S-WbqjX2A-7obnYop4%3DW%3DXK5NaWZE2PJyvqPEGq0VNZHGQ%40mail.gmail.com.