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.

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

Jon, is this worth re-triaging, perhaps?

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.

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

(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

Usage of modulepreload has been growing steadily at about 3x annually for the past few years despite the lack of support in Firefox. This is a key feature of the web platform and Chrome's performance is noticeably better than Firefox's on sites that leverage it.

https://chromestatus.com/metrics/feature/timeline/popularity/2232

This seems to have hundreds of ms page load impact for 1% of page views and 1% top sites (per above chrome use counter).

I checked a page (https://www.norwoodrun.com/) from the "Adoption of the feature on top sites" list and checked how it uses modulepreload. It's a Vimeo video player embed (https://player.vimeo.com/video/364490447). I ran https://www.webpagetest.org/ for the vimeo url in Firefox and Chrome; Firefox is 400ms slower to Start Render (1300ms vs 1700ms). The waterfall chart shows the module scripts being loaded in parallel in Chrome and in sequence in Firefox.

Firefox: https://www.webpagetest.org/result/230220_BiDcEZ_7AM/1/details/#waterfall_view_step1
Chrome: https://www.webpagetest.org/result/230220_AiDcTB_7JV/1/details/#waterfall_view_step1

WebKit/WebKit#10419 was merged, so WebKit now has modulepreload support along with Chrome.

We were previously able to polyfill modulepreload. However, something has changed in recent versions of Firefox making it so that using the polyfill always results in duplicate requests being issued (guybedford/es-module-shims#354). We've had a number of web dev experts looking at it and no one's been able to come up with a solution other than just living with the duplicate requests. However, that's a highly unsatisfying solution and is really increasing our desire to see this implemented natively.

This does perform the optional step of fetching descendents and linking:
https://html.spec.whatwg.org/multipage/webappapis.html#fetching-scripts:fetch-the-descendants-of-and-link-a-module-script-2

Backed out for causing leaks on nsStringBuffer.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=be054669251a3e33fc0d63c996f06ee834ab7e2d&selectedTaskRun=LLTduUGvR6yEDHjsQ_SZ2A.0

Failure log:

• browser-chrome https://treeherder.mozilla.org/logviewer?job_id=412417354&repo=autoland
• wpt https://treeherder.mozilla.org/logviewer?job_id=412423058&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/f85504ea64447bad9642e335572654bc79cb111d

Backed out changeset b288a387f790 (Bug 1425310) for causing Reflection related failures.

Backout: https://hg.mozilla.org/integration/autoland/rev/c36c7ae8449bed261c0cc6ac7446bc557dfb8b8e

Failure push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=b288a387f790cce05c73bf7057940e4c95fb53f9

Failure logs:
mochitest https://treeherder.mozilla.org/logviewer?job_id=413306564&repo=autoland&lineNumber=9368
wpt: https://treeherder.mozilla.org/logviewer?job_id=413306577&repo=autoland&lineNumber=3214
wpt: https://treeherder.mozilla.org/logviewer?job_id=413306022&repo=autoland&lineNumber=9430

Backed out changeset 1ef27d4a851e (Bug 1425310) for causing build bustages in nsHtml5TreeBuilderCppSupplement.h

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=bfb62VufT1GMzBzHPM7Gsw.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=1ef27d4a851eb1cb285d43647d7d1ee85e9e3c1b&searchStr=linux%2Cx64%2Cplain%2Cbuild-linux64-non-unified%2Fplain%2Cbp-nu

Log: https://treeherder.mozilla.org/logviewer?job_id=414931767&repo=autoland&lineNumber=53962

Backout: https://hg.mozilla.org/integration/autoland/rev/f09f1b7d47d388511d3f2a9f00e5d74d1384f14a

https://hg.mozilla.org/mozilla-central/rev/0054de12b39c

Backed out while the issue is being investigated(Bug 1832361)

• Backout link

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/ad0390325e28

Backed out for failures on /preload/modulepreload.html

• backout: https://hg.mozilla.org/integration/autoland/rev/c2e4de2178a51678ed49f1151b972c0bc96ac9fd
• push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=STRr9jVwT3S51Wx8tgGEyg.0&revision=3bb8a8b46f3c1180e5f2e7c38fb85089f9cac25a
• failure log: https://treeherder.mozilla.org/logviewer?job_id=415677598&repo=autoland&lineNumber=3843

[task 2023-05-13T17:41:02.938Z] 17:41:02     INFO - TEST-START | /preload/modulepreload.html
[task 2023-05-13T17:41:02.972Z] 17:41:02     INFO - Closing window 9c1102f3-02ef-455e-901d-f3a77324ddfb
[task 2023-05-13T17:41:16.503Z] 17:41:16     INFO - Got content assert count 1
[task 2023-05-13T17:41:16.576Z] 17:41:16     INFO - TEST-UNEXPECTED-FAIL | /preload/modulepreload.html | assertion count 1 is more than expected 0 assertions
[task 2023-05-13T17:41:16.577Z] 17:41:16     INFO - TEST-OK | /preload/modulepreload.html | took 13639ms

Other TVw failure: TEST-UNEXPECTED-FAIL | /preload/modulepreload.html | link rel=modulepreload - assert_equals: resources/dummy.js?unique expected 1 but got 0

https://hg.mozilla.org/mozilla-central/rev/e1770e1308d6

FYI FF115 Docs work for this is complete/awaiting reviews. Detail can be found in https://github.com/mdn/content/issues/27177