你打开浏览器的网络标签时，你会看到大量的活动。资源正在下载，信息正在提交，事件正在记录，等等。
由于有太多的活动，有效地管理这些流量的优先级变得至关重要。带宽争用是真实存在的，当所有请求同时触发时，有些 HTTP 请求的优先级并不像其他请求那样高。例如，如果你必须选择，你可能更希望某人的付款请求成功完成，而不是仅仅表示他们尝试过的分析请求。而让你的主要图片尽快显示无疑比在页面底部渲染你的标志更为重要。
幸运的是，浏览器拥有越来越多的工具来帮助优先处理所有这些网络活动。这些“优先级提示”帮助浏览器在资源有限时，对哪些请求应该优先处理做出更少的假设和更明确的决策。
这是一套有用的工具，当它们得到很好的利用时，它们可以对页面性能产生实质性的影响，包括那些越来越重要的核心网络指标。让我们探索其中的一些，以及它们最有帮助的一些场景。
优先加载的资源
现代浏览器有一个受到良好支持的方法，可以告诉浏览器当前页面最终需要哪些资源：<link rel="preload" ... />。当它放在文档的<head>中时，浏览器会被指示尽快以“高”优先级下载它。
公平地说，浏览器中的预加载扫描器已经非常擅长这方面的工作。因此，预加载通常最适用于晚些时候发现的资源 – 任何不直接由你的 HTML 加载的东西，比如通过内联样式属性加载的背景图像。但它也适用于任何其他可能不像你希望的那样被浏览器优先考虑的东西。
例如：默认情况下，Chrome 会以非常高的优先级加载字体，但如果某人的网络连接速度很慢，它会使用备用字体并降低该优先级。
考虑一个仅通过 CSS @font-face规则加载的字体：
@font-face {
font-family: "Inter Variable";
src: url("./font.woff2") format("woff2");
}
在加载时，由于网络连接慢，该字体获得了最低的下载优先级，尽管它对于页面的视觉体验非常重要。
虽然我这里没有特意玩它，但是，是的，fetchpriority 也适用于延迟的脚本。
何时使用
当你提前知道脚本的优先级，并且怀疑浏览器可能没有足够的信息来自行决定时，将 fetchpriority 放在你的脚本上。正如我所提到的，对于你希望以非阻塞、异步的方式加载的脚本，优先化它们特别有帮助。
有意使用
很容易对这样的工具过于热衷，导致过度使用。所以，要小心 – 这样做可能会付出代价。正如俗话所说：“强调一切=强调无。”事实上，过度使用可能实际上使得浏览器更难管理网络争用，损害页面的性能。
MDN 甚至特意在他们的优先级提示文档中指出：
仅在浏览器可能无法自动推断加载资源的最佳方式的特殊情况下使用它。过度使用可能会导致性能下降。
所以，不要因为这些工具存在就觉得有义务使用它们。小心使用。
回顾：何时提示
这里有很多内容，所以让我们快速回顾一下你可能选择使用优先级提示的时机。这些都不是详尽无遗的。只是一些好的开始。
- 当你希望浏览器知道多个晚些时候发现的资源，其中一些比其他资源更对页面至关重要时，提示预加载的资源。
- 提示你知道是用户体验的关键部分的
fetch()请求，或者可以安全地被降级以为更重要的请求让路。 - 提示你希望尽快加载和显示的首屏图像。
- 提示对页面功能至关重要的脚本，但你不希望阻止页面的其他部分（包括其他资源）被解析和下载。
让浏览器猜得少些
浏览器非常擅长弄清楚如何以及何时下载使我们的页面运行的东西。但它并不总是那么好。它不知道一个页面存在的原因，也不知道它的各个部分背后的意图。所以偶尔，它可以使用一些额外的帮助。
这就是为什么这些优先级提示存在的原因：为了使指令清晰，并且让浏览器很少有机会做出错误的决策。下次当你研究自己应用程序的网络活动时，记住它们，当有意义时，使用它们来帮助使你的页面性能更加智能。