如何通過使用優先級提示，來控制所有網頁資源加載順序
當你打開瀏覽器的網絡標簽時，你會看到大量的活動。資源正在下載，信息正在提交，事件正在記錄，等等。
由于有太多的活動，有效地管理這些流量的優先級變得至關重要。帶寬爭用是真實存在的，當所有請求同時觸發時，有些HTTP請求的優先級并不像其他請求那樣高。例如，如果你必須選擇，你可能更希望某人的付款請求成功完成，而不是僅僅表示他們嘗試過的分析請求。而讓你的主要圖片盡快顯示無疑比在頁面底部渲染你的標志更為重要。
幸運的是，瀏覽器擁有越來越多的工具來幫助優先處理所有這些網絡活動。這些“優先級提示”幫助瀏覽器在資源有限時，對哪些請求應該優先處理做出更少的假設和更明確的決策。
這是一套有用的工具，當它們得到很好的利用時，它們可以對頁面性能產生實質性的影響，包括那些越來越重要的核心網絡指標。讓我們探索其中的一些，以及它們最有幫助的一些場景。
這是一套有用的工具，當它們得到很好的利用時，它們可以對頁面性能產生實質性的影響，包括那些越來越重要的核心網絡指標。讓我們探索其中的一些，以及它們最有幫助的一些場景。
優先加載的資源
現代瀏覽器有一個受到良好支持的方法，可以告訴瀏覽器當前頁面最終需要哪些資源：<link rel="preload" ... />。當它放在文檔的<head>中時，瀏覽器會被指示盡快以“高”優先級下載它。
公平地說，瀏覽器中的預加載掃描器已經非常擅長這方面的工作。因此，預加載通常最適用于晚些時候發現的資源 - 任何不直接由你的HTML加載的東西，比如通過內聯樣式屬性加載的背景圖像。但它也適用于任何其他可能不像你希望的那樣被瀏覽器優先考慮的東西。
例如：默認情況下，Chrome 會以非常高的優先級加載字體，但如果某人的網絡連接速度很慢，它會使用備用字體并降低該優先級。
考慮一個僅通過CSS @font-face規則加載的字體：
@font-face {
font-family: "Inter Variable";
src: url("./font.woff2") format("woff2");
}在加載時，由于網絡連接慢，該字體獲得了最低的下載優先級，盡管它對于頁面的視覺體驗非常重要。
但我們可以通過預加載該資源來覆蓋瀏覽器的決定：
<head>
<!-- Other stuff... -->
<link rel="preload" href="/font.woff2" as="font">
</head>現在它更受歡迎了：
你可以直接在鏈接標簽上使用 fetchpriority 來明確指示相對優先級，這在同時預加載多個資源時非常有用。
這是一個假設的場景，你想預加載兩種字體，但想讓其中一種優先于另一種：
<link rel="preload" href="./font-1.woff2" as="font" fetchpriority="low" />
<link rel="preload" href="./font-2.woff2" as="font" fetchpriority="high" />網絡活動的結果會反映這些指示。
何時使用
通常，當資源不直接由HTML加載，但對頁面的體驗至關重要時（例如字體、CSS背景圖像等），使用預加載。當預加載多種同類型的資源，且你明確知道哪個最重要時，加入fetchpriority屬性。
優先化 fetch() 請求
我認為，Fetch API 是現代網絡的最佳工具之一。與 XMLHttpRequest 相比，它有一些很好的功能，比如在外發請求時發出優先信號的能力。
最容易想到的用例是：分析請求。當帶寬有限并且有多個請求在執行時，瀏覽器會自行決定優先級。但我們作為工程師應該知道，通常的分析請求應該優先于頁面目的更為關鍵的其他請求。現代的fetch()使這變得簡單。
下面是兩個請求幾乎同時入隊的簡單設置：
fetch("http://localhost:8000/pay", {
method: "POST",
body: paymentBody,
});
fetch("http://localhost:8000/log", {
method: "POST",
body: loggingBody,
});默認情況下，瀏覽器會自動將它們都視為 "高 "優先級：
現在，我們要明確地告訴瀏覽器每個請求的優先級：
fetch("http://localhost:8000/pay", {
method: "POST",
body: paymentBody,
+ priority: "high"
});
fetch("http://localhost:8000/log", {
method: "POST",
body: loggingBody,
+ priority: "low"
});這次，優先級是不同的：
可能的擔憂是"low"優先級的請求可能會丟失 - 如果用戶過早離開頁面，請求可能會被取消。這是一個真正的問題。根據幾個因素，關閉標簽頁或轉到下一個頁面可能導致一個重要但相對低優先級的請求被中止。
幸運的是，fetch() 還接受一個 keepalive 選項。當設置為true時，即使頁面終止，瀏覽器也會完成該請求。
何時使用
當你知道多個請求正在并發執行，并且你明確知道哪個最重要（或哪個可以安全地被降級）時，指示fetch()的優先級。
優先化<img />請求
如果我們不做任何特殊處理，瀏覽器會盡量確定頁面上最重要的圖像。為了說明這一點，我加載了以下圖像，它們之間的距離很大，所以只有一個會在"頁面首部"顯示。
<img src="./cat-1.jpeg" />
<div style="height: 5000px"></div>
<img src="./cat-2.jpeg" />
<div style="height: 5000px"></div>
<img src="./cat-3.jpeg" />瀏覽器發現了哪個最重要，但這花了一秒鐘。當開始下載時，這三者都是“低”優先級。但很快，頁面首部的那個切換到了“高”優先級。
當我為第一張圖片添加fetchpriority屬性時，情況變得更加可預測：
<img src="./cat-1.jpeg" fetchpriority="high" />此后，cat-1.jpeg 從一開始就以最高的優先級加載。雖然最初令人費解，但這是有道理的。瀏覽器非常擅長確定資源的關鍵性，但它從明確的指示中受益。如果你知道一張圖片很重要，就明確說明。
順便說一句，這個特性與本地圖像延遲加載非常搭，這是現在非常受支持的特性。
<img src="./cat-1.jpeg" fetchpriority="high"/>
<div style="height: 5000px"></div>
<img src="./cat-2.jpeg" loading="lazy" />
<div style="height: 5000px"></div>
<img src="./cat-3.jpeg" loading="lazy" />有了這個，瀏覽器就知道如何加載圖像，只在合適的時候加載。在我的情況下，它甚至不會開始請求初始加載時屏幕外的圖像。相反，它會等到它們更接近視口。
何時使用
當你知道它們對頁面體驗非常重要時，對圖像使用明確的fetchpriority。主圖像是一個很好的開始，它甚至可以影響頁面的核心網絡指標 - 特別是LCP（最大內容繪制）。
優先化 <script /> 標簽
頁面上帶有src屬性的任何普通<script />在獲取時都會得到高優先級，但這有一個權衡：在它加載并執行之前，它會阻止解析頁面的其余部分。出于這個原因，async屬性很有用。它會以低優先級在后臺請求腳本，并在準備好后立即執行。知道這一點，以下設置行為是可預測的：
<script src="/script-async.js" async notallow="console.log('async')"></script>
<script src="/script-sync.js" notallow="console.log('sync')"></script>
<script>console.log("inline");</script>異步腳本在優先級中被降低：
控制臺確認，在 async 腳本加載過程中，允許解析和執行后續腳本。
非阻塞，但高優先級的腳本
大多數時候，這種行為都很好。但有時，你可能希望腳本既以“高”優先級加載，又異步加載。
一個可能的場景是在落地頁的英雄部分安裝一個小的 SPA。為了保留頁面的核心網絡指標，特別是LCP和FID（首次輸入延遲，很快將被下一個繪制的交互所取代），你需要高度優先這個腳本（畢竟，它負責構建和供電你的應用）。但同時，你不希望它阻止頁面的其余部分進行解析。
所以，我們給它一個fetchpriority：
<script src="/script-async.js" async notallow="console.log('async')" fetchpriority="high"></script>
<script src="/script-sync.js" notallow="console.log('sync')"></script>
<script>console.log("inline");</script>現在，它以提高的優先級下載，同時仍然不阻止頁面的其他部分：
控制臺驗證了這一點。有了更高的優先級，異步腳本加載得更快。在這種情況下，甚至比同步和內聯的還要快。
雖然我這里沒有特意玩它，但是，是的，fetchpriority 也適用于延遲的腳本。
何時使用
當你提前知道腳本的優先級，并且懷疑瀏覽器可能沒有足夠的信息來自行決定時，將 fetchpriority 放在你的腳本上。正如我所提到的，對于你希望以非阻塞、異步的方式加載的腳本，優先化它們特別有幫助。
有意使用
很容易對這樣的工具過于熱衷，導致過度使用。所以，要小心 - 這樣做可能會付出代價。正如俗話所說：“強調一切=強調無。”事實上，過度使用可能實際上使得瀏覽器更難管理網絡爭用，損害頁面的性能。
MDN 甚至特意在他們的優先級提示文檔中指出：
僅在瀏覽器可能無法自動推斷加載資源的最佳方式的特殊情況下使用它。過度使用可能會導致性能下降。
所以，不要因為這些工具存在就覺得有義務使用它們。小心使用。
回顧：何時提示
這里有很多內容，所以讓我們快速回顧一下你可能選擇使用優先級提示的時機。這些都不是詳盡無遺的。只是一些好的開始。
- 當你希望瀏覽器知道多個晚些時候發現的資源，其中一些比其他資源更對頁面至關重要時，提示預加載的資源。
- 提示你知道是用戶體驗的關鍵部分的 fetch() 請求，或者可以安全地被降級以為更重要的請求讓路。
- 提示你希望盡快加載和顯示的首屏圖像。
- 提示對頁面功能至關重要的腳本，但你不希望阻止頁面的其他部分（包括其他資源）被解析和下載。
讓瀏覽器猜得少些
瀏覽器非常擅長弄清楚如何以及何時下載使我們的頁面運行的東西。但它并不總是那么好。它不知道一個頁面存在的原因，也不知道它的各個部分背后的意圖。所以偶爾，它可以使用一些額外的幫助。
這就是為什么這些優先級提示存在的原因：為了使指令清晰，并且讓瀏覽器很少有機會做出錯誤的決策。下次當你研究自己應用程序的網絡活動時，記住它們，當有意義時，使用它們來幫助使你的頁面性能更加智能。
