Intent to Ship: <link rel=preload>

719 views
Skip to first unread message

Yoav Weiss

unread,
Jan 25, 2016, 9:17:42 AM1/25/16
to blink-dev
Primary eng email

Spec

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

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

Yes

Demo link

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.
 
Web developers: Positive

Ongoing technical constraints
None

OWP launch tracking bug

Entry in Chromium Dashboard

Requesting approval to ship?
Yes.

Philip Jägenstedt

unread,
Jan 26, 2016, 1:43:10 AM1/26/16
to Yoav Weiss, blink-dev
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

unread,
Jan 26, 2016, 2:39:22 AM1/26/16
to Philip Jägenstedt, Yoav Weiss, blink-dev
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

unread,
Jan 26, 2016, 3:06:31 AM1/26/16
to Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik, Anne van Kesteren
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

unread,
Jan 26, 2016, 3:11:22 AM1/26/16
to Yoav Weiss, Philip Jägenstedt, blink-dev, Ilya Grigorik, Anne van Kesteren

Yoav Weiss

unread,
Jan 26, 2016, 3:13:13 AM1/26/16
to Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik, Anne van Kesteren
On Tue, Jan 26, 2016 at 9:11 AM, Jochen Eisinger <joc...@chromium.org> wrote:

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

Anne van Kesteren

unread,
Jan 26, 2016, 10:04:49 AM1/26/16
to Yoav Weiss, Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik
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

unread,
Jan 26, 2016, 2:31:53 PM1/26/16
to Anne van Kesteren, Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik
Current implementation only includes the types defined in fetch, where "script" is considered a subresource, restricted by the 'script-src' directive.

Anne van Kesteren

unread,
Jan 26, 2016, 2:42:10 PM1/26/16
to Yoav Weiss, Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik
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

unread,
Jan 26, 2016, 6:03:50 PM1/26/16
to Anne van Kesteren, Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik
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

unread,
Jan 26, 2016, 6:22:22 PM1/26/16
to Yoav Weiss, Jochen Eisinger, Philip Jägenstedt, blink-dev, Ilya Grigorik
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

unread,
Jan 26, 2016, 10:26:52 PM1/26/16
to Anne van Kesteren, Yoav Weiss, Jochen Eisinger, blink-dev, Ilya Grigorik
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

unread,
Jan 27, 2016, 9:49:52 AM1/27/16
to Philip Jägenstedt, Anne van Kesteren, Yoav Weiss, Jochen Eisinger, blink-dev, Ilya Grigorik
LGTM2

Jochen Eisinger

unread,
Jan 27, 2016, 9:52:04 AM1/27/16
to Rick Byers, Philip Jägenstedt, Anne van Kesteren, Yoav Weiss, blink-dev, Ilya Grigorik
lgtm3

Ilya Grigorik

unread,
Jan 27, 2016, 11:34:17 AM1/27/16
to Jochen Eisinger, Rick Byers, Philip Jägenstedt, Anne van Kesteren, Yoav Weiss, blink-dev
\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
Reply all
Reply to author
Forward
0 new messages