Open Bug 1425310 Opened 3 years ago Updated 2 months ago

Implement link rel="modulepreload"

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Version:
55 Branch
Type:
enhancement

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
Priority: -- → P3
Preloading is currently disabled and will be re-enabled by bug 1394778.
Depends on: 1394778
FWIW the processing module for modulepreload is unrelated to that for preload so I don't think bug 1394778 is actually a dependency.

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.

You need to log in before you can comment on or make changes to this bug.