1425310 - (modulepreload) Implement link rel="modulepreload"

Status: NEW

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

Description

[Domenic Denicola]

modulepreload is a new link relation that behaves similar to preload, but different in several key ways. For example, it interprets its attributes and changes to them differently; it uses the module map instead of the preload cache; and it allows optionally fetching descendant modules as an optimization.

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

Tests: https://github.com/w3c/web-platform-tests/blob/master/preload/modulepreload.html

Comment 1

[Jon Coppeard (:jonco)]

Preloading is currently disabled and will be re-enabled by bug 1394778.

Comment 2

[Domenic Denicola]

FWIW the processing module for modulepreload is unrelated to that for preload so I don't think bug 1394778 is actually a dependency.

Comment 3

[Westbrook]

Until recently (I'd need to parse Firefox versions to confirm when this occurred), web pages could leverage rel="preload" to ensure the early download of a JS file (and as spec'd early parsing) regardless of whether the script was later loaded as type="module" or not. However, the current experience is that while the preload occurs, a script included in the page as type="module" is then downloaded a second time. See https://modern-web.dev/ as an example as discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=1178198#c9

It seems Chrome is likely to move to this more strict interpretation of the rel="preload" spec and pages will need to move to rel="modulepreload" to get performance benefits in type="module" scripts anywhere, so I was hoping it would be possible to get an update on whether Firefox saw this as something they'd be able to implement.

Comment 4

[BenjaminAster]

I think <link rel="modulepreload"> is currently one of the most important features to be implemented in Gecko, as pages load a lot slower without this.

Without modulepreload, the user agent must first download the primary JavaScript file before it can download its dependencies specified in an ES6 import. These imported JavaScript modules can import other modules as well, and so on. Because of this, the user agent has to make several network requests successively instead of making them all at once in parallel. This results in a noticeably slower page loading speed.

To better illustrate this, here is a screenshot of Chromium's waterfall of JavaScript files of some website of mine and here is the same website's JavaScript files download timeline in Firefox. Notice how without modulepreload support, Gecko has to wait for the first file to be downloaded before it can download the other files imported by it. These files themselves import other files which then also import yet another set of files. Blink however can download all JavaScript files in parallel, which results in a ~4 times better loading speed.

Blink is currently the only browser engine that supports this, which is a shame because preloading JavaScript modules is an essential thing that modern browsers are supposed to support. This has been specified for over five years now in the official HTML specification, which is another reason to implement this. As @Westbrook already pointed out, there is no way to polyfill this feature with things like <link rel="preload">.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Jon, is this worth re-triaging, perhaps?

Comment 6

[Ben McCann]

I'm a maintainer of Svelte / SvelteKit and contributor to Vite, which are large and growing projects in the JS ecosystem (https://2021.stateofjs.com/en-US/conclusion). We are using ESM modules almost exclusively and are seeing more and more of the JS ecosystem moving this direction. Vite and SvelteKit provide modulepreload on all pages out-of-the-box and performance is greatly improved in Chrome compared to Firefox as a result. I would find it very valuable if the priority and severity were bumped on this one.

Comment 8

[Noam Rosenthal]

I saw that https://bugzilla.mozilla.org/show_bug.cgi?id=1773056 was marked as duplicate of this, are Mozilla in favor of implementing modulepreload also in link headers? See spec PR: https://github.com/whatwg/html/pull/7862

Comment 9

[Sebastian Zartner [:sebo]]

(In reply to Noam Rosenthal from comment #8)

I saw that https://bugzilla.mozilla.org/show_bug.cgi?id=1773056 was marked as duplicate of this, are Mozilla in favor of implementing modulepreload also in link headers? See spec PR: https://github.com/whatwg/html/pull/7862

As there was no feedback on this question and they are actually two different features, I've reopened bug 1773056 now. Though Yoshi, feel free to mark the other bug as duplicate again if you think both the HTML attribute and the HTTP header will be implemented in this bug.

Sebastian