Intent to Ship: Link rel=modulepreload

[Kunihiko Sakamoto]

Contact emails

Implementation: ksak...@chromium.org

Spec: dom...@chromium.org

Explainer

Please refer to the design doc and the spec's explanatory material

Spec

Spec: https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload

Design doc: https://docs.google.com/document/d/1WebH4IOCswACUbaczx5cGQPVl5mnqcieOd4MRJM2syk/edit?usp=sharing

TAG review: https://github.com/w3ctag/design-reviews/issues/213

Summary

Add support for the "modulepreload" rel value in <link> element and Link: header, providing a way to initiate early (and high-priority) loading of module scripts.

This feature is implemented in M64 behind the “Experimental Web Platform features” flag.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ynkrM70KDD4

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

Yes.

Demo link

https://irori.github.io/modulepreload-demo/

Debuggability

Preloaded modules are visible in the devtools network panel, and the "Initiator" column references the <link rel=modulepreload> element.

Risks

Interoperability and Compatibility

Medium. Chrome would be the first browser to support this feature.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive in wanting this ability, although some are unsure about the specific shape of the solution, wishing rel=preload would "just work".

Ergonomics

This will be used along with <script type=”module”>, to improve the latency of loading module graphs or to pre-load module graphs that will be loaded later.

Activation

This is an optional feature, so it’s easy for developers to take advantage of. Unsupported browsers would just ignore <link> with rel=modulepreload.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. https://wpt.fyi/preload/modulepreload.html

Entry on the feature dashboard

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

[Chris Harrelson]

LGTM1

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO5vZCjLpNf8dnHkq4yUJCcsfi8B2C8Eu%2BnTZYoRDNpnd4r%2BsA%40mail.gmail.com.

[Ojan Vafai]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO5vZCjLpNf8dnHkq4yUJCcsfi8B2C8Eu%2BnTZYoRDNpnd4r%2BsA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-EHiQ-BzcwuZyaPq4WEfjYwy9PNLJ3XMF2gBhm3owtfA%40mail.gmail.com.

[TAMURA, Kent]

LGTM3.

TAG Review didn't raise significant issues. It's unfortunate that other browser vendors have no signals, but this feature is a hint for performance, and it would not cause interoperability issues.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO5vZCjLpNf8dnHkq4yUJCcsfi8B2C8Eu%2BnTZYoRDNpnd4r%2BsA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-EHiQ-BzcwuZyaPq4WEfjYwy9PNLJ3XMF2gBhm3owtfA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTuMZaVU3rFyqVqqV3BJNL77TJz84j4Yy-5C%2B%3D1iG9L-oQ%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Daniel Bratell]

This is post 3xLGTM but I'm wondering if the reason "rel=preload" doesn't work is an implementation specific reason and if so, can the implementation be changed instead?

/Daniel

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO5vZCjLpNf8dnHkq4yUJCcsfi8B2C8Eu%2BnTZYoRDNpnd4r%2BsA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-EHiQ-BzcwuZyaPq4WEfjYwy9PNLJ3XMF2gBhm3owtfA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTuMZaVU3rFyqVqqV3BJNL77TJz84j4Yy-5C%2B%3D1iG9L-oQ%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFva_ywhoieVDmJaaxe5%2BYnTd_2HP_sh%2B4sPfKpCfbjhA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Domenic Denicola]

> This is post 3xLGTM but I'm wondering if the reason "rel=preload" doesn't work is an implementation specific reason and if so, can the implementation be changed instead?

Nah, it's pretty endemic to the preload infrastructure. The spec has a few notes, as does the design doc, but https://github.com/whatwg/fetch/issues/486#issuecomment-282044172 is probably the most consolidated summary. The TL;DR is that it has a very different processing model from preload and the two should not be conflated into a single rel="" value.

[Yoav Weiss]

I have another question: the spec states that eventually, `modulepreload` will recursively preload all dependencies, but current implementation does not do that.

What's the transition plan between the two? Will authors be able to detect the browser's behavior with respect to recursive preloading?

On Fri, Feb 16, 2018 at 5:45 PM Domenic Denicola <d...@domenic.me> wrote:

> This is post 3xLGTM but I'm wondering if the reason "rel=preload" doesn't work is an implementation specific reason and if so, can the implementation be changed instead?

Nah, it's pretty endemic to the preload infrastructure. The spec has a few notes, as does the design doc, but https://github.com/whatwg/fetch/issues/486#issuecomment-282044172 is probably the most consolidated summary. The TL;DR is that it has a very different processing model from preload and the two should not be conflated into a single rel="" value.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CO2PR05MB2679FC4720EE151659365F5BDFCB0%40CO2PR05MB2679.namprd05.prod.outlook.com.