What a fantastic idea Jxtps! I'd like to suggest a way for the user-agent to keep track of assets within the bundle vs. individual files. For example on an image link:
<img src="/folder/imagefile.jpg" asset="/bundle.zip/imagefile.jpg" alt="title" /> If the user-agent recognises bundles, then it will extract the imagefile.jpg from the bundle.zip archive, but if the user-agent doesn't recognise bundles, it requests the imagefile.jpg individually from the web server from the /folder/. The user-agent would keep track of the fact that: /folder/imagefile.jpg ... is exactly the same as: /folder/bundle.zip/imagefile.jpg ... so that if it comes across another instance of /folder/imagefile.jpg in the same web-page or another web-page, it can extract it from the cached bundle.zip archive instead of making another HTTP request. Likewise: <link type="text/css" rel="StyleSheet" href="/folder/stylesheetfile.css" asset="/bundle.zip/stylesheetfile.css" /> <script type="text/javascript" src="/folder/javascriptfile.js" asset="/bundle.zip/javascriptfile.js"><script> I hope this makes sense. Regards, -- David Bailey, Bath Spa University - Web Manager. [As long as you don't print this email, no trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.] From: [email protected] [mailto:[email protected]] On Behalf Of jxtps435 Sent: 08 November 2009 19:58 To: [email protected] Subject: 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
