Link rel=preload：優先考慮資源以獲得更好的站點速度

2016 年，w3c 與 Yoav Weiss 一起為 Chrome 發布了一個名為link rel="preload"的新網絡標準，為更快的加載時間開闢了新途徑。

六年後，預加載成為頂級網站為提高加載速度和用戶體驗而採用的排名第一的資源優先級排序技術。

條形圖顯示了按 CrUX 等級劃分的 rel="preload" 的採用情況。 資料來源：網絡年鑑 2021

link rel=preload 的日益流行證明了它的有效性。 這也使得它容易被濫用。

由於其靈活性，預加載重要資源需要更深入的知識，才能利大於弊。

在本文中，您將了解到：

• 資源優先級如何運作
• link rel preload 是什麼
• 您可以預加載哪些網頁元素
• 什麼時候應該（不應該）使用 link rel=preload
• 哪些 Core Web Vitals 指標預加載得到改善
• 鏈接 rel=preload 在真實網站中的好處

讓我們直接開始吧！

查看您的網站使用 NitroPack 可以提高多少速度

資源優先級解釋

手動資源優先級排序是您將現代瀏覽器從頁面加載過程中進行猜測的方式。

然而，在您開始影響加載資源的方式和時間之前，我們應該介紹一些基礎知識。

默認情況下，瀏覽器會嘗試找出要請求的資產以及請求的順序。 當瀏覽器下載資源時，它總是被分配一個優先級：最高、高、中、低或最低。

優先級取決於資源類型（例如文本、圖像、樣式表、腳本、視頻）和資源引用在文檔中的位置。

在選擇要預加載的資產時，您必須注意渲染阻塞資源，而不是阻止瀏覽器先下載它們。 否則，您最終可能會顯示一個空白頁面，而不是更快地加載它。

優化自動駕駛儀上的關鍵資源！ 使用 NitroPack 查看您的站點。

什麼是鏈接 rel=preload？

簡而言之， link rel=preload是一個命令，用於告訴瀏覽器您希望它們比正常情況下更快地獲取重要資源。

與預取和預連接等其他資源優先級排序技術不同，預加載不僅僅是一種提示，而是一種聲明。 這意味著瀏覽器被迫獲取您知道對頁面體驗至關重要的資源。

您可以通過將帶有 rel="preload" 的鏈接標記添加到 HTML 文檔的頭部來預加載資源：

< link rel ="preload" as ="script" href ="critical.js">

別擔心，我們稍後會詳細介紹。

哪些瀏覽器支持鏈接 rel=preload？

所有主流瀏覽器都支持預加載，使網站所有者和開發人員能夠提供更快的加載時間和無限制的用戶體驗。

有關支持的瀏覽器版本的詳細分類，請參閱“我可以使用嗎”下的此表。

link rel=preload 是必要的嗎？

預加載關鍵資源可讓您進行精細控制以定義自定義加載邏輯。 您的站點是否需要它取決於您的審核結果。

對於高質量的關鍵請求評估，我們建議探索手動網頁速度測試和內部收集的現場實驗室數據。

超跳轉到：如何檢查要預加載的資源。

link rel=preload 渲染阻塞嗎？

當用於大量非必要文件時，預加載標籤會干擾頁面的正確呈現。 在這種情況下，瀏覽器沒有關注重要的渲染阻塞資源，而是忙於處理大量低優先級文件。

例如，Asana 主頁為低重要性的 JavaScript 文件提供了 26 個預加載標籤。 這會導致頁面呈現出現大量延遲，從而損害用戶體驗。

（Asana 主頁示例）請求瀑布圖中的綠線顯示頁面開始呈現的時間。 來源：DebugBear 的文章

鏈接 rel=”preload” 與 rel=”prefetch”

當預加載首次可用時，許多用戶對其與現有預取指令相比的優勢感到困惑。

Prefetch 專注於最有可能成為未來導航必不可少的資源（意味著在當前頁面之後）。 另一方面，預加載處理當前導航的資源。

