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 18 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 58464



Sign in to add a comment

link rel=prefetch loads resources prematurely

Reported by mbelshe@chromium.org, Nov 1 2010

Issue description

link rel=prefetch should load resources *after* this page is complete.

What steps will reproduce the problem?
1. http://www.belshe.com/test/prefetch2.html
2. This page loads a resource (cuzillion.com gif) via prefetch, and also has an inline image.
3. Look at the trace, the cuzillion.com gif is loaded in parallel with the inline image.

What is the expected output? What do you see instead?
cuzillion.com gif should be loaded after all other content completes.

From about:net-internals (these times are in millisecs)

main page start:        65908
main page finish:       66081
chrome_logo.gif start:  66083
cuzillion.gif start:    66083   <----- TOO EARLY!    
chrome_logo.gif finish: 66116
cuzillion.gif finish:   68201

 
Blockedon: 58464
marked this as blocked on 58464, since really we should be handling this with the IDLE priority in the network stack.
Labels: Feature-ContentPrefetch
Status: Assigned
Project Member

Comment 4 by bugdroid1@chromium.org, Mar 10 2013

Blockedon: -chromium:58464 chromium:58464
Labels: -Area-Internals Cr-Internals
It appears that rel=prefetch resources block onload event in Chrome - doh?

Simple page that tries to prefetch two resources: http://jsbin.com/efodun/9/quiet

- FF does not block onload 
- Chrome blocks onload... and then cancels both requests for some reason? (Not sure what's up with cancel - any ideas?)
firefox.png
85.5 KB View Download
chrome.png
61.6 KB View Download
Labels: Hotlist-Recharge Hotlist-Recharge-Stale
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  It has also not been modified in a year (prior to this update).  Thanks for helping out!

-Anthony
Cc: y...@yoav.ws pmeenan@chromium.org
Labels: -Hotlist-Recharge hotlist-recharge
I think we can close this bug as WontFix / works as intended. 

Prefetch requests are initiated with lowest priority [1], which is the correct behavior. I don't think we should wait for onload (or some other arbitrary event) to initiate these fetches. On the other hand, prefetch shouldn't block onload.. but we should open a separate bug for that.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp&q=ResourceFetcher.cpp&sq=package:chromium&type=cs&l=126-127
The way this works is a significant issue for us at Inkbunny.net - in our "wide" mode we may typically be displaying multi-megabyte images, and we want to decrease the load times, so we've added preload elements for images on "nearby" pages.

Since preloads are in <head>, Chrome starts to load them immediately, before any other resources - which'd be fine by itself, *but* when network bandwidth is constrained it starves the /current/ page's image, slowing the art the visitor originally intended to view.

Part of the problem seems to be that Resource::Image and Resource::LinkPrefetch have the _same_ priority, ResourceLoadPriorityVeryLow /  WebURLRequest::PriorityVeryLow / net::IDLE:
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/web_url_loader_impl.cc&sq=package:chromium&type=cs&l=135&rcl=1461179858

In our use-case, images on the current page are more important than *any* preload - or images loaded by pre-render for that matter (we're already preloading the main image on that page, but there may still be user icons to consider).

Dynamic prerender links aren't yet deployed in Firefox (bugzilla 580313). We don't want to do user-agent sniffing - let alone both client-side and server-side - but currently it seems the only way to get the behaviour we want: on-page resources having priority over preload.

Issue 58464 starts to addresses this, but stopping new requests being launched may not be enough; existing prerender requests may need to be deferred if bandwidth is insufficient to load resources on the current page simultaneously.

---
Related code exploration:

This comment suggests ClientSocketPool prioritization only matters if there aren't yet any available sockets.
https://code.google.com/p/chromium/codesearch#chromium/src/net/socket/client_socket_handle.h&cl=GROK&gsn=net/socket/client_socket_handle.h&l=49

The priority queue is FIFO among requests of equivalent priority:
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/priority_queue.h&cl=GROK&gsn=net/socket/client_socket_handle.h&rcl=1461179858&l=25

Priority ends up in net::URLRequest via ResourceDispatcherHostImpl::BeginRequest
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/resource_dispatcher_host_impl.cc&l=1456&cl=GROK&gsn=priority&rcl=1461179858
This looks to be passed through HttpNetworkTransaction to HttpBasicStream/WebSocketBasicHandshakeStream… though I'm unsure it's used:
https://code.google.com/p/chromium/codesearch#chromium/src/net/websockets/websocket_basic_handshake_stream.cc&cl=GROK&l=460
https://code.google.com/p/chromium/codesearch#chromium/src/net/http/http_basic_state.cc&cl=GROK&gsn=priority&rcl=1461179858&l=28
https://code.google.com/p/chromium/codesearch#chromium/src/net/http/http_basic_stream.cc&cl=GROK&gsn=priority&rcl=1461194223&l=131

ClientSocketPoolBaseHelper::Group::InsertPendingRequest


Cc: -pmeenan@chromium.org

Sign in to add a comment