|link rel prefetching should be implemented|
|Project Member Reported by email@example.com, Jun 6 2009||Back to list|
Mozilla has a cool feature that allows content to *suggest* that an additional URL be prefetched. As an example, this is used by some search vendors to cause a browser to prefetch the highest ranking content when the content author (search vendor) believes there is a high probability that the user will soon click on the indicated link. This is nicely described in: https://developer.mozilla.org/En/Link_prefetching_FAQ Note that the hooks are almost already in place in Chromium, as we need to parse out this <link rel="prefetch" href="..."> tag at the same time as we parse out <link rel="dns-prefetch" href="...">. When this parsing was upstreamed to Webkit, a change was made in HTMLLinkElement::tokenizeRelAttribute() in HTMLLinkElement.cpp, but we didn't also include the corresponding parsing of the plain "prefetch" tag. We need to upstream that plumbing to WebKit, and then implement the backend prefetching of the content (...in the background... and to the extent to which we think it is reasonable for a user).
Jun 8 2009,
Jun 16 2009,
I will take a look.
Nov 5 2009,
Is this what the Google Toolbar "Enable pre-fetching to load web pages faster" option does? If so, it would be great if Chrome could natively have this kind of optimization that Google is adding to other browsers.
Nov 12 2009,
Are there any updates on this? Would be great to implement this. Also, Darin and I had discussed long time back whether it makes sense to implement it like Firefox does (where only the root page is prefetched) or prefetch the entire page (along with its subresources).
Nov 12 2009,
Personally I feel downloading an entire page's contents might be overkill. If they want you to prefetch certain objects on the page, they can specify them. "Recursive prefetch" needs a different link rel.
Nov 12 2009,
I'm pretty sure that recursive prefetch would be a bad idea. IF the party that suggests the prefetch thinks otherwise, it should specify the extended set of sub- resources that should be loaded. I think that currently the suggestions for prefetching via link-rel might include *only* subresources, as only cached content should be preloaded, and sometimes the top-level page is not cached (but it has a pile of cached subresources). As I understand it, this bug was intended to implement the current feature as spec'ed, and we shouldn't get diverted to building extensions until we can justify the value of this feature at all. There is ongoing debate about whether the server is even qualified to suggest what should be preloaded, as it may not understand the network environment of the client. When the client is severely bandwidth constrained, pre-loading content may be a very iffy deal. We'll need some stats to quantify wins/losses before going forward.
Nov 16 2009,
Dec 9 2009,
Issue 27111 is a related feature request. rel=prefetch, yes as long as network and memory isn't too filled. If headers forbid caching? Perhaps cache anyway, and expire when leaving current site and not going to the prefetch page. Mozilla also prefetches rel=next unless it has parameters, i.e. no prefetch of "list.php?page=2". When the current page forbids caching (pragma or short page expiry) then surely rel=next should not be prefetched. (A cacheable current page and a rel=next with parameters might actually be a good idea to prefetch?) What resources of a page pays off to prefetch? By looking at page load profiles of both optimized and average websites, the waterfall(s) start from the main document, then CSS-files. A page with many small images (=TABLE based designs) could prefetch images, especially since those pages aren't going to add their own rel=prefetch for the specific graphics files anytime soon. Perhaps use header Content-Range set to one or few TCP packets, where few packets = less risk of delays due to dropped packets. Long running prefetch connections can't be afforded, as dictated by Chrome's max-connection-count=5. Prefetch probably shouldn't go via the regular cache to avoid kicking out cached data which have provably been of use, and more so for rel=next than for rel=prefetch.
Dec 9 2009,
A temporary workaround as an extension - which (with some luck) is better than nothing: https://chrome.google.com/extensions/search?q=prefetch
Dec 9 2009,
@simon.bohlin Care has to be taken to not be overly aggressive, as this feature can easily add to overall latency. Simply put, if a user has infinite bandwidth, and infinite cache, then prefetching is always a win. If either of those resources are finite, then an attempt to prefetch may bog down the comm link (and it takes a while to say "no, I don't need this anymore") or may cause cache evictions of useful data. Looking at the other side of the equation, if the user is DEFINITELY going to need the content next, there is no downside to starting the prefetch sooner. In the end, we have a comparison of the probability of really needing the content, vs the expected degradation of other content fetches when we errantly prefetch, consuming bandwidth and/or cache space. re: "...shouldn't go via the regular cache.." There really is no choice. If you can find memory that is "free to be used by chrome," then it would probably be valuable to use it for the "regular cache." In addition, all the plumbing tends to get data from the regular cache, and to implement with a second cache would probably add a lot of complexity. Perhaps there are, or will be, ways to tag prefetched content as "less valuable to preserve extensively in cache" under some circumstances, but even the act of loading such prefetched content has the potential for causing evictions of other content. IMO, the feature of having a prefetch tag is slightly broken, as it is typically the browser that knows a) what the last mile's bandwidth is (currently) like; b) how much cache space is available. I think the server should provide a prefetch suggestions, but servers should also provide their estimate of the probability of the user navigating to each target. This would allow the browser to make the final calculation and decision about prefetching, or not. As it currently stands, the prefetch suggestion by the server is made without that additional insight (bandwidth and cache size), and the expected probability is never passed to the client (so the client can't really evaluate the value of the prefetch). That said... it would be good to implement the feature as spec'ed, and then do an evaluation of benefit. Going down that road is the only way to really move the bar in this area.
Dec 17 2009,
Replacing labels: Area-BrowserBackend by Area-Internals
Mar 25 2010,
Hi, looking at "http://www.whatwg.org/specs/web-apps/current-work/#link-type-prefetch" (I hope it's a reference document) the prefetch is about getting data from a resource (not an hyper-link) earlier because it's likely to be beneficial for the user. The document seems to guarantee that the developer of the HTML take responsibility for ensuring that downloading the resource will be beneficial. Maybe providing this feature through the dev branch will provide feedback to assess if it would in most case enhance the browsing experience? KR
Apr 6 2010,
Dirk: Are you still working on this? If not I'd like to assign this to a Noogler.
Apr 6 2010,
When this is implemented, it would be nice to gather some UMA numbers about how often <link rel=prefetch> exists on the web and the effect prefetching has on page load time. The most prominent instance of prefetching I'm aware of is on the Google SERP which may include a <link rel=prefetch> for the top search result. However, currently that page only outputs the tag to Firefox user agents presumably because that is the only user-agent that supports the it. I'll file a separate request to see if it should be enabled for Chrome's user-agent. Having that use-case in place should help us measure this feature. Browserscope measures support for <link rel=prefetch> here: http://www.browserscope.org/?category=network&v=top
Apr 6 2010,
I am not actively working on this, and unfortunately not likely to in the near to foreseeable future. I've cleared my name as owner; feel free to reassign.
Apr 9 2010,
Gavin Peters will actually be working on this, and Matthew Lloyd started implementing a very similar feature which uses an HTTP Header to indicate content to prefetch.
Apr 29 2010,
Jun 24 2010,
There's a chrome patch on my local disk for this waiting on https://bugs.webkit.org/show_bug.cgi?id=3652 , I don't know if that will make it in time.
Jul 26 2010,
Jul 28 2010,
Jul 31 2010,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=54421 ------------------------------------------------------------------------ r54421 | firstname.lastname@example.org | 2010-07-30 18:30:03 -0700 (Fri, 30 Jul 2010) | 15 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/build/features_override.gypi?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=54421&r2=54420 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/functional/prefetch.py M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/request_priority.h?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/client_socket_pool_base_unittest.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_network_transaction_unittest.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_stream_unittest.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_test_util.cc?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request.h?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/resource_type.h?r1=54421&r2=54420 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/weburlloader_impl.cc?r1=54421&r2=54420 Implement prefetching in chrome With this CL (see also issue 2910009), chrome will support basic prefetching. You can optionally deactivate prefetching with the command line argument --disable-prefetch. A new RequestPriority was created as well, IDLE, which is lower than LOWEST. Unfortunately, SPDY has only two bits for priority, so as a temporary measure (pending SPDY v3 which will have three), we have a mapping in SPDY that folds net::LOWEST and net::IDLE together. BUG= 13505 TEST=http://gemal.dk/browserspy/prefetch.php Review URL: http://codereview.chromium.org/3050016 ------------------------------------------------------------------------
Aug 20 2010,
Aug 20 2010,
This bug says we need to reduce PLT. We need to demonstrate that fact, and hopefully we'll get data pro or con in this regard from your histograms. IMO, until that is done (or at a minimum, we show this is not increasing PLT), this bug is not fixed. If you want, you could create a second bug to track the PLT so as to see if this is an optimization, and rename this bug to only cover the implementation of the feature. Although I feel confident that prefetching content can help in *some* context, I continue to be wary that the current interface may make it detrimental (even on average).
Aug 20 2010,
Jim, I think you've made a good point; I'm creating a new bug to describe improving prefetch PLT; obviously prefetch needs to prove itself in field trials before it stays. It's Issue 52878.
Feb 24 2011,
I don't see it specifically discussed above, but link pre-fetching can cause issues with anyone doing server-side web analytics. Would love to see a custom HTTP header emitted that indicates that a given HTTP request was a prefetch request. Mozilla emits a "X-moz: prefetch" HTTP header to distinguish its prefetches; if Chrome could do the same, that would be ideal.
Mar 10 2013,
Mar 13 2013,
|► Sign in to add a comment|