我可以預加載哪些網頁元素？

如前所述，link rel preload 適用於通常被瀏覽器發現較晚的資源。

您可以預加載的資源包括：

• 聲音和音樂文件
• 視頻（MP4、MP3、WebM）
• 音頻 WebVTT 軌道
• JavaScript文件
• CSS 樣式表
• 網絡字體（TTF、EOT、WOFF、WOFF2）
• 圖像（AVIF、WebP、JPG 和 JPEG 或 PNG）
• XHR 和獲取 API 請求
• 網絡工作者
• 多媒體嵌入和對象

preload 指令具有強大的“as”值。 必須告訴瀏覽器在不延遲更重要的文件或落後於不重要的文件的情況下為您預加載的資源賦予什麼優先級。

以下是您可以指定的“as”值的便捷列表：

Yoav Weiss（谷歌 Chrome 開發者關係團隊成員）還指出：

“...preload 不會阻止窗口的onload事件，除非該資源也被阻止該事件的資源請求。”

讓我們回顧一下網站所有者和開發人員選擇預加載的最常見資源。

如何鏈接 rel=preload 圖像

您的網站上始終至少有一個頁面在視口中有一個大圖像，從一開始就歡迎網站訪問者。 此類圖像非常適合預加載。

請記住，通過將帶有 rel="preload" 的鏈接標記添加到 HTML 文檔的頭部來預加載資源。 像這樣：

結果是您的圖像加載速度更快，並改進了最具挑戰性的核心網絡生命指標之一 - LCP。

但是，要預加載響應式圖像，您需要使用imagesrcset和imagesizes屬性來幫助瀏覽器根據屏幕尺寸選擇合適的圖像進行下載。

優化您的所有圖像以實現快速加載時間和自動駕駛儀的響應能力。 使用 NitroPack 查看您的站點。

如何鏈接 rel=preload 網絡字體

在瀏覽器下載並解析 CSS 文件之前，不會獲取在 CSS 文件中使用 @font-face 規則定義的字體。 這就是為什麼網絡字體是排名靠前的網站選擇預加載的第二受歡迎的資產。

這是一個示例片段：

如何鏈接 rel=preload JavaScript 文件

為了提高交互時間等響應指標，我們建議您拆分龐大的 JavaScript 包並僅預加載關鍵塊。

這樣，瀏覽器就可以將獲取與執行分開，並在下載整個 JS 包之前更早地發現該特定資源。

它會是這樣的：

< link rel ="preload" as ="script" href ="late_discovered.js">

我什麼時候應該使用鏈接相對預加載？

這是“視情況而定”的情況。

一般規則是僅預加載您知道對於訪問者登陸頁面時的首次交互必不可少的較晚發現的資產。

如何檢查要預加載哪些資源？

正如我們之前提到的，確定要預加載哪些資源的最佳方法是審核網頁的加載方式。

幸運的是，您可以使用 Chrome DevTools 中的請求瀑布圖來識別要預加載的資源。

第 1 步：訪問大多數訪問者登陸的網頁並“檢查”它

第 2 步：導航到“網絡”選項卡並刷新頁面以生成瀑布圖

第 3 步：右鍵單擊“名稱”部分以打開“優先級”列

第 4 步：探索資源的加載方式以及為它們分配的優先級，以查明可能的預加載資產

此外，您的 Lighthouse 報告有一個“機會”部分，將您的關鍵請求鏈中遲到發現的資產標記為預加載候選資產：

我怎麼知道預加載是否正常工作？

在確定預加載候選對像後，您可以開始測試鏈接 rel=preload 是否正常工作。

在 DevTools 中使用相同的請求瀑布圖來執行此操作。 如果您正確選擇了要預加載的資產並如前所示放入有效屬性，您應該會看到頁面加載時間有所改善。

這是之前和之後的示例：

