<script type="module"> 加载性能

Question

我想<script type="module"> 的一个流行用例将是加载一个“主模块”，通过import 语句树解决项目的所有依赖项。但是，在 Web 上，这似乎会造成加载瓶颈，因为浏览器在解析它们的依赖项以找到 import 之前无法知道要下载哪些脚本。将此与在最初交付的 HTML 文件中的单独 <script> 元素中引用所有项目脚本的情况进行对比。脚本可以在解析 HTML 的同时和之后并行下载。

<script type="module"> 会造成加载瓶颈吗？一个页面上的多个<script type="module">元素是否可以相互提供依赖关系，因此浏览器不一定需要下载和解析JavaScript来确定下一步要下载什么？

我想这将是 HTTP/2 PUSH_PROMISE 的一个用例？服务器需要静态分析 JavaScript 文件并提前确定它们的依赖关系。但是即使可以告诉浏览器提前下载模块，我想知道在解析 import 之前，推送的模块是否仍然不会执行。至少对于<script>，我知道他们会一有机会就执行。

Answer 1

<script type="module"> 加载模块的效率可能与<script> + 动态模块加载器一样有效。

多个<script type="module">可以相互提供依赖。来源（via IRC）：

我：如果我有一个<script type="module" src="a.js">，其中“a.js”将export一个模块，我也有<script type="module" src="b.js">，而“b.js”将import "./a.js";，将相同的实例以前<script type="module" src="a.js">创建的模块可以用吗？

annevk：如果它们在同一个文档中，是的

这是因为重复导入是从每个窗口的“模块映射”中提取的（请参阅the spec）：

如果 module map 包含带有键 url 的条目，则使用该条目的值异步完成此算法，并中止这些步骤。

通过创建多个<script type="module"> 元素，我们可以让浏览器在第一时间知道它需要下载的脚本，从而避免“依赖树瓶颈”。

“模块脚本”推迟模块的评估，直到它的所有依赖项都被获取；而“经典脚本”只是执行，因此动态模块加载器理论上可以更快。但是，如果该动态模块加载器也阻止了依赖项的执行，那么它的任务可能需要与import 一样长的时间才能完成。此外，对性能的真正威胁可能是网络。相比之下，评估可能是如此之快，以至于它是微不足道的。