Chrome的新版本增加了对<link rel="preload">的支持。他们发布了很多关于原始文档参考的信息。有人可以提供关于它如何工作的简单解释，与没有rel="preload"的情况相比有什么不同。
答案 0 :(得分：5)
在最基本的形式中，它将具有link的{{1}}设置为高优先级，与预取不同，浏览器可以决定它是否是一个好主意，preload将强制浏览器这样做。
=== 更深入的了解： ===
这是W3c的一个片段
许多应用程序需要对资源何时进行细粒度控制 获取，处理并应用于文档。例如， 某些资源的加载和处理可能会被推迟 应用程序，以减少资源争用和提高性能 初始负荷。通常通过移动来实现此行为 资源获取到由...定义的自定义资源加载逻辑 应用程序 - 即通过注入启动资源提取 元素，或通过XMLHttpRequest，当特定的应用程序 条件得到满足。
但是，也有一些情况需要获取一些资源 尽早，但他们的处理和执行逻辑是 受特定应用要求的限制 - 例如依赖 管理，条件加载，订购保证等。 目前，如果没有a，则无法提供此行为 绩效惩罚。
通过现有元素之一声明资源（例如img， 脚本，链接）耦合资源获取和执行。然而，一个 应用程序可能希望获取，但延迟执行资源 直到满足某些条件。使用XMLHttpRequest获取资源 避免上述行为会因隐藏而导致严重的性能损失 来自用户代理的DOM和预加载解析器的资源声明。 仅在相关JavaScript时调度资源提取 由于大多数页面上存在大量阻塞脚本而被执行 引入显着延迟并影响应用程序性能。该 链接元素上的preload关键字提供声明性提取 解决上述启动早期用例的原语 从资源执行中获取和分离获取。因此， preload关键字用作启用的低级原语 构建自定义资源加载和执行行为的应用程序 没有从用户代理隐藏资源并导致延迟 资源取得罚款。
例如，应用程序可以使用preload关键字来启动 CSS资源的早期，高优先级和非呈现阻塞提取 然后，应用程序可以在适当的时间应用它：
rel="preload"以下是对W3c的深入了解：https://w3c.github.io/preload/
但如果您计划使用它，我会小心，因为浏览器支持不是很好，全球支持率只有0.18％。
答案 1 :(得分：2)
Google Developers建议rel="preload"用于更早地请求字体，以在CSSOM准备就绪时使它们可用。
字体的延迟加载带有重要的隐含含义，可能 延迟文本渲染：浏览器必须构造渲染树， 在知道哪个之前，它取决于DOM和CSSOM树 呈现文本所需的字体资源。结果，字体 其他重要资源之后，请求被延迟了很长时间，并且 浏览器可能被阻止呈现文本，直到资源被 提取。
用作：
<link rel="preload" href="/fonts/my-font.woff2" as="font">
<link rel="stylesheet" href="/styles.min.css">
另外，请注意：
并非所有浏览器都支持
<link rel="preload">，在这些浏览器中， 只会被忽略。但是每个浏览器 支持预加载还支持WOFF2，因此始终是格式 您应该预加载。