Enable using "modulepreload" instead of "preload" for module links

[TxHawks]

Feature request

@janicklas-ralph introduced the module/nomodule pattern in #7704, which allows modern browsers to load javascript through the use of es2015 modules, and therefore, more modern, less transpiled-down code based on the support vector of browsers supporting modules, while still offering more a fallback to less modern browsers.

However, the pull request still uses <link rel="preload" /> to preload the modules. As suggested in this Google Developers guide, and again today by Phill Walton using <link rel="modulepreload" /> would be more efficient, since it doesn't only download the script, but also starts processing and compiling it immediately - off the main thread.

One caveat though, is that modulepreload is only supported in chromium-based browsers.

Describe the solution you'd like

A configurable option to use modulepreload instead of preload for module files. Making this configurable allows optimizing for the bulk of an application's user-base. I guess keeping preload as the default makes sense for the time being.

Describe alternatives you've considered

Keeping preload as it is now, or alternatively, using modulepreload as default and making the tradeoff very clear in the documentation.

[timneutkens]

Browser support for modulepreload is not at a desirable point imo: https://caniuse.com/#search=modulepreload

[TxHawks]

Like I said, it's only supported in chromium-based browser, which is why I think it should be a configurable option.

However, for many sites, the vast majority of users use chromium-based browsers. Since preload behavior is an optimization that doesn't break functionality when it doesn't work, I think it's fair to allow the developer to change the behavior.

Another option worth investigating is that according to the spec the rel attribute is a space-separated list. I know that <link rel="preconnect dns-prefetch /> works and it might be worth testing what the effect of <link rel="modulepreload preload" /> is.

[Timer]

Closing due to lack of browser support and Next.js not having modern bundles by default right now. We can explore this in the future!

Thanks for the detailed issue.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.