This proposal aims to be targetable by bundlers and other JavaScript tools as an output format, while achieving, at a minimum, same kind of site loading performance as bundlers achieve today. (Ideally, performance should be even better, by decreasing the amount of virtualization that has to be done in JavaScript, further reducing the number of requests, and improving compression.) It would be great to hear feedback from tooling maintainers on this thread.

To interactively test this proposal, it would be useful to have a polyfill of subresource loading using ServiceWorker, so that it can be run in browsers during development (even if it may be too slow for production). This issue tracks that work.

Following issue: #21 and change #22, this proposal has changed its focus to subresource preloading using bundles.

The name of this repository remains resource-bundles, which is now imprecise and potentially misleading as the proposal outlined here does not describe a new format for building resource bundles.

Rather, it uses the Web Bundles format already being defined by the IETF WPACK Working Group to solve the specific use case of preloading resources on a Web site.

A better choice of name for the repository would be bundle-preloading, since that is the specific use case that this proposal aims to solve.

Following the discussion in IETF 110's WPACK WG meeting, there is a call for adoption of the "bundled responses" file format. This repository should be rearranged to focus on subresource loading, deferring the file format to the new WPACK repository once it is created.

I think it would be best if subresource loading initially focused on a simpler, imperative mechanism along the lines of this gist (which Shubhie from the Chrome team pointed out to me would be more accurately thought of as "prefetching" than preloading). Such a mechanism would form a flexible basis for the output of tools in the near-term, and a higher-level manifest-based mechanism as is currently described for subresource loading could be built on top of it.

With these changes, this repository might be more accurately called "WICG/batch-prefetchingbundle-preloading".

In the serving document, the proposal opens with

The resource bundle file format can be used by web servers to improve usability.

What does usability mean here? I would have actually expected an expansion on this if we are talking about usability.

The document also covers chunking -- this isn't something that I would think of as covered by usability, so the introductory paragraph threw me off. I would expect the opening to be. I would have expected a dedicated section on serving to be broader than usability. It might also help to pull out the serving parts out of the subresource loading document and link it to here. Maybe starting with something like this?

Serving Resource Bundles

The Resource bundles proposal seeks to address some of the issues that arise on the web platform when shipping complex application to the client. This segment focuses on how resource bundles address those concerns and what additional benefits may come from using this technique.

And move and expand these sections from subresourcing

• https://github.com/littledan/resource-bundles/blob/main/subresource-loading.md#for-servers
• (etc, will add others later)

Resource bundles can be used to develop applications across the build/serve pipeline, beyond just what is used in browsers. @wycats is working on documenting the full vision better, beyond the early notes that I wrote in other-uses.md. This issue tracks that work.

@yoavweiss described an idea for using cuckoo hashes to transmit cache contents to the server through a header, in this document. This issue tracks fully describing the idea in this repository.

To validate this proposal, it would be great to develop an early prototype of various versions of it in web servers, for testing.

There is a nice TypeScript implementation of Web Bundle manipulation by @irori in the WICG/webpackage repository. It would be great to make a similar CLI tool and JS library for this kind of processing on the "resource bundle" format, which is just the same as Web Bundles plus PRs #617, #618, #619. (This could be based on a fork of @irori's code, if he's OK with it.)

To validate this design before shipping as on-by-default in browsers, it would be great to implement it as an output format of bundlers. This would be particularly useful to help experiment with the various possible manifest formats discussed in subresource-loading.md. This issue tracks the bundler prototyping work.

There is a motivation sub-section for Subresource loading with resource bundles but none for the main repository, it is partially covered in "implementation", and touched on in other areas. However there is no "we need to fix this problem or this set of problems" that is easily understood from the readme.

I think for those who are familiar with what this is trying to solve it may be self evident, but not everyone is or they may not agree with the motivation. Can you add a section to the README?

For example, someone coming from the webpackage area might think this has the same motivation as that project, which lists it as:

Previous attempts at packaging web resources (e.g. Resource Packages and the W3C TAG's packaging proposal) were motivated by speeding up the download of resources from a single server, which is probably better achieved through other mechanisms like HTTP/2 PUSH, possibly augmented with a simple manifest of URLs a page plans to use. This attempt is instead motivated by avoiding a connection to the origin server at all. It may still be useful for the earlier use cases, so they're still listed, but they're not primary.

But is the goal here the same? (I suspect no, but I think you know the specific motivation better here)

This proposal aims to permit content blockers to block not just entire bundles but also particular parts of a bundle, using similar techniques as today (e.g., filtering based on URL patterns). If you maintain a content blocker, please let us know what you think in this thread. Does this proposal meet your needs?

The example in subresource-loading.md has the following manifest:

    "paths": {
        "a.js": ["bGpobG", "FzZGZq"],
        "b.js": ["bGpobG", "sbnNkd"],
        "style/page.css": ["a2FzaG"],
    }

(implicit: common.js => bGpobG)

However, there's no way to indicate whether a resource is needed immediately or soon here, which would help in batching requests and with page responsiveness. For example, a.js and b.js might depend on common.js to be able to execute, but may also insert loading-wheel.gif into the page when running and be able to start executing / return control to the user before that soft dependency loaded. Similar to priority hints, a mechanism here & in the proposed bundle navigator control mechanism could offer larger sites much needed control to maintain responsiveness while using bundles.

@wycats and @bradleymeck have both raised this issue: what happens in various cases where one side understands the subsetting protocol and the other doesn't, or where both sides understand it, but some intermediary does not? How are errors, where the other side gives invalid messages, handled? We should enumerate all the cases we can think of, and ensure that the details are handled in a useful way.

https://github.com/WICG/resource-bundles/blob/main/bundle-format.md#the-resources-section currently documents headers and payload fields.

• "headers" is a colloquial reference to what is more strictly defined as the singular header section, which consists of individual header fields (RFC 7230, HTTP draft)
• "payload" is being renamed to "content" (HTTP draft)