859177 - Investigate link rel=subresource prefetching

Status: NEW

(Core :: Networking, enhancement, P5)

Description

[Greg Lowe]

Use case: prefetcher can start loading a file before javascript parse/execute and XHR send.

Note - this is different that prefetch, as it applies to resources within the currently loading page, not a future navigation.

<link rel="subresource" href="blah.json" />

<script>
   var req = new XMLHttpRequest();
   req.onload = function() {
      console.log(this.responseText);
   };
   req.open("get", "blah.json", true);
</script>

See chromium docs:
http://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource

Not sure about standards discussion.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Patrick, is that even a useful operation with our current network stack?  Last I checked if the prefetch were not done by the time open() is called, the open() would just end up doing a new request...

Comment 2

[Patrick McManus [:mcmanus]]

bz, this would take some hacking but its an interesting use case :)

I think we'd have to change the channel to block on an in-progress cache entry with the assumption that the result will be cacheable in the case this subresource link syntax was used.

I have seen js that does a whole bunch of XHRs off onPageLoad to essentially load the cache for reuse by other script functions.. its basically an automation of that.

Honestly, this reminds me a lot of spdy push.. which has a similar mechanism in that it moves resources before they are referenced by the dom. (in that case there isn't an official markup syntax for it.. the server is in charge of omnisciently knowing, but adding markup would be one way to implement that.. ala server side includes but with better cachability.)

Comment 3

[Nicholas Shanks]

Do not forget that this is also available via the HTTP header (tbh, that's where I expect it will be most useful), e.g:

Link: </styles.min.css>;rel="stylesheet subresource"

[Though perhaps for a non-alternative stylesheet, rel=subresource may not even be necessary, since the link will have a high priority anyway.]

Comment 4

[Florian Bender]

Honza, is this something for Bug 941841? :)

My use case would be lazy-loading of (cross-origin) webfonts to not slow down rendering in bad networks. Subresource prefetching should allow having a shorter (or no) FOUC were network conditions are good.

Comment 5

[Honza Bambas (:mayhemer)]

Not sure this is related to cache at all.

What's FOUC ?

Comment 6

[Florian Bender]

Flash of unstyled content (in this case: wrong font).

(In reply to Honza Bambas (:mayhemer) from comment #5)
> Not sure this is related to cache at all.

The new cache includes new prefetching (and some prioritized loading) logic, doesn't it? And this bug is essentially about a prefetching mechanism. Or was that simply about the database stuff, and actual prefetching is handled by another component (e.g. the preloader – which category should this bug be in, then)?

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Florian Bender from comment #6)
> Flash of unstyled content (in this case: wrong font).
> 
> (In reply to Honza Bambas (:mayhemer) from comment #5)
> > Not sure this is related to cache at all.
> 
> The new cache includes new prefetching (and some prioritized loading) logic,
> doesn't it? 

It can load some files from disk sooner then others despite order of AsyncOpenURI calls for them.  But that is all controlled by the consumer, cache itself just dumbly listens to commands from above.

> And this bug is essentially about a prefetching mechanism. Or
> was that simply about the database stuff, and actual prefetching is handled
> by another component (e.g. the preloader – which category should this bug be
> in, then)?

Hmm.. hard to say.  Does the preloader already exists?  Is that something around Nick's Network Seer?

I personally wanted to make the new cache smarter like doing preloads and offer prefetch/preconnect data directly, but the new cache work was already enough complicated that I moved the work and even planning to some future point.  And then Nick wrote his Seer.

Comment 8

[Florian Bender]

Ah, yes, Seer is probably a better match here.

Comment 9

[j.j.]

I'd say WONTFIX since Chrome removes <link rel=subresource> just now?

https://crbug.com/581840

Comment 10

[j.j.]

btw, replacement should be <link rel=preload>, bug 1222633

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 13

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 14

[j.j.]

This bug is obsolete and should be closed. Chromium (Chrome 50) removed support:

"Remove support for the "subresource" rel of HTMLLinkElement, as it is not useful, proprietary, and buggy. "
https://www.chromestatus.com/feature/6596598008119296