# Built-In Bundling For Faster Loading

I used to work on [mod_pagespeed](https://www.modpagespeed.com/), which would rewrite web pages so they would load faster. A key component was bundling: combining multiple small resources into a single larger one to reduce overhead. For example, it had tools to combine multiple [CSS](https://www.modpagespeed.com/doc/filter-css-combine), [JS](https://www.modpagespeed.com/doc/filter-js-combine), and [images](https://www.modpagespeed.com/doc/filter-image-sprite).

There were serious downsides to our approach, however, because there was no built-in support for bundling:

*   Combining many small images required spriting, with CSS to identify which area of the image you want for each usage. This is a very different syntax, and is awkward to do by hand. Our ability to do it automatically was limited, because it needed to understand the site's css and the publisher needed to have intentionally set their css up to minimize the changes required.
    
*   Combining many small CSS or JS files worked better but still required hacks to prevent errors in one file from breaking the others.
    
*   We had to change the URLs in the page, which was mostly a problem for images. JS that modified image URLs, like changing `foo.png` to `foo_hover.png` on hover, could be broken, and images wouldn't have the right names if you downloaded them. This also sometimes broke JS that expected it could derive the location of related files from its URL.
    
*   We needed separate files for the CSS, JS, and images.
    

With the release of Chrome/Edge/Opera/Vivaldi 104, however, there's a new API that makes bundling subresources very natural. Here's a demo: [wbn-demo](https://www.jefftk.com/wbn-demo/).

The core of the demo is:

<script type="webbundle">
{
   "source": "subresources.wbn",
   "resources": \["script.js", "sheet.css"\]
}
</script>

<link rel=stylesheet href="sheet.css">
<script async src="script.js"></script>

This tells the browser to fetch `[subresources.wbn](https://www.jefftk.com/wbn-demo/subresources.wbn)`, and then if it needs to load [`script.js`](https://www.jefftk.com/wbn-demo/script.js) or [`sheet.css`](https://www.jefftk.com/wbn-demo/sheet.css) it will get them from the bundle instead of making separate requests. Of course this is overkill for my little demo, but if I had a page with a large number of small resources the savings would add up.

You can read more about this API by looking at the [spec](https://wicg.github.io/webpackage/subresource-loading.html) or the Chrome [explainer](https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md). I'm hoping that Firefox and Safari decide to add support for this functionality!

Above I listed Chrome, Edge, Opera, and Vivaldi, four out of the five main Chromium-based browsers, as supporting this feature. What about Brave? Brave [objected](https://brave.com/web-standards-at-brave/3-web-bundles/) to Web Bundles, arguing that they could be used to work around ad blocking. I think they're mistaken, and [argued so at the time](https://www.jefftk.com/p/webbundles-and-url-randomization), but apparently they aren't convinced. Since this is a progressive enhancement, however, it's fine that Brave has disabled it: their users will cleanly fall back to loading multiple resources, at a small performance cost.

(There is also another way of using this feature which goes beyond reducing network requests, and allows you to efficiently isolate untrusted content on a unique origin. I wrote about that in [WebBundles for Ad Serving](https://github.com/WICG/webpackage/issues/624), which describes how to use this feature to load and display ads in a more secure and private way. Doesn't make them [any less blockable](https://www.jefftk.com/p/thoughts-on-ad-blocking), though.)

*Comment via: [facebook](https://www.facebook.com/jefftk/posts/pfbid0R3ctdKJ3CkBpd9MUXpUtpjyNEiaD3EZzawmeqweAPgq4pQyEpygBGQoSaZkgTxNvl)*