Bundle preloading

Authors

• @cjtenny
• @littledan
• @wycats
• @felipeerias

Introduction

This document describes a mechanism and semantics for the efficient preloading of multiple resources using bundled HTTP responses in the Web Bundles format.

Modern websites are composed of hundreds or thousands of resources. Fetching them one by one has poor performance, which is why Web developers rely on bundlers, tools that combine and transform resources for efficient deployment.

However, bundlers currently face many hurdles to provide a good developer experience, fast site loading, and efficient cache and network usage. The non-standard formats used by bundlers are not interoperable and extracting resources from them tends to be costly; furthermore, their contents are mostly opaque to browsers, preventing fine-grained cache management.

This proposal focuses on a mechanism that allows a large number of resources to be preloaded efficiently and incrementally cached by browsers, CDNs, and other intermediaries.

There have been several previous attempts to implement aspects of efficient resource bundling on the Web. Unfortunately, they failed to gain widespread adoption due to constraints imposed on bundlers, servers, and clients. This proposal attempts to avoid the shortcomings of those previous attempts by:

• Offering imperative and declarative client-side control to Web developers.
• Maintaining backwards compatibility for servers and intermediaries through polyfilling and existing cache-control mechanisms.
• Preserving the relationship between URLs and content ("resource identity" for graceful degradation and content blocking.

The main goals of bundle preloading are:

• Efficiently distribute Web content in a standard and interoperable manner.
• Allow developers to keep the benefits of today's bundler ecosystem:
  • improved network performance and faster load times;
  • optimization strategies like revving, code splitting, tree shaking, etc. remain possible;
  • reduced bundler build time and simplified internal logic.
• At the same time, preserve the benefits of accessing individual resources:
  • flexibility when loading and processing responses;
  • each response can be cached individually.

Participation and Standards Venues

The Web Incubator Community Group is not a standards venue itself; documents developed here, such as this one, are not by themselves on a standards track. Instead, WICG serves to provide an open platform and safeguard the intellectual property developed to enable later standardization.

The resource bundle format referenced in this proposal is an RFC from the IETF WPACK working group which will be periodically published as an Internet-Draft. The bundle format is currently developed in the wpack-wg/bundled-responses repository.

Discussion of this proposal is welcome in the issues section of this repository. Additional discussion occurs on our Matrix channel, at IETF WPACK WG meetings, and on the WPACK WG mailing list.

Resource and module loading on the Web is generally defined by WHATWG standards like HTML and Fetch and W3C standards like Resource Hints. When the proposals in this repository reach a state of multi-implementer support and no strong implementer objections, with Web-platform-tests tests developed, they will be proposed as pull requests to those standards.

Table of contents

• Motivation, goals and constraints
• Overview: bundle preloading
• Considerations for bundlers, servers, and browsers
  • Bundle preloading for clients
  • Bundle preloading for servers
  • Suggestions for bundlers & tools
• FAQ
• Prototyping and implementation
• Glossary

This proposal seeks to address several audiences—bundler and tooling authors, client and server side Web developers, and browser implementers—and as such has been split into several sections.

We recommend starting with the motivation and overview, which together with this introduction form a general-purpose explainer for most audiences. The remaining sections provide further details for specific audiences.

Stakeholder feedback

The FAQ contains some characterization of stakeholder feedback. This section will be updated as stakeholders offer feedback.

Acknowledgements

Ongoing conversations with and feedback from the following parties have helped shape (and continue to shape!) this proposal. The authors very much appreciate:

Guy Bedford, Rob Buis, Andrea Gianmarcchi, Devon Gonett, Tsuyoshi Horo, Hayato Ito, Jeff Kaufman, Tobias Koppers, Jason Miller, Shubhie Panicker, Pete Snyder, Martin Thomson, Sean Turner, Yoav Weiss, Evan Williams, Kinuko Yasuda, and Jeffrey Yasskin.

Previous section - Table of contents - Next section