Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 27 users
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
M-7

Blocking:
issue 52878
issue 27111

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link rel prefetching should be implemented
Project Member Reported by jar@chromium.org, 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).



 
Comment 1 by jar@chromium.org, Jun 8 2009
I will take a look.
Comment 3 by ghost...@gmail.com, 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.
Comment 4 by arv...@gmail.com, 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).

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.
Comment 6 by jar@chromium.org, 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.
Comment 7 by darin@chromium.org, Nov 16 2009
Labels: -Area-Misc Area-BrowserBackend Mstone-X
 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.
A temporary workaround as an extension - which (with some luck) is better than nothing: 
https://chrome.google.com/extensions/search?q=prefetch
Comment 10 by jar@chromium.org, 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.
Comment 11 by oritm@chromium.org, Dec 17 2009
Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

Comment 12 by eque...@gmail.com, 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
 
Dirk: Are you still working on this? If not I'd like to assign this to a Noogler. 
Labels: Internals-Network
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
Status: Available
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.
Labels: -Mstone-X Mstone-6
Status: Assigned
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.
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.
Labels: -Mstone-6 Mstone-7
Comment 20 by mal@chromium.org, Jul 28 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=54421 

------------------------------------------------------------------------
r54421 | gavinp@google.com | 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
------------------------------------------------------------------------

Status: Fixed
Comment 23 by jar@chromium.org, 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).
Summary: link rel prefetching should be implemented (was: NULL)

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.

Comment 25 by cal...@gmail.com, 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.
Project Member Comment 26 by bugdroid1@chromium.org, Oct 12 2012
Blocking: -chromium:27111 -chromium:52878 chromium:27111 chromium:52878
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 27 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Mstone-7 -Area-Internals -Internals-Network M-7 Cr-Internals Cr-Internals-Network
Project Member Comment 28 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment