I can recreate the issue locally. Thanks for the test case! :)

BTW, this works as expected in Firefox. 
Also prefetch doesn't seem to honor cache headers i.e. Chrome caches the response even if there are no cache headers. Should I file a separate issue for it?

Chrome caches prefetched resources for a short period even if they're non-cacheable (to avoid double downloads)

So the priority seems to be set (as it should be) to "very low", but gaps in resource discovery mean that these resources go out before higher priority resources that are discovered later.

One way to go about this is to pipe the prefetch info all the way to ResourceScheduler (since there are other VeryLow resources) and then add some kind of fixed delay since last request before sending out prefetch requests.

Nate/Charlie/Pat - does that make sense?

I would prefer throttling the prefetch in the renderer. Blink should know we are early in a page load and there are other critical resources coming. Worst case I wouldn't be opposed to send these out at DCL.

Note that we shouldn't be adding any more logic to ResourceScheduler, because rdsmith is in the process of removing it.

A few thoughts off the top of my head:

- We should probably just queue them up in the renderer until the load event and only pass them through then.  That way there's no races and it's guaranteed to have loaded all of the main resources.

- Right now, VeryLow just get a lower priority than other requests but if they are on a separate host they will still contend (up to the 10 concurrent low priority resources at a time).  If we really want them to only go out during idle times we need to plumb that logic and it might need a discrete priority for "Idle"

- As far as caching in general, "no" caching headers means browsers can use heuristics (custom logic aside for prefetch).  If you don't want things generally cached you need to be explicit with a no-cache directive.

Delaying till DCL (or even onload) makes sense. And if we're doing that, keeping this logic in the renderer would certainly simplify things. Thanks!

I'd recommend onload over DCL.  DCL will still compete with the images that this specific case is trying to avoid.

 Issue 652746  (loosely prerenders aren't completing quickly enough, priority should be raised above IDLE) might also be of interest to folks on this bug.  That issue is closed, but discussion is still ongoing about whether/how to extend the Android fix (which was to raise the priority) to other platforms.

I would be supportive of delaying until onload (instead of DCL). Has a decision been made on which of these points we want to move ahead with on this particular issue?

I'm working on requestResource refactoring that's required in order to split prefetch request processing from the actual loading: https://codereview.chromium.org/2660213003/

I have a WIP patch to resolve this at https://codereview.chromium.org/2751973005/ but csharrison@ rightfully argued that it may regress certain usage patterns. I'm starting to think this might require some explicit control that'd enable Web developers to express their preference one way or the other.

Yoav, are you actively working on this? If not, do you mind if we take this over?

cc his new chromium account just in case

This has been stagnant as we had no good ideas on how to resolve this without regressing some of the use-cases. If you have ideas on tackling that, or if the urgency here is higher than it used to be, please let me know.