Asset bundles for faster page fetching (fewer requests to the server)

Hi all,

It would be great if it were possible for a web page author to specify an
"asset bundle" to use for the web page authored. This asset bundle could be
e.g. a zip file containing parts/all of the css, javascript and image
content needed by the page. A user agent could then fetch the asset bundle
(one request) and in it find most/all of the assets needed to render the
page, without the need to make additional requests to the server (with all
the attendant latency etc issues).

User agents that are not aware of the asset bundle concept would simply
ignore the asset bundle reference and fetch the assets in the way it's
already done today, thereby ensuring full backwards compatibility.

Assets required for page rendering but not found in the asset bundle would
be fetched the way it's already done today (so you can optimize what you put
in the asset bundle).


Benefits:

- Lower the impact of latency on page loading for web pages with multiple
assets (almost all modern web pages).

- Many web page authors do not have fine-grained control over the ETAGs
generated for their css/javascript/image assets, which then requires the
user agent to issue refresh requests for all those assets. With an asset
bundle the number of such requests could be drastically reduced.

- Even in the case where web page authors do have fine-grained control over
the ETAGs, it can be difficult to take advantage of this since you may not
know when content will need to be refreshed. If you set the ETAG to
~infinity, then it requires significant labor to update the file names of
content that has changed to make sure it is refreshed. With an asset bundle
you would only need to update a single filename.

- Many web servers are poorly configured and do not compress e.g. css and
javascript content they serve. An asset bundle would be compressed by virtue
of construction.

- Fully backwards compatible with opt-in for web page authors and user
agents.


The asset bundle itself could be easily generated either manually by the web
page author (zip the contents of the directory containing the assets for
simple cases), or automated by a tool in e.g. the web framework used (if
any). This would allow for single-point-of-update with an ETAG set to
~infinity - just change the name of the asset file, rather than the name of
each individual asset. Note that this could easily be fully automated in any
of the popular web frameworks in use today.

The asset bundle could be referenced in the web page by e.g. something like
<link rel="assetbundle" src="/assetbundle.zip" ... >.

Tools used to create the asset bundle could be made sufficiently smart so as
to only include "small" assets (e.g. the 50+ <4kb images), but not "big"
assets (e.g. the 2mb video).

Mapping the directory structure inside the asset bundle to the path
structure of the assets used in the web page/css/javascript should be
straightforward, even for complex cloud-fronted/akamai-ed configurations,
with the use of a few optional path mapping attributes in the tag used to
reference the asset bundle.

Since it would be completely optional to use an asset bundle, the user agent
should assume that the asset bundle is an authoritative source for the most
recent version of any assets found inside of it, thereby allowing the user
agent to skip additional refresh requests for those assets.

If multiple asset bundles are referenced by a web page, the most recent one
specified that contains a given asset would be used for that asset (i.e.
order-in-web-page decides priority, just like for css).

Use of streaming compression standards would allow for the unpacking of
received bundle contents before the full file has been fetched. This would
allow conscientious web page authors and their tools to optimize the storage
order inside the asset bundle.

In a low-latency situation a user agent may be able to fetch the assets
faster if the requests are made in parallel, rather than through the by
construction serialized fetching of an asset bundle. User agents can be
optimized to detect and take advantage of this (i.e. the asset bundle is a
"hint" or "suggestion" not a requirement).

I read somewhere that the typical website visitor views on the order of 5
pages. With say 50 assets for each page (including the page itself), a user
agent that aggressively checks for refreshed content may find itself making
5*50=250 requests to the website. With an asset bundle this would be 5*2=10
requests, and if the asset bundle's ETAG is properly configured, it would be
6 requests (vs 54 for a fully ETAGged non-asset-bundle site).


Thank you for reading this.
Jxtps