（預加載前）：僅在樣式表“main.css”之後下載字體文件“Pacifico-Bold.woff2”。 （預加載字體文件後）：字體的下載與樣式表同時進行。

如何不濫用鏈接 rel=preload

鑑於一些適當的預加載標籤可以顯示令人印象深刻的結果，很容易被帶走。

但是由於預加載的性質，可能會出現一系列性能問題。

• 對瀏覽器正常行為的不必要干擾
• 過度使用資源（即比平時更快地用完帶寬）
• 對關鍵渲染路徑的有害影響阻止瀏覽器做正確的事情

錯誤 #1：預加載太多資源

沒有您應該瞄準的確切數字，但在選擇要預加載的資源時要非常小心。 請記住，您應該定位對首次與網頁交互至關重要的較晚發現的資產。

錯誤 #2：預加載未使用的內容

通常情況下，我們會在公共標頭中找到一個鏈接 rel=preload，即使預加載資源僅位於一個網頁（例如登錄頁面）上。

預加載未使用內容的警告消息

這可能只是一個簡單的錯誤或編碼不足。 在這種情況下，將通用包拆分為特定模板的較小目標包是一種更好的方法。

錯誤 #3：預加載非必要資源

僅預加載任何資源不會讓您獲得所需的速度提升。 對首屏體驗的呈現和交互性不重要的資產最好保留較低的優先級。

相反，旨在找到瀏覽器發現的元素比您希望的晚。

錯誤 #4：預加載不存在的內容

這種情況很少發生，但一旦發生，結果就是 404 頁面。 這在預加載時是不行的，您應該始終仔細檢查資源是否確實有效。

rel=preload 改善了哪些 Core Web Vital 指標？

到目前為止，我們已經看到了預加載速度優化能力的不可否認的證據。 它可以縮短加載時間，改進性能指標和響應能力，並幫助您留下良好的第一印象。

以下是正確預加載後改進最大的指標：

• Largest Contentful Paint (LCP) ：大型首屏資源（如英雄圖片和大塊文本）是很好的 LCP 候選者。 更快地交付它們可以幫助您改善核心網絡生命指標網站最難解決的問題。
• Cumulative Layout Shift (CLS) ：預加載網絡字體顯示字體相關佈局偏移的顯著改進，例如 Flash of Unstyled Text (FOUT) 和 Flash of Invisible Text (FOIT)。
• First Input Delay (FID)和Interaction to Next Paint (INP) ：預加載支持重要交互的 JavaScript 可幫助您根據用戶的意圖達到更好的響應水平。

鏈接 rel=preload 流行網站的好處

2017 年，Chrome Data Saver（現已停用）團隊在腳本和 CSS 樣式表上應用了預加載，發現受影響頁面的 First Contentful Paint 改進平均縮短了 12%。

使用 link rel=preload 改進加載指標的其他成功案例包括：

1. 預加載網絡字體時，Shopify 將 Chrome 桌面上的下一次繪製時間縮短了 50%（1.2 秒），這完全消除了不可見文本的 Flash；
2. Flipkart 通過預加載他們的密鑰包來減少大量的主線程空閒；
3. 通過預加載 9 個基本 API 調用將頁面呈現指標提高 10% 的概念；
4. 《金融時報》通過使用鏈接預加載標題，將顯示刊頭圖像所需的時間縮短了 1 秒。

使用預加載（左）和不使用預加載（右）的 Shopify。 資料來源：Addy Osmani 的文章

加入前31%的高速網站！ 親眼目睹 NitroPack 的影響。

概括

Link rel=preload 是一種有效的資源優先級排序技術，可加快您的網站速度並在首次接觸時提供更好的用戶體驗。

謹慎使用此指令，並且僅用於對首屏體驗至關重要的較晚發現的資源。 確保首先在 Chrome DevTools 和 Lighthouse 的幫助下分析瀏覽器如何下載和解析您的資產。

正確實施 rel=”preload” 將提高站點響應能力和性能指標，這對您的在線業務的成功至關重要。