资源提示的奇妙但令人困惑的想法：（a）同步？
The fantastic but confusing idea of Resource Hints: (a)synchronous?
我一直在通读 Google 的关于所谓的 预优化 的幻灯片。 （有兴趣的或者不知道我在说什么的，this slide 稍微总结一下。）
在 HTML5 中，我们可以在 link 元素中预取和预渲染页面。 Here's an overview. 我们可以使用 rel 值 dns-prefetch、subresource、prefetch 和 prerender。
第一个令人困惑的事情是 the spec for HTML5 (and 5.1) but none of the others are. (Yet! 中显然只有 prefetch) 第二个，浏览器支持 (dns-)prefetch 是可以的，但很差对于其他人。尤其是 Firefox 不支持 prerender 令人恼火。
第三，我问自己的问题是：预取（或任何其他方法）是在浏览器读取该行时立即发生（然后阻止当前页面加载），还是它等待在后台加载资源，直到当前页面完全加载？
如果以阻塞方式同步加载，有没有办法异步或在页面加载后执行此操作？我想使用这样的 JS 解决方案，但我不确定它会 运行 异步。
var pre = document.createElement("link");
pre.setAttribute("rel", "prerender prefetch");
pre.setAttribute("href", "next-page.php");
document.head.appendChild(pre);
如果适用，请回答这两个问题！
编辑 9 月 17 日
阅读 Editor's draft 资源提示后，我发现了以下内容（重点是我的）：
Resource fetches that may be required for the next navigation can
negatively impact the performance of the current navigation context
due to additional contention for the CPU, GPU, memory, and network
resources. To address this, the user agent should implement logic to
reduce and eliminate such contention:
- Resource fetches required for the next navigation should have lower
relative priority and should not block or interfere with resource
fetches required by the current navigation context.
- The optimal time to initiate a resource fetch required for the next navigation is
dependent on the negotiated transport protocol, users current
connectivity profile, available device resources, and other context
specific variables. The user agent is left to determine the optimal
time at which to initiate the fetch - e.g. the user agent may decide
to wait until all other downloads are finished, or may choose to
pipeline requests with low priority if the negotiated protocol
supports the necessary primitives. Alternatively, the user agent may
opt-out from initiating the fetch due to resource constraints, user
preferences, or other factors.
注意用户代理可以做这个或那个的程度。我真的担心这会导致不同浏览器的不同实现，这将再次导致分歧。
问题仍然存在。我不清楚使用 prefetch 或其他方式加载外部资源是同步发生的（因此，当放在头部时，在加载内容之前），还是异步发生的（优先级较低）。我猜是后者，虽然我不明白这是怎么可能的，因为 link 规范中没有任何内容允许异步加载 link 元素的内容。
免责声明：我没有花很多时间研究这些规范，所以很可能我错过了一些重要的观点。
就是说，我的解读与您的一致：如果资源是由于 pre 优化而获取的，则很可能是异步获取的，并且几乎无法保证您应该预期在管道中的哪个位置待取。
这个意图似乎是建议性的而不是规定性的，就像 CSS will-change attribute 建议渲染引擎应该特别考虑一个元素，但没有规定行为，或者确实应该 是任何特定行为。
there's nothing in the link spec that would allow asynchronous loading of link elements' content
并非所有链接在任何情况下都会加载内容（author 类型不会导致 UA 下载 mailto: URL 的内容），我可以'除了围绕 crossorigin:
的讨论之外，在规范中找不到任何提及获取资源的内容
The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type. Some of the attributes control whether or not the external resource is to be applied (as defined below)... User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied.
（强调我的）
这似乎为异步获取（或根本不获取）link 指定的资源打开了大门。
我一直在通读 Google 的关于所谓的 预优化 的幻灯片。 （有兴趣的或者不知道我在说什么的，this slide 稍微总结一下。）
在 HTML5 中，我们可以在 link 元素中预取和预渲染页面。 Here's an overview. 我们可以使用 rel 值 dns-prefetch、subresource、prefetch 和 prerender。
第一个令人困惑的事情是 the spec for HTML5 (and 5.1) but none of the others are. (Yet! 中显然只有 prefetch) 第二个，浏览器支持 (dns-)prefetch 是可以的，但很差对于其他人。尤其是 Firefox 不支持 prerender 令人恼火。
第三，我问自己的问题是：预取（或任何其他方法）是在浏览器读取该行时立即发生（然后阻止当前页面加载），还是它等待在后台加载资源，直到当前页面完全加载？
如果以阻塞方式同步加载，有没有办法异步或在页面加载后执行此操作？我想使用这样的 JS 解决方案，但我不确定它会 运行 异步。
var pre = document.createElement("link");
pre.setAttribute("rel", "prerender prefetch");
pre.setAttribute("href", "next-page.php");
document.head.appendChild(pre);
如果适用，请回答这两个问题！
编辑 9 月 17 日
阅读 Editor's draft 资源提示后，我发现了以下内容（重点是我的）：
Resource fetches that may be required for the next navigation can negatively impact the performance of the current navigation context due to additional contention for the CPU, GPU, memory, and network resources. To address this, the user agent should implement logic to reduce and eliminate such contention:
- Resource fetches required for the next navigation should have lower relative priority and should not block or interfere with resource fetches required by the current navigation context.
- The optimal time to initiate a resource fetch required for the next navigation is dependent on the negotiated transport protocol, users current connectivity profile, available device resources, and other context specific variables. The user agent is left to determine the optimal time at which to initiate the fetch - e.g. the user agent may decide to wait until all other downloads are finished, or may choose to pipeline requests with low priority if the negotiated protocol supports the necessary primitives. Alternatively, the user agent may opt-out from initiating the fetch due to resource constraints, user preferences, or other factors.
注意用户代理可以做这个或那个的程度。我真的担心这会导致不同浏览器的不同实现，这将再次导致分歧。
问题仍然存在。我不清楚使用 prefetch 或其他方式加载外部资源是同步发生的（因此，当放在头部时，在加载内容之前），还是异步发生的（优先级较低）。我猜是后者，虽然我不明白这是怎么可能的，因为 link 规范中没有任何内容允许异步加载 link 元素的内容。
免责声明：我没有花很多时间研究这些规范，所以很可能我错过了一些重要的观点。
就是说，我的解读与您的一致：如果资源是由于 pre 优化而获取的，则很可能是异步获取的，并且几乎无法保证您应该预期在管道中的哪个位置待取。
这个意图似乎是建议性的而不是规定性的，就像 CSS will-change attribute 建议渲染引擎应该特别考虑一个元素，但没有规定行为，或者确实应该 是任何特定行为。
there's nothing in the link spec that would allow asynchronous loading of link elements' content
并非所有链接在任何情况下都会加载内容（author 类型不会导致 UA 下载 mailto: URL 的内容），我可以'除了围绕 crossorigin:
The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type. Some of the attributes control whether or not the external resource is to be applied (as defined below)... User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied.
（强调我的）
这似乎为异步获取（或根本不获取）link 指定的资源打开了大门。