改善 Speculation Rules API

Barry Pollard

Chrome 團隊持續針對 Speculation Rules API 進行了幾項令人期待的更新，可以透過預先擷取或甚至預先轉譯日後的瀏覽方式，改善導覽效能。現在，這些額外的改善項目已從 Chrome 122 推出 (某些舊版功能會提供部分功能)。

這些變動讓預先擷取和預先轉譯網頁更易於部署，還能減少浪費，我們希望鼓勵進一步採用。

其他功能

首先，我們會說明 Speculation Rules API 新增的新增功能與使用方式。接著，我們將示範示範，協助您瞭解這些功能的實際運作情形。

文件規則

先前，Speculation Rules API 運作時會指定要預先擷取或預先算繪的網址清單：

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

這種推測規則具有半動態的性質，可新增新的推測規則指令碼，移除舊指令碼以捨棄這些推測 (請注意，更新現有推測規則指令碼的 urls 清單並不會觸發推測規則變更)。不過，在網頁要求時從伺服器傳送網址，或透過用戶端 JavaScript 以動態方式建立此清單，它仍會保留選定的網站網址。

「清單規則」仍是較簡單的用途 (下一個導覽來源有少量明顯的用途)，或更進階的用途 (系統會根據網站擁有者想使用的任何經驗法則動態計算網址清單，然後插入網頁中)。

