html5 – 资源提示的奇妙但令人困惑的想法:(a)同步?

前端之家收集整理的这篇文章主要介绍了html5 – 资源提示的奇妙但令人困惑的想法:(a)同步?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在阅读谷歌的幻灯片,以进行所谓的预优化. (对于那些感兴趣的人或那些不知道我在说什么的人,this slide总结了它.)

在HTML5中,我们可以在link元素中预取和预渲染页面. Here’s an overview.我们可以使用rel值dns-prefetch,subresource,prefetch和prerender.

第一个令人困惑的事情是,显然只有预取是在the spec中的HTML5(和5.1),但其他都没有. (Yet!)第二,浏览器支持对于(dns-)预取是可以的,但对其他人来说非常糟糕.特别是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.

请注意用户代理可以执行此操作的程度.我真的担心这将导致不同浏览器的不同实现,这将导致再次分歧.

问题仍然存在.我不清楚是否通过使用预取或其他方式同步加载外部资源(因此,当放入头部时,在加载内容之前)或异步(具有较低优先级).我猜测后者,虽然我不明白这是怎么可能的,因为链接规范中没有任何内容可以允许异步加载链接元素的内容.

解决方法

免责声明:我没有花太多时间专注于这些规格,所以我很可能错过了一些重要的观点.

也就是说,我的读者同意你的看法:如果资源是由于预优化而被提取的,那么它很可能是异步获取的,并且几乎不能保证在管道中你应该获取它的位置.

意图似乎是建议性的而不是规定性的,就像CSS will-change attribute建议渲染引擎元素应该得到特殊考虑,但没有规定行为,或者确实应该有任何特定行为一样.

there’s nothing in the link spec that would allow asynchronous loading of link elements’ content

并非所有链接都会在任何情况下加载内容(作者类型不会导致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.

(强调我的)

这似乎打开了由异步提取(或根本不提取)的链接指定的资源的大门.

猜你在找的HTML5相关文章