Add PreconnectPreferringCache for resources that are likely in the cache |
||||||
Issue descriptionThe existing preconnect system will blindly issue a preconnect even if the desired resource is resident in cache without need of revalidation. We should add an option to preconnect that aborts if the resource is in the cache (and doesn't need revalidation). This will be useful in the future as we'll want to use the preload scanner to preconnect webfonts (which are often resident in cache with long max age).
,
Mar 31 2016
,
May 11 2016
What blockers are there for implementing this today? We'd like misses to be fast, therefore it seems like this should only be implemented for SimpleCache, with the in-memory index. Should we wait until metadata (i.e. whether the resource needs revalidation) is in the index?
,
May 11 2016
Is there anything today that could make use of this? Is there a doc about preconnecting webfonts? When is that happening?
,
May 11 2016
There's a preload discussion on 502371 that's related. Maybe we should hold off on this until we know exactly what the consumers will look like.
,
Jun 10 2016
Looks like issue 619027 will be a consumer of this (preconnecting directly from the BG parser thread). This will prewarm the cache for entries that will be looked up, and for those not in the cache we can preconnect. Talked to mmenke@ about this and he thought that URLRequest w/ load only from cache could work, though we may have to do some work to figure out if the entry needs revalidation. I can look into that. ccing mmenke@.
,
Jun 10 2016
,
Jul 14 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 23 2018
BG parser thread is no more, WontFixing since there are no definite consumers. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by csharrison@chromium.org
, Mar 31 2016