改善 Speculation Rules API

Barry Pollard

Chrome 團隊一直致力於為 Speculation Rules API 進行一些有趣的更新，這些更新藉由預先擷取或預先算繪的瀏覽體驗來提升導覽效能。這些額外改善功能現已在 Chrome 122 中推出 (包括舊版的部分功能)。

這些變更讓預先擷取和預先轉譯網頁可以大幅簡化部署，減少浪費，我們希望未來能進一步採用。

其他功能

首先說明 Speculation Rules API 的新功能及其使用方式。之後，我們會顯示示範，讓您示範實際運作情況。

文件規則

先前推測規則 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>

注意： 舊版的文件規則 (可在來源試用期間使用) 需要額外的語法來比對網址參數和片段 ({"href_matches": "/*\\?*#*"})，而這項做法已在發布版本中簡化。

href_matches

CSS 選取器也可以做為替代選項使用，或搭配 href 比對使用，即可找出當前頁面中的連結：

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

如此一來，即可在整個網站上使用單一推測規則集，而不是在每個頁面建立專屬規則，讓網站更容易部署推測規則。

當然，預先算繪網頁上的「所有」連結絕對是多餘的，因此利用這項新功能導入了 eagerness 設定。

渴望

無論是何種推測結果，精確度與喚回度和前置時間之間各有取捨。在網頁載入時預先轉譯所有連結，基本上就能預先算繪使用者點選的連結 (假設他們點擊了網頁上的相同網站連結)，盡可能縮短前置時間，但可能會浪費大量頻寬。

另一方面，在使用者點選連結後進行預先算繪可避免浪費，但代價會大幅縮短。這意味著瀏覽器在瀏覽器切換至該網頁前，不太可能完成預先算繪。

eagerness 設定可讓您定義推測的執行時間，並分隔「when」(何時) 來推測要執行推測的網址。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 設定會因您的網站而異。如果是非常簡單的靜態網站，更頻繁地推算成本和對使用者有益。如果網站架構更複雜、網頁酬載較多，則比較減少投射頻率，以減少資源浪費，直到向使用者傳達更正面的消費意願信號，進而減少資源浪費。

注意： 過度推測會對使用者造成明確的頻寬、記憶體和 CPU 費用，但對網站本身也有費用。導入推測時，請務必留意可能對使用者帶來的影響。eagerness 設定可降低推測出的推測機率。Chrome 也會對推測內容設下限制，以降低過度使用的影響。

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 也會禁止在特定情況下使用推測功能，包括：

• 儲存資料。
• 節能模式。
• 記憶體限制。
• 如果「預先載入網頁」設定已關閉 (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 (分析) 會使用 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 興趣設定的文件規則：

推測規則示範

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

將滑鼠遊標懸停在水果上，就會看到預先算繪的頁面。與未預先算繪的方案相比，點選圖表後，LCP 顯示時間會更快。你也可以觀看以下影片，進一步瞭解本示範內容：

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

支援推測規則的平台

雖然推測規則是將規則插入 <script type="speculationrules"> 元素中的相對簡單，但平台支援卻可能成為一鍵式考量。我們持續與許多平台和合作夥伴合作，讓推出推測規則更簡單。

我們也正努力透過 Web Incubator Community Group (WICG) 將 API 標準化，讓其他瀏覽器也能視需要使用這個新奇的 API。

WordPress

WordPress 核心效能團隊 (包括 Google 開發人員) 建立了推測規則外掛程式。透過這個外掛程式，只要按一下滑鼠，就能將支援的文件規則新增至任何 WordPress 網站。您也可以透過 WordPress Performance Lab 外掛程式安裝這個外掛程式。此外，建議您安裝這個外掛程式，隨時查看團隊提供的最新效能外掛程式。

有兩種設定可供選擇：「推測模式」和「Eagerness」設定：

WordPress 推測規則外掛程式

如果是較複雜的設定 (例如禁止特定網址預先擷取或預先轉譯)，請參閱說明文件。

Akamai

Akamai 是全球首屈一指的 CDN 供應商，他們目前已經積極對「推測規則」API 進行實驗已有一段時間。Akamai 發布了說明文件，說明客戶如何在 CDN 設定中啟用這個 API。他們先前也分享了這個新 API 帶來令人驚豔的結果，

NitroPack

NitroPack 是一種效能最佳化解決方案，運用自訂的 Navigation AI 來預測要加入推測規則的網頁，比起將滑鼠遊標懸停在連結上，需要更長的前置時間，不必浪費時間全盤評估觀察到的所有連結。詳情請參閱 Nitropack Speculation Rules API 說明文件。這項創新的解決方案顯示，將舊名單規則搭配特定網站的分析數據時，仍有充足可用。

Chrome 團隊也與 NitroPack 合作，在 Speculation Rules API 的網路研討會中探討更多資訊，包括充分討論如何提前及頻繁推測，以及延遲或更少的考量因素。

天文

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

結論

這些推測規則 API 的新增項目讓網站更容易使用這項令人期待的全新效能功能，並降低未使用推測而浪費資源的風險。很高興能看到已有採用這個 API 的平台。我們希望在 2024 年能更廣泛採用這個 API，進而為使用者提供更好的效能。

除了成效提高 Speculation Rules API 的成果外，我們也很開心能藉此機會檢視畫面轉換是新的 API，可讓開發人員更輕鬆地指定導覽之間的轉換。這項功能目前適用於單頁應用程式 (SPA)，但多頁版本正在建構中 (Chrome 會在旗標中提供)。預先算繪是確保功能不會發生延遲的自然附加元件，以其他方式避免使用者遇到轉換情形，是為了提供更好的轉場效果。目前已有存在使用這種組合進行實驗的網站。

我們期盼在 2024 年能進一步採用 Speculation Rules API，如有進一步改善 API，我們會立即通知您。

特別銘謝

Robbie Down 於 Unsplash 提供的縮圖