There is a very interesting article on web.dev on module worker's https://web.dev/module-workers/ where we have an ability to load worker's as preloaded module, which means they can be preloaded and even pre-parsed and prefetch their dependencies (https://web.dev/module-workers/#preload-workers-with-modulepreload).
If I am correct, not only Web-Workers can be loaded as preload module, this is applicable to any js script, font, css etc. like
<link rel="preload" href="fonts/cicle_fina-webfont.woff2" as="font" type="font/woff2" crossorigin="anonymous">
<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">
There is a saying in this article, which bothers me a lot:
Preloaded modules can also be used by both the main thread and module workers. This is useful for modules that are imported in both contexts, or in cases where it's not possible to know in advance whether a module will be used on the main thread or in a worker.
Does this mean that module loading also caches parsed code, which means modules that are used in the main thread and in a worker will not be parsed again, if we have included it using import statement on top?
However this does not happen, whenever we import module's on any realm (main thread, worker thread), they execute their import's independently and then future onward they refer to their parsed-cached instance's in their own realms.
I am really confused, what exactly is the author trying to explain. And how can we implement it.
Related articles: https://developers.google.com/web/updates/2017/12/modulepreload#does_preloading_modules_help_performance
Kaiido Thank you for the detailed response. It is very helpful.
I also searched a lot on this problematic quote and then I initiated an issue on web.dev if they could update the content. You can track on Issue
One of heaviest job for JS Engine is to parse/compile(What is Parse/Compile) our code and it plays an important role in time to interact of a web page and also there are many ways where we can improve TTI like only sending the code a user needs(code-splitting by webpack, chunks etc..), minification, tree shaking, http-caching, module-workers etc.... and also not to forget preload
Actual Definition of Preload:
The basic way you could use preload is to load late-discovered resources early. While most markup-based resources are discovered fairly early by the browser’s preloader, not all resources are markup-based. Some of the resources are hidden in CSS and in JavaScript, and the browser cannot know that it is going to need them until it is already fairly late. So in many cases, these resources end up delaying the first render, the rendering of text, or loading of critical parts of the page.
In short:
Download a resource(preparse + compile) because you know you’d need it, but you don’t yet want to execute it.
Earlier, If we inject the script at the point we want it to run, the browser will have to then download the script before it can be executed(NOTE: Browser has to do lot of stuff before executing your code), which can take a while. But Preload resolve this.
I believe the author is trying to explain the same i.e preloaded and even pre-parsed modules(Not to execute + compiled bytecode is cached) using link rel="modulepreload" Tag for later evaluation(re-compilation can be skipped).
And Finally I believe my queries are resolved. Thank you so much!
Couple of Helpful Links: