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>
您也可以使用 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) |
moderate 和 conservative 設定會依據使用者互動方式，以先進先出 (FIFO) 的方式運作。達到上限後，新的推測會導致最舊的推測遭到取消，並由較新的推測取代，以節省記憶體。
moderate 和 conservative 的推測是由使用者觸發，因此我們可以使用較為溫和的 2 個門檻來節省記憶體。immediate 和 eager 設定不會因使用者操作而觸發，因此限制較高，因為瀏覽器無法得知需要哪些設定，以及何時需要這些設定。
系統會將已取消的推測內容從 FIFO 佇列中移除，但您可以再次觸發推測內容 (例如再次將滑鼠游標懸停在該連結上)，系統就會重新推測該網址。在這種情況下，先前的推測可能會導致瀏覽器在該網址的 HTTP 快取中快取一些資源，因此重複推測應可大幅減少網路和時間成本。
immediate 和 eager 限制也是動態的。使用這些積極程度移除推測規則指令碼元素，可透過取消這些已移除的推測，來創造容量。如果這些網址包含在新網址指令碼中，且尚未達到上限，系統也會重新推測這些網址。
Chrome 也會在特定情況下禁止使用推測，包括：
所有這些條件都是為了減少過度投機對使用者造成的負面影響。
選填 source
Chrome 122 將 source 鍵設為選用鍵，因為系統可從 url 或 where 鍵的存在情況推斷出 source 鍵。因此，這兩個推測規則是相同的：
<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 快取中儲存及重複使用資源。也就是說，即使您未使用預測值，仍可在日後獲得相關好處。
這也讓重新推測 (例如針對設有 moderate 急迫度設定的文件規則) 的成本大幅降低，因為 Chrome 會使用 HTTP 快取來快取可快取的資源。
我們也支援新的 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>
在本範例中，/products 初始網頁的 HTML 與產品 ID 123 和 124 相同。不過，最終的網頁內容會因用戶端端繪作業而有所不同，因為這項作業會使用 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 時間會比未預先算繪的食譜快上許多。您也可以在以下影片中觀看這個示範：
您也可以參閱先前的偵錯推測規則網誌文章，進一步瞭解如何使用 DevTools 偵錯推測規則。
平台支援推測規則
雖然您可以將推測規則插入 <script type="speculationrules"> 元素，讓推測規則實作相對簡單，但平台支援功能可讓您一鍵完成這項操作。我們一直與各種平台和合作夥伴合作，以便更輕鬆地推出投機規則。
我們也正努力透過 Web Incubator Community Group (WICG) 將 API 標準化，讓其他瀏覽器也能視需要導入這個令人興奮的 API。
WordPress
WordPress Core Performance 團隊 (包括 Google 的開發人員) 已建立「Speculation Rules」外掛程式。這個外掛程式可讓你輕鬆一鍵為任何 WordPress 網站新增文件規則支援功能。您也可以透過 WordPress Performance Lab 外掛程式安裝這個外掛程式，建議您也考慮安裝這個外掛程式，因為它會讓您隨時掌握團隊提供的相關成效外掛程式。
您可以使用兩組設定：推測模式和積極性設定：
如需設定更複雜的情況 (例如排除特定網址，以免預先擷取或預先轉譯)，請參閱說明文件。
Akamai
Akamai 是全球領先的 CDN 供應商之一，他們一直積極實驗 Speculation Rules API。Akamai 已發布說明文件，說明客戶如何在 CDN 設定中啟用此 API。他們也曾分享這項新 API 帶來的驚人成果。
Uxify
Uxify (先前是 Nitropack 的一部分) 是成效最佳化解決方案，可使用自訂導覽 AI 預測要加入到推測規則的網頁，目的是提供比游標懸停在連結上更長的前導時間，但不會浪費時間對觀察到的所有連結進行不必要的推測。詳情請參閱 Uxify Speculation Rules API 說明文件。這項創新解決方案證明，舊版清單規則搭配網站專屬洞察資料後，仍有許多優點。
Chrome 團隊也與該團隊合作，為想進一步瞭解相關資訊的使用者舉辦「投機規則 API」網路研討會，討論在早期和頻繁投機，以及晚期和較少投機之間的考量因素。
天文攝影
Astro 在 4.2 版中使用 Speculation Rules API 實驗性地加入了預先顯示網頁功能，讓使用 Astro 的開發人員輕鬆啟用這項功能，同時在瀏覽器不支援 Speculation Rules API 時，改用標準預先擷取功能。詳情請參閱用戶端預先顯示說明文件。
結論
透過 Speculation Rules API 的這些新增功能，您可以更輕鬆地為網站使用這項令人期待的新成效功能，且不必擔心會因未使用的推測而浪費資源。很高興看到平台已開始採用這個 API。我們希望在 2024 年，這個 API 能廣泛採用，進而為使用者帶來更出色的成效。
除了 Speculation Rules API 提供的成效提升外，我們也期待透過這項 API 開創新的商機。View Transitions 是新的 API，可讓開發人員更輕鬆地指定導覽之間的轉場效果。這項功能目前適用於單頁應用程式 (SPA)，但多頁版本正在開發中 (並且在 Chrome 中透過標記提供)。預先算繪是這項功能的自然附加功能，可確保沒有延遲情形，否則會導致轉場無法提供良好的使用者體驗。我們已經看到有網站嘗試使用這兩種元素。
我們期待在 2024 年進一步採用投機規則 API，並會持續更新 API 的任何改善項目。
特別銘謝
Unsplash 上的縮圖，由 Robbie Down 提供