diff options
Diffstat (limited to 'chromium/docs/website/site/x-subresources/index.md')
| -rw-r--r-- | chromium/docs/website/site/x-subresources/index.md | 119 |
1 files changed, 0 insertions, 119 deletions
diff --git a/chromium/docs/website/site/x-subresources/index.md b/chromium/docs/website/site/x-subresources/index.md deleted file mode 100644 index dad0d28e876..00000000000 --- a/chromium/docs/website/site/x-subresources/index.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -breadcrumbs: [] -page_name: x-subresources -title: X-Subresources ---- - -## Andrew Oates <[aoates@google.com](mailto:aoates@google.com)>, Bryan McQuade <[bmcquade@google.com](mailto:bmcquade@google.com)>, Mike Belshe <[mbelshe@google.com](mailto:mbelshe@google.com)> - -## The Problem - -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. - -In older browsers, this problem was exacerbated by the fact that the browsers -would block when downloading external JavaScript resources. Blocking on -JavaScript downloads delayed the time to discover additional subresources needed -in the page. Recent browsers (IE8+, Safari 4+, Chrome2+, FF3.5+) can download -scripts in parallel, which mitigates this particular part of the problem. - -We've also seen traces from real world web pages, where the top of the page is -loaded with several kilobytes (even after compression) of inline CSS and -JavaScript. If you had 20KB of such information at the top of the page, and -downloaded the page over a slow network (such as a 256Kbps cell phone), it could -request those resources as much as 600ms earlier than it otherwise could! Now, -the observant reader may notice that if the network is fully utilized there is -no point in adding additional resources to the download, as they will compete -for bandwidth and slow each resource down. However, such networks usually have -large RTT in addition to low bandwidth. The time to get requests to the server -can be 200+ms. Although the bandwidth may not be immediately available, getting -the RTTs started in parallel provides an advantage. Further, servers that use -this experiment can intelligently schedule the responses (potentially even -across connections) to avoid such contention issues. - -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. - -## Challenges - -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. - -## The Experiment - -If browser's knew what subresources they would need for a given page, they could -kick off the requests at the start of the page load, and wouldn't have to block -on fetching javascript files (only on execution). This experiment proposes a new -HTTP header, "X-Subresources" which can inform the client of subresources that -may be needed when downloading a resource much earlier than when the client -would otherwise discover the resource. The browser can optionally use this -header to download content sooner than it otherwise would have done so. - -## Other Solutions - -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. - -## Informal Specification - -Client-side - -If a client wishes to receive subresource notification headers, it should -include a X-subresource header on the appropriate requests: - -X-Subresource: enabled - -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. - -### Server-side - -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. - -#### Header Format - -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. - -For example: - -X-subresource: text/css; http://www.foo.com/styles/foo.css; -image/gif;/images/img1.gif
\ No newline at end of file |