Andrew Oates <firstname.lastname@example.org>, Bryan McQuade <email@example.com>, Mike Belshe <firstname.lastname@example.org>
A typical modern webpage fetches many external resources. www.cnn.com, for example, loads 150+ external resources on a fresh page load. The browser has no way of knowing which resources will be required for a page until it reaches the tags that reference them, or until a script sends off the request dynamically. The more time it takes for the browser to discover that it will need a resource, the more time it will take to download the entire page.
Evidence suggests that we can improve page load times for some sites if the server can inform the client of subresources earlier than it does today.
When downloading additional resources sooner, we need to ensure that the downloading of those resources does not defer the downloading of primary content. For example, the browser may be critically blocked on the downloading of the main HTML or the main CSS file. If we inform the client of low-priority images earlier, we should make sure that downloading them will not delay the higher priority resources.
Many alternative approaches to this problem exist. One simple one would be to consider putting this information into the HTML content (perhaps as LINK headers) as opposed to putting it into the HTTP headers. There are advantages to this approach, because having the server know about subresources for a given content page can be difficult to discover or manage. This approach would inform the browser of the subresources marginally later, but probably not significantly later. We haven't rejected this approach, and it may be a good idea to support as well. The reason we chose the HTTP header is because we'd like the origin server to be able to discover these optimizations on-the-fly without intervention from the content author. Content authors often do not know about the "tricks" to optimally load a web page, and giving servers the tools so that they can perform these changes automatically, we hope this feature is more useful. We could, of course, have servers modify the content being issued to the client on-the-fly, but this can be more difficult to do efficiently. All in all, we hope the solution we've chosen is a good starting point for this experiment.
If a client wishes to receive subresource notification headers, it should include a X-subresource header on the appropriate requests:
When a client receives a response with the X-subresource header, it should decode the value, and generate requests for the URIs listed in the header. If multiple subresources are listed, it should fetch them in the order that is listed.
When a server receives a request with an appropriate X-subresource header, it may generate a list of subresources to be used by the requested page. It could do this by scraping the HTML, consulting a database, etc. It should then return this list as a X-subresource header to the client as part of the HTTP response header block. The server must not use X-Subresource headers for resources which are not cacheable, or whose lifetime might expire before the end of the current page load.
The X-subresource header has the following format:
header-value ::= type ; resource [; type; resource]
type ::= text
resource ::= URI
Each resource consists of a type and a URI. The type is the mime-type of the URI, such as "text/html", "image/gif", etc. The URI is a standard HTTP URI.
X-subresource: text/css; http://www.foo.com/styles/foo.css; image/gif;/images/img1.gif