Intent to Ship: <link rel=preload>

[Yoav Weiss]

Primary eng email

yo...@yoav.ws / yoav....@akamai.com

Spec

https://w3c.github.io/preload/

Summary

Add support for <link rel="preload"> (and the equivalent HTTP Link header) to tell the browser that it needs to download a certain resource in a certain priority, since this resource will be needed later during current navigation.

Motivation

The preload relationship provides a declarative fetch primitive that enables developers to initiate a resource fetch and separate fetching from resource execution. As such, preload is a low-level primitive that enables applications to build custom resource loading and execution behaviors without hiding resources from the user agent and incurring delayed resource fetching penalties. For more, see introduction and use cases sections in the spec.

Link to “Intent to Implement” blink-dev discussion

Intent to implement

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

demo

Debuggability

Preloaded resources can be seen in the Network tab, just like any other resources, and their initiator points to the initiating tag.

Interoperability and Compatibility Risk

Low.

Regarding compatibility risk, it's a new feature so no risk of breaking content. The feature can also be feature detected, enabling developers to avoid relying on it when it's not supported.

Regarding interoperability, we have positive signals from MS Edge and the WebKit teams. Firefox also show some interest.

 

MS Edge: Positive signals

WebKit: Positive signals

Firefox: Slightly positive signals

Web developers: Positive

Ongoing technical constraints

None

OWP launch tracking bug

http://crbug.com/471199

Entry in Chromium Dashboard

https://www.chromestatus.com/features/5757468554559488

Requesting approval to ship?

Yes.

[Philip Jägenstedt]

There are a bunch of open spec issues, is shipping this effectively going to decide the outcome of any of those issues? If so, can they be closed before shipping?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jochen Eisinger]

There's also an open spec issue wrt the referrer policy to use, but I guess that can also be addressed after shipping the initial version.

[Yoav Weiss]

The only implementation-relevant open spec issue is Preload and CSP. The main open questions there are with regard to the addition of new `as` types, so that iframes, objects, worker-scripts, etc. Shipping current implementation won't impact the decision there AFAICT. 

+Ilya and Anne for their opinions on that.

On Tue, Jan 26, 2016 at 8:39 AM, Jochen Eisinger <joc...@chromium.org> wrote:

There's also an open spec issue wrt the referrer policy to use, but I guess that can also be addressed after shipping the initial version.

I agree that we need to decide this, but couldn't find an open issue on this matter (or on mixed content policy, which is also relevant). I also agree that this shouldn't necessarily block shipping. 

[Jochen Eisinger]

https://github.com/w3c/webappsec-referrer-policy/issues/15

[Yoav Weiss]

On Tue, Jan 26, 2016 at 9:11 AM, Jochen Eisinger <joc...@chromium.org> wrote:

https://github.com/w3c/webappsec-referrer-policy/issues/15

 

Thanks for the pointer! :) I'll open a bug pointing to that discussion on the preload repo.

[Anne van Kesteren]

On Tue, Jan 26, 2016 at 12:06 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> The only implementation-relevant open spec issue is Preload and CSP. The
> main open questions there are with regard to the addition of new `as` types,
> so that iframes, objects, worker-scripts, etc. Shipping current
> implementation won't impact the decision there AFAICT.
> +Ilya and Anne for their opinions on that.

If the current implementation does not include that feature, agreed.


--
https://annevankesteren.nl/

[Yoav Weiss]

Current implementation only includes the types defined in fetch, where "script" is considered a subresource, restricted by the 'script-src' directive.

[Anne van Kesteren]

On Tue, Jan 26, 2016 at 11:31 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> Current implementation only includes the types defined in fetch, where
> "script" is considered a subresource, restricted by the 'script-src'
> directive.

Ah interesting. When will Fetch integration be defined then? E.g., if
you preload something and another request gets there through a
redirect, does it end up using the preloaded resource? (And is that
response then changed to account for the possibly mixed content
violating redirect?)


--
https://annevankesteren.nl/

[Yoav Weiss]

It seems that in this case the resource will not be reused, which if I understand you correctly is the right behavior. I'm adding a test to that effect. 

[Anne van Kesteren]

On Tue, Jan 26, 2016 at 3:03 PM, Yoav Weiss <yo...@yoav.ws> wrote:
> It seems that in this case the resource will not be reused, which if I
> understand you correctly is the right behavior. I'm adding a test to that
> effect.

It can probably be made to work either way, as long as we're careful
and dot all the ı's.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

So it sounds to me like shipping the current implementation isn't
going to create trouble for any of the outstanding issues, and simply
not reusing preloaded redirects sounds like a safe starting point.

LGTM1

[Rick Byers]

LGTM2

[Jochen Eisinger]

lgtm3

[Ilya Grigorik]

\o/

Re, Fetch integration: agree that the remaining bits are non-blocking. For those interested in following along: https://github.com/w3c/preload/issues/30