好消息！我們很高興能提供新選項，以便使用文件規則自動尋找連結。此功能的運作原理是根據 where 條件，從文件本身取得網址。您可以根據連結本身設定以下內容：

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/logout/*"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

您也可以使用 CSS 選取器做為替代項目，也可以搭配 href 比對功能使用，以找出目前頁面上的連結：

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

這樣一來，整個網站就能使用單一推測規則集，而不需要在每個網頁套用特定規則集，方便網站部署推測規則。

當然，在網頁上預先轉譯「所有」連結一定會浪費資源，因此我們導入了 eagerness 設定。

熱力

無論是哪種類型的推測，在「精確度與喚回度」和前置時間之間都可以取捨。在網頁載入時預先轉譯所有連結，就幾乎絕對能預先轉譯使用者所點選的連結 (假設客戶點擊網頁上的相同網站連結)，並盡可能增加前置時間，但可能會產生大量頻寬。

另一方面，只有在使用者點選連結後，才能避免浪費，但能大幅縮短前置時間。換句話說，在瀏覽器切換至該網頁之前，可能就不太可能完成預先算繪作業。

eagerness 設定可讓您定義推測的執行時機，並以「時機」區分要執行推測的網址。eagerness 設定同時適用於 list 和 document 來源規則，有四種設定，Chrome 提供以下經驗法則：

  • immediate：用於盡快推測結果，也就是在發現推測規則後立即推估。
  • eager：目前運作方式與 immediate 設定相同，但我們日後會考慮在 immediate 和 moderate 之間放置此程式碼。
  • moderate：如果將遊標懸停在連結上 200 毫秒 (如果是更短的 pointerdown 事件或行動裝置沒有 hover 事件)，系統就會執行推測。
  • conservative：這個值會在指標或輕觸手勢上做出推測。

list 規則的預設 eagerness 為 immediate。您可以使用 moderate 和 conservative 選項，將 list 規則限制為僅和使用者與特定清單互動的網址。在許多情況下，也許更適合搭配適當 where 條件的 document 規則。

document 規則的預設 eagerness 為 conservative。由於文件可能包含多個網址，因此使用 immediate 或 eager 套用 document 規則時，請務必謹慎使用 (另請參閱下一節「Chrome 限制」一節)。

要使用哪一個 eagerness 設定，取決於您的網站。如果是非常簡單的靜態網站，則越積極投機可能不容易，而且對使用者有益。如果網站的架構較複雜，網頁承載則較為複雜，在減少浪費之前，可能會傾向於減少推測頻率，直到能更重視使用者的意圖，以減少浪費。

moderate 選項是中間位置，許多網站都能夠受益於下列簡單的推測規則，以基本但效果顯著的實作規則，預先轉譯懸停或指標上的所有連結：

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Chrome 限制

即使選擇 eagerness，Chrome 仍會設有限制，避免這個 API 過度使用：

eagerness 預先擷取 預先算繪
immediate/eager 50 10
moderate/conservative 2 (FIFO) 2 (FIFO)
Chrome 的推測限制

moderate 和 conservative 設定 (取決於使用者互動) 設定，採用先進先出 (FIFO) 方式。達到上限後，系統會取消最舊的推測並替換為新的推測，以節省記憶體。

事實上，使用者會觸發 moderate 和 conservative 推測，讓我們使用比 2 更適中的門檻來節省記憶體。使用者動作不會觸發 immediate 和 eager 設定，因此限制較高，因為瀏覽器無法知道自己需要哪些必要項目。

如果將推測從 FIFO 佇列中推斷，就會再次觸發這個推測 (例如再次將遊標移到該連結上)，系統就會重新推測該網址。在這種情況下，先前的推測可能會使瀏覽器在網址的 HTTP 快取中快取部分資源，因此重複進行推測應可大幅降低網路和時間成本。

immediate 和 eager 的限制也屬於動態性質。使用這些測高強度等級移除推測規則指令碼元素後，系統會取消這些已移除的推測來建立容量。如果新網址指令碼中包含該網址，而且未達限制，還可以重新推測這些網址。

Chrome 也會防止在特定條件下使用推測，包括：

  • Save-Data (儲存資料)。
  • 節能模式。
  • 記憶體限制
  • 「預先載入網頁」這項設定會關閉 (Chrome 擴充功能 (例如 uBlock Origin) 也會明確關閉這項設定)。
  • 在背景分頁中開啟網頁。

上述所有條件旨在降低過度推測，進而對使用者造成負面影響。

選用 source

Chrome 122 可能會選擇是否使用 source 鍵，因為這可從 url 或 where 鍵中推論得出。因此，這兩個推測規則完全相同：

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

Speculation-Rules HTTP 標頭

您也可以使用 Speculation-Rules HTTP 標頭傳送推測規則，不必將規則直接加入文件的 HTML 中。這可讓 CDN 更輕鬆地進行部署，無需自行變更文件內容。

Speculation-Rules HTTP 標頭會隨文件一起傳回，並指向包含推測規則的 JSON 檔案位置：

Speculation-Rules: "/speculationrules.json"

這項資源必須使用正確的 MIME 類型，如果是跨源資源，請通過 CORS 檢查。

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

如要使用相對網址，建議您在推測規則中加入 "relative_to": "document" 鍵。否則，相對網址會是推測規則 JSON 檔案網址的相對網址。當您需要選取部分或所有相同來源的連結時，這個功能就特別實用。

改善快取重複使用率

我們改善了 Chrome 的快取功能，讓預先擷取 (或甚至預先算繪) 文件可在 HTTP 快取中儲存並重複使用資源。這表示即使不採用推測，進行推測仍可繼續帶來未來效益。

此外，由於 Chrome 會使用 HTTP 快取來快取資源，因此重新推測作業的費用會大幅減少 (例如針對具有 moderate 效率設定的文件規則)。

我們也支援新的 No-Vary-Search 提案，以進一步改善快取重複使用的情形。

「No-Vary-Search」支援頁面

預先擷取或預先轉譯網頁時，某些網址參數 (技術稱為「搜尋參數」) 對伺服器實際放送的網頁來說可能不重要，且僅用於用戶端 JavaScript。

舉例來說，Google Analytics 會使用 Urchin 流量監視器 (UTM) 參數來評估廣告活動，但通常不會使伺服器傳送不同的網頁。這表示 page1.html?utm_content=123 和 page1.html?utm_content=456 會從伺服器傳送同一個網頁，因此可以由快取重複使用同一個網頁。

同樣地，應用程式也可以使用其他網址參數。

No-Vary-Search 提案可讓伺服器指定參數，避免系統傳送的資源有所不同，進而讓瀏覽器重複使用先前快取的文件版本，文件版本只會因這些參數而不同。注意：目前只有 Chrome (和以 Chromium 為基礎的瀏覽器) 支援預先擷取導覽推測功能。

推測規則支援使用 expects_no_vary_search，指出 No-Vary-Search HTTP 標頭的預期傳回位置。如此可以避免不必要的下載作業。

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

在這個示例中，產品 ID 123 和 124 的 /products 初始網頁 HTML 都相同。不過，網頁內容最終會因使用 JavaScript 的用戶端轉譯而使用 id 搜尋參數來擷取產品資料，最終也會有所不同。因此我們主動擷取該網址，且應傳回 No-Vary-Search HTTP 標頭，顯示網頁可用於任何 id 搜尋參數。

不過，如果使用者在預先擷取完成前點選任何連結，瀏覽器可能無法收到 /products 網頁。在此情況下，瀏覽器無法知道當中是否包含 No-Vary-Search HTTP 標頭。然後瀏覽器就能選擇是否要再次擷取連結，或是等待預先擷取作業完成，確認其中是否包含 No-Vary-Search HTTP 標頭。expects_no_vary_search 設定可讓瀏覽器知道網頁回應應包含 No-Vary-Search HTTP 標頭，並等待預先擷取作業完成。

示範

我們已在 https://speculative-rules.glitch.me/common-fruits.html 上建立示範，可用來查看含有 moderate 主動式設定的文件規則：

在故障過程中建立的示範網站螢幕截圖，當中列出許多以水果標示的連結。開發人員工具已開啟，並顯示兩個連結 (apple.html 和 Orange.html) 已成功預先算繪的連結。
推測規則示範

開啟開發人員工具，按一下「Application」面板。然後在「背景服務」專區中，依序點選「推測載入」和「推測」窗格，然後依「狀態」欄排序。

只要將滑鼠遊標懸停在水果，畫面上就會顯示預先算繪的頁面。此外，點選這些食譜後，相較於未預先算繪的食譜，點選這些食譜可更快完成 LCP 檢查時間。您也可以觀看以下影片中的相關示範：

如要進一步瞭解如何使用開發人員工具對推測規則進行偵錯，也可以參閱先前的「偵錯推測規則」網誌文章。

平台支援推測規則

儘管將規則插入 <script type="speculationrules"> 元素中，實作模擬規則相對簡單，但平台支援讓此工具只要按一下即可處理。我們持續與多個平台和合作夥伴合作，簡化推測規則的實施方式。

我們也正努力透過 Web Incubator 社群群組 (WICG) 將 API 標準化，讓其他瀏覽器也能在選用時導入這個令人期待的 API。

WordPress

WordPress Core 成效團隊 (包括 Google 開發的開發人員) 建立了推測規則外掛程式。這個外掛程式讓您只要輕輕一按，就能支援任何 WordPress 網站的文件規則。您也可以透過 WordPress Performance Lab 外掛程式安裝這個外掛程式，因此建議您一併安裝這個外掛程式，以便隨時掌握團隊提供的相關效能外掛程式。

提供兩種設定：「推測模式」和「Eagerness」設定：

內含推測規則設定的 WordPress 設定閱讀面板螢幕截圖。其中提供兩種選項：「推測模式」以及「預先擷取」或「預先轉譯」選項。此外，該模式也提供「保守」、「中度」或「熱度」設定。
WordPress 推測規則外掛程式

如需較複雜的設定 (例如禁止特定網址進行預先擷取或預先算繪)，請參閱說明文件。

Akamai

Akamai 是全球頂尖的 CDN 供應商之一，他們一直積極試用推測規則 API，已有一段時間。Akamai 已發布說明文件，說明客戶如何在 CDN 設定中啟用這個 API。此外，他們也曾分享使用這個新 API 可能獲得的成果。

NitroPack

NitroPack 是效能最佳化解決方案，使用其自訂 Navigation AI 預測應加入哪些網頁加入推測規則，比起將遊標懸停在連結上，能延長前置時間，但不會浪費系統觀察到的所有連結。詳情請參閱 Nitropack Speculation Rules API 說明文件。這項創新解決方案顯示，搭配網站專屬分析資料時，仍有許多舊名單規則可供參考。

Chrome 團隊也與 NitroPack 合作舉辦 Speculation Rules API 網路研討會，希望瞭解更多資訊，包括提早和頻繁進行推測以及延遲和較不常出現的考量重點。

天文攝影

Astro 針對使用 Speculation Rules API 4.2 版新增的預先算繪頁面是以實驗性方式新增，可讓使用 Astro 的開發人員輕鬆啟用這項功能，同時針對不支援 Speculation Rules API 的瀏覽器，改回使用標準預先擷取內容。詳情請參閱用戶端預先算繪說明文件。

結論

這些新增至 Speculation Rules API 新增了 Speculation Rules API，可讓網站更容易使用這項令人期待的全新效能功能，並降低浪費資源、未派上用場的推測的風險。很高興看到平台已經採用這個 API。我們期望在 2024 年能更廣泛採用這個 API，進而為使用者帶來更出色的成效。

除了成效提升外，推測規則 API 還能為我們帶來許多新商機。View Transitions 是全新的 API，可讓開發人員更輕鬆地指定導覽之間的轉場效果。這項功能目前適用於單頁應用程式 (SPA)，但多頁版本正在處理中 (必須搭配 Chrome 的旗標使用)。預先算繪是該功能的自然附加元件，不會發生延遲，以免干擾使用者體驗，進而無法改進轉場效果。我們已經發現一些網站嘗試使用此組合。

我們預計在 2024 年逐步採用 Speculation Rules API，如有進一步改善，我們會隨時通知您。

特別銘謝

縮圖來源：Robbie Down 的 Unsplash 網站上