1409290 - Link: header with rel=preload

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement, P2)

Description

[Dragana Damjanovic [:dragana]]

I was working on bug 1407355 - Implement 103 Early Hints[1] and I notice that we will need a bigger rework on how we handle link headers with rel=preload. It would be good to have one place that handles it. Currently Link header is parsed only for html document (as far as I know) so for main doc, iframes...
For example test testing/web-platform/tests/preload/link-header-on-subresource.html is failing. It is testing Link headers on a stylesheet subresource.

The informational 103 response is received before a response. In this case we even do not know what type of response it will be and we do not have a document that will consume it (the doc is created during OnStartRequest and for 103 OnStartRequest will be fired later).

We also need to decide in which cases we want to start preload triggered by a 103 response (for example if load is triggered by imglib and we receive a 103 with a link header we may not want to start that preload. This is just one arbitrary example).


[1] A 103 response is an informational response and it is received before the actual response. It is foresee as a way to convey Link rel=preload headers early.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

There is a spec feature to install service workers through the link header as well.  See bug 1247141.  Its unclear if we want to implement this or not, but just wanted to mention it in case it factored into your design at all.

Comment 2

[Dragana Damjanovic [:dragana]]

Just want to mention that it would be good if someone from dom could take this bug. It would take me much longer and I am not sure if I know dom well enough to choose the best architecture here.

Andrew, can you find someone?

Comment 3

[Andrew Overholt [:overholt]]

I'll add it to our backlog.

Comment 4

[Andrew Overholt [:overholt]]

Do we need to have this for the initial shipment of rel=preload to release?

Comment 5

[Dragana Damjanovic [:dragana]]

(In reply to Andrew Overholt [:overholt] from comment #4)
> Do we need to have this for the initial shipment of rel=preload to release?

No. But since we already have a speculative load in place many use-cases for preload are irrelevant for us. They are relevant on Chrome because it is not implementing a speculative load.

This is one use-case for which make sense to have preload. This one could make difference in a page load. The other is one from bug 1405761.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Dragana Damjanovic [:dragana] from comment #5)
> (In reply to Andrew Overholt [:overholt] from comment #4)
> > Do we need to have this for the initial shipment of rel=preload to release?
> 
> No. But since we already have a speculative load in place many use-cases for
> preload are irrelevant for us. They are relevant on Chrome because it is not
> implementing a speculative load.
> 
> This is one use-case for which make sense to have preload. This one could
> make difference in a page load. The other is one from bug 1405761.

I mentioned this to Yoav this morning and it seemed he was interested in understanding more.  NI so he can find this bug and ask questions.

Comment 7

[Yoav Weiss]

All in all, there are many use-cases for using preload as a Link header. Relevant Chrome use counters show that the header variant is used in 0.6% of page views [1] vs. 15% of overall preload [2] (so 4% of overall preload usage. Not huge but not negligible either). I also suspect that usage for the header variant will grow significantly as optimization services adopt preload at a wider scale.

At the same time, I totally agree that supporting preload for the 103 scenario is tricky at best. 


[1] https://www.chromestatus.com/metrics/feature/timeline/popularity/1124
[2] https://www.chromestatus.com/metrics/feature/timeline/popularity/901


(In reply to Dragana Damjanovic [:dragana] from comment #5)
> (In reply to Andrew Overholt [:overholt] from comment #4)
> > Do we need to have this for the initial shipment of rel=preload to release?
> 
> No. But since we already have a speculative load in place many use-cases for
> preload are irrelevant for us. They are relevant on Chrome because it is not
> implementing a speculative load.

I'd love more details to better understand which preload use-cases are not relevant for Firefox.
 
> 
> This is one use-case for which make sense to have preload. This one could
> make difference in a page load. The other is one from bug 1405761.

Comment 8

[Andrew Overholt [:overholt]]

(In reply to Yoav Weiss from comment #7)
> All in all, there are many use-cases for using preload as a Link header.
> Relevant Chrome use counters show that the header variant is used in 0.6% of
> page views [1] vs. 15% of overall preload [2]
> [...]
> [2] https://www.chromestatus.com/metrics/feature/timeline/popularity/901

15% is much higher than I expected! Do you know: is it a few popular sites using it?

Comment 9

[Yoav Weiss]

I'm not sure what's the composition of that, but I do know there are very popular sites (e.g. facebook) that are using preload, so that can explain at least part of that usage.

Comment 10

[Dragana Damjanovic [:dragana]]

(In reply to Yoav Weiss from comment #7)
> All in all, there are many use-cases for using preload as a Link header.
> Relevant Chrome use counters show that the header variant is used in 0.6% of
> page views [1] vs. 15% of overall preload [2] (so 4% of overall preload
> usage. Not huge but not negligible either). I also suspect that usage for
> the header variant will grow significantly as optimization services adopt
> preload at a wider scale.
> 
> At the same time, I totally agree that supporting preload for the 103
> scenario is tricky at best. 
> 
> 
> [1] https://www.chromestatus.com/metrics/feature/timeline/popularity/1124
> [2] https://www.chromestatus.com/metrics/feature/timeline/popularity/901
> 
> 
> (In reply to Dragana Damjanovic [:dragana] from comment #5)
> > (In reply to Andrew Overholt [:overholt] from comment #4)
> > > Do we need to have this for the initial shipment of rel=preload to release?
> > 
> > No. But since we already have a speculative load in place many use-cases for
> > preload are irrelevant for us. They are relevant on Chrome because it is not
> > implementing a speculative load.
> 
> I'd love more details to better understand which preload use-cases are not
> relevant for Firefox.
>  


I am not an expert on dom at all. So please ignore this statement. I am most probably wrong.

Comment 11

[Anne (:annevk)]

It seems that Early Hints will only be supported on navigations for now. I think before we support them on subresources we need to resolve the standards issue/PR I linked above.

Comment 12

[Kershaw Chang [:kershaw]]

I think we can close this bug, since we already implemented rel=preload.