Jac*_*son 10 html javascript performance networking module
我想一个流行的用例<script type="module">是加载一个"主模块",通过一个import语句树解决所有项目的依赖关系.但是,在网络上,似乎这会产生一个加载瓶颈,因为浏览器在解析其依赖项之前无法知道要下载哪些脚本import.与此对比的情况是,所有项目的脚本都<script>在最初提供的HTML文件中的单独元素中引用.在解析HTML时,脚本可以全部并行下载.
会<script type="module">造成加载瓶颈吗？<script type="module">页面上的多个元素是否可以为彼此提供依赖关系,因此浏览器不一定需要下载和解析JavaScript以确定下一步要下载的内容？
我想这将是HTTP/2 PUSH_PROMISE的用例？服务器需要静态分析JavaScript文件并提前确定它们的依赖关系.但即使可以告诉浏览器提前下载模块,我想知道推送的模块在解析之前是否仍然不会执行import.至少<script>,我知道他们会在第一时间执行.
<script type="module">可能像<script>+动态模块加载器一样有效地加载模块.
多个<script type="module">可以为彼此提供依赖关系.来源(通过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:如果他们在同一份文件中,是的
这是因为重复导入是从每个窗口"模块映射"中获取的(请参阅规范):
如果模块映射包含带有密钥URL的条目,则使用该条目的值异步完成此算法,并中止这些步骤.
通过创建多个<script type="module">元素,我们可以通过让浏览器在第一时间知道需要下载的脚本来避免"依赖性树瓶颈".
"模块脚本"推迟对模块的评估,直到获取所有依赖项为止; 而"经典脚本"只是执行,因此理论上动态模块加载器可以更快.但是,如果该动态模块加载器也阻止对依赖项的执行,那么它的任务可能需要与完成时一样长import.此外,对性能的真正威胁可能是网络化; 相比之下,评估可能是如此之快,以至于它是微不足道的.