Implement link rel="modulepreload"
Categories
(Core :: DOM: Core & HTML, enhancement, P3)
Tracking
()
People
(Reporter: d, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-needed)
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
Updated•3 years ago
|
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Preloading is currently disabled and will be re-enabled by bug 1394778.
Reporter | ||
Comment 2•3 years ago
|
||
FWIW the processing module for modulepreload is unrelated to that for preload so I don't think bug 1394778 is actually a dependency.
Updated•3 years ago
|
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.
Description
•