在 Chrome 中預先算繪頁面，讓使用者能夠快速瀏覽網頁

Barry Pollard

發布日期：2022 年 12 月 2 日，上次更新日期：2026 年 10 月 29 日

Browser Support

• 109
• 109
• 
• 

Source

Chrome 團隊已重新推出完整預先算繪功能，可預先算繪使用者可能前往的未來網頁。

比起閱讀，更喜歡看影片嗎？請觀看這部 Google I/O 影片，瞭解本頁內容摘要。

預先算繪簡史

過去 Chrome 支援 <link rel="prerender" href="/next-page"> 資源提示，但 Chrome 以外的瀏覽器並未廣泛支援，且 API 的表達能力不佳。

這種使用連結 rel=prerender 提示的舊版預先算繪功能已淘汰，改用 NoState Prefetch，後者會擷取未來頁面所需的資源，但不會完整預先算繪頁面，也不會執行 JavaScript。NoState Prefetch 確實能改善資源載入，進而提升網頁效能，但無法像完整預先算繪一樣立即載入網頁。

Chrome 團隊現已在 Chrome 中重新導入完整預先算繪功能。為避免與現有用途發生衝突，並允許日後擴充預先算繪功能，這項新的預先算繪機制不會使用 <link rel="prerender"...> 語法，該語法仍適用於 NoState 預先擷取，並預計在未來某個時間點淘汰。

如何預先算繪網頁？

網頁可以透過下列四種方式之一預先算繪，所有方式都是為了加快瀏覽速度：

1. 在 Chrome 網址列 (又稱「多功能框」) 輸入網址時，Chrome 可能會根據你的瀏覽記錄，判斷你是否很有可能造訪該網頁，並自動預先算繪網頁。
2. 使用書籤列時，如果將滑鼠游標懸停在其中一個書籤按鈕上，Chrome 可能會自動預先算繪網頁。
3. 在 Chrome 網址列輸入搜尋字詞時，Chrome 可能會根據搜尋引擎的指示，自動預先算繪搜尋結果網頁。
4. 網站可以使用 Speculation Rules API，以程式輔助方式指示 Chrome 預先算繪哪些網頁。這項功能取代了 <link rel="prerender"...> 過去的作用，可讓網站根據網頁上的推測規則，主動預先算繪網頁。這些標記可以靜態存在於網頁上，也可以由 JavaScript 根據網頁擁有者的需求動態插入。

在上述各情況下，預先算繪的行為就像是在隱藏的背景分頁中開啟網頁，然後將前景分頁替換為預先算繪的網頁，藉此「啟用」網頁。如果網頁在完全預先算繪前就啟用，則目前狀態為「前景」，並會繼續載入，這表示您仍可搶先一步。

由於預先算繪的網頁是以隱藏狀態開啟，因此許多會造成干擾行為的 API (例如提示) 在此狀態下不會啟用，而是會延遲到網頁啟用後才啟用。在少數情況下，如果無法這麼做，系統會取消預先算繪。Chrome 團隊正致力於將預先算繪取消原因公開為 API，並強化開發人員工具功能，以便更輕鬆地找出這類極端案例。

附註：預先算繪的網頁應視為提示和漸進增強。與 preload 不同，預先算繪是推測性提示，瀏覽器可能會根據使用者設定、目前記憶體用量或其他經驗法則，選擇不根據提示採取行動。

預先算繪的影響

預先算繪可讓網頁幾乎即時載入，如以下影片所示：

預先算繪的影響範例。

範例網站本身的速度已經很快，但即使如此，您還是可以看到預先算繪如何改善使用者體驗。因此，這也會直接影響網站的 Core Web Vitals，LCP 幾乎為零、CLS 降低 (因為任何載入 CLS 都發生在初始檢視之前)，INP 則有所改善 (因為載入應在使用者互動前完成)。

即使網頁在完全載入前就啟用，預先載入網頁仍可改善載入體驗。如果在預先算繪期間啟用連結，預先算繪頁面會移至主頁框並繼續載入。

不過，預先算繪確實會耗用額外的記憶體和網路頻寬。請注意，不要過度預先算繪，以免耗用使用者資源。只有在使用者很可能前往該頁面時，才預先算繪。

如要進一步瞭解如何評估分析中的實際成效影響，請參閱「評估成效」一節。

查看 Chrome 網址列預測查詢字串

針對第一個用途，您可以在 chrome://predictors 頁面查看 Chrome 對網址的預測：

Chrome 預測工具頁面。

綠線表示有足夠的信心觸發預先算繪。在這個範例中，輸入「s」時，Chrome 的信心程度合理 (琥珀色)，但輸入「sh」後，Chrome 就有足夠的信心，認為你幾乎總是前往 https://sheets.google.com。

這張螢幕截圖是在相對較新的 Chrome 安裝作業中擷取，並篩除可信度為零的預測結果，但如果您查看自己的預測器，可能會看到更多項目，而且可能需要更多字元才能達到足夠的可信度。

這些預測工具也會在網址列中顯示建議選項，您可能已經注意到：

網址列「預測輸入」功能。

Chrome 會根據你輸入的內容和選取的項目，持續更新預測工具。

• 如果信賴水準超過 30% (顯示為琥珀色)，Chrome 會主動預先連線至網域，但不會預先算繪網頁。
• 如果信賴水準高於 50% (以綠色顯示)，Chrome 就會預先算繪網址。

Speculation Rules API

如果使用 Speculation Rules API 預先算繪選項，網頁程式開發人員可以在網頁中插入 JSON 指令，告知瀏覽器要預先算繪哪些網址。

網址清單

推測規則可以根據網址清單設定：

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

文件規則

推測規則也可以是使用 where 語法的「文件規則」。這項規格會根據 href 選取器 (以 網址模式 API 為基礎) 或 CSS 選取器，推測文件中找到的連結：

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

注意： Speculation Rules API 過去包含 source 鍵，清單網址會設為 list，文件網址則設為 document，但由於這可以從 urls 或 where 鍵 (兩者互斥) 的存在推斷出來，因此 Chrome 121 已移除這項規定。您可能仍會在某些網站或範例程式碼中看到這個 source 鍵。

Eagerness

Browser Support

• 121
• 121
• 
• 

Source

eagerness 設定用於指出何時應觸發推測，這對文件規則特別有用：

• conservative：在點下游標或觸碰時推測。
• moderate：在電腦上，如果將游標懸停在連結上 200 毫秒，或者發生 pointerdown 事件 (以較快者為準，在行動裝置上沒有 hover 事件)，那麼就執行推測。自 2025 年 8 月起，行動裝置改為根據複雜的可視區域經驗法則計算。使用者停止捲動 500 毫秒後，系統會觸發複雜的可視區域經驗法則，適用於垂直距離在前一個指標向下 30% 內的錨定標記，其中錨定標記的大小至少是可視區域中最大錨定標記的 0.5 倍。如這份文件所述。
• eager：這項積極程度設定的運作方式原本與 immediate 相同，但自 Chrome 143 起有所變更。在電腦上，如果將游標懸停在連結上 10 毫秒，就會執行推測。自 2026 年 1 月起，行動裝置改為根據簡易可視區域經驗法則判斷。錨定標記進入可視區域後，簡單的可視區域經驗法則會在 50 毫秒後觸發。
• immediate：用於盡快推測，亦即發現推測規則時就開始推測。

list 規則的預設 eagerness 為 immediate。eager、moderate 和 conservative 選項可用來限制 list 規則，只套用至使用者與特定清單互動的網址。不過，在許多情況下，使用具有適當 where 條件的 document 規則可能更合適。

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

要使用哪種 eagerness 設定取決於您的網站。如果是輕量靜態網站，積極推測可能不會耗費太多資源，而且對使用者有益。如果網站架構較複雜，且網頁酬載較重，建議減少推測次數，直到使用者展現更明確的意圖信號，再進行推測，以免浪費資源。

注意： 過度推測會對使用者造成明顯的頻寬、記憶體和 CPU 成本，但也會對網站本身造成影響。實作推測時，請留意對使用者造成的影響。eagerness 設定可降低浪費推測的可能性。Chrome 也會對推測設限，減少過度使用的影響。

moderate 選項是折衷方案，許多網站都能受益於下列推測規則：當指標懸停在連結上 200 毫秒，或在 pointerdown 事件發生時，預先算繪連結，這是基本但強大的推測規則實作方式：

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

預先擷取

推測規則也可用於預先擷取網頁，而不必完整預先算繪。這通常是預先算繪的第一步：

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

注意：舊版 <link rel="prefetch"> 資源提示只會預先擷取至 HTTP 快取，而使用推測規則載入的文件則會以與導覽相同的方式處理 (但不會算繪)，並保留在記憶體中，因此瀏覽器在需要時能更快取得。這也允許預先擷取無法在 HTTP 快取中快取的文件。

由於使用 <link rel="prefetch"> 預先擷取文件時會發生問題，建議您日後使用推測規則進行導覽，並僅使用 <link rel="prefetch"> 預先擷取子資源。相反地，推測規則應使用於文件導覽推測，而非子資源預先擷取，特別是考量到 Speculation Rules API 的跨來源限制。

Prerender until script

實驗功能：這是 Speculation Rules API 的新功能，目前仍在開發階段，尚未預設啟用。我們將從 2026 年 1 月起，針對這項功能進行來源試用。

Chrome 團隊也正努力將 prerender_until_script 新增至 Speculation Rules API (請參閱導入錯誤)。這個步驟介於預先擷取和預先算繪之間，使用方式類似：

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

與 NoState prefetch 類似，這會預先擷取 HTML 文件，以及該 HTML 中可用的子資源。不過，系統會進一步預先算繪網頁，並在遇到第一個指令碼時停止。

這表示如果網頁沒有 JavaScript，或只有在頁尾有 JavaScript，網頁幾乎可以完全預先算繪。<head> 中含有指令碼的網頁無法預先算繪，但仍可透過子資源擷取功能受益。

這樣可以避免 JavaScript 執行時產生非預期的副作用，但效能提升幅度會比單純使用 prefetch 大得多。

Chrome 限制

Chrome 設有限制，防止過度使用 Speculation Rules API：

eagerness	預先擷取	預先算繪
immediate	50	10
行動裝置：eager/moderate	6 (FIFO)	2 (FIFO)
eager/moderate (電腦版)	2 (FIFO)	2 (FIFO)
conservative	2 (FIFO)	2 (FIFO)

Chrome 的推測限制

。

eager、moderate 和 conservative 設定取決於使用者互動，並以先進先出 (FIFO) 方式運作：達到上限後，新的推測會導致最舊的推測取消，並由較新的推測取代，以節省記憶體。

取消的推測可以再次觸發，例如再次將滑鼠游標懸停在該連結上，這會導致該網址重新推測，並推送最舊的推測。在這種情況下，先前的推測會將該網址的所有可快取資源快取到 HTTP 快取中，因此再次推測時，成本應該會降低。因此，系統預設將上限設為保守的 2 次。在行動裝置上，我們將預先擷取的門檻提高到 6，因為行動裝置沒有「懸停」動作，替代的行動可視區域經驗法則較不準確，且預先擷取的成本低於預先算繪 (在行動裝置上，我們將預先算繪的限制維持在 2)。

靜態清單規則不會由使用者動作觸發，因此上限較高，因為瀏覽器無法得知需要哪些規則以及何時需要。

Chrome 也考慮將行動裝置上的 eager 和 moderate 限制提高到 5，至少預先擷取，因為這是較不精確的經驗法則。使用 eager 的開發人員，可以考慮搭配使用 conservative 規則，這樣一來，當可視區域中有多個連結時，即使連結未獲選為前兩個連結，系統仍會進行推測。

immediate 限制也是動態的，因此移除 list 網址指令碼元素會取消移除的推測，進而釋出容量。

Chrome 也會禁止在特定情況下使用推測功能，包括：

• Save-Data。
• 節能模式：啟用且電量不足時。
• 記憶體限制。
• 「預先載入網頁」設定已關閉 (uBlock Origin 等 Chrome 擴充功能也會明確關閉這項設定)。
• 在背景分頁中開啟的網頁。

此外，Chrome 也不會在預先算繪的網頁上算繪跨源 iframe，直到網頁啟用為止。

這些條件都是為了減少過度推測對使用者造成的負面影響。

如何在網頁中加入推測規則

提示：如要進一步瞭解如何為更複雜的網站使用推測規則，請參閱複雜網站適用的推測規則導入指南。

推測規則可以靜態方式包含在網頁的 HTML 中，也可以透過 JavaScript 動態插入網頁：

• 靜態包含的推測規則：舉例來說，如果新聞媒體網站或網誌經常是大部分使用者的下一個瀏覽目標，則可能會預先算繪最新文章。或者，您也可以使用含有 moderate 或 conservative 的文件規則，在使用者與連結互動時進行推測。
• 動態插入的推測規則：這可能取決於應用程式邏輯、使用者個人化設定或其他經驗法則。

如果偏好根據懸停或點選連結等動作動態插入 (就像過去許多程式庫使用 <link rel=prefetch> 的做法)，建議您查看文件規則，因為瀏覽器可透過這些規則處理許多用途。

推測規則可新增至主頁框的 <head> 或 <body>。系統不會執行子頁框中的推測規則，而預先算繪頁面中的推測規則，則會在該頁面啟用後才執行。

Speculation-Rules HTTP 標頭

Browser Support

• 121
• 121
• x
• 

Source

推測規則也可以透過 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 檔案的網址。如果您需要選取部分或所有同源連結，這個方法特別實用。

推測規則標記欄位

Browser Support

• 136
• 136
• x
• 

Source

您也可以在推測規則 JSON 語法中，為規則集內的所有推測規則新增「標記」：

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

或在個別規則層級：

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

這個標記會反映在 Sec-Speculation-Tags HTTP 標頭中，可用於篩選伺服器上的推測規則。如果推測規則涵蓋多項規則，Sec-Speculation-Tags HTTP 標頭可以包含多個標記，如以下範例所示：

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

部分 CDN 會自動插入推測規則，但會封鎖非邊緣快取網頁的推測，避免這項功能導致原始伺服器用量增加。標記可讓他們識別由預設規則集啟動的推測，但仍允許網站新增的任何規則傳遞至來源。

規則集標記也會顯示在 Chrome 開發人員工具中。

推測規則 target_hint 欄位

Browser Support

• 138
• 138
• x
• x

Source

推測規則也可以包含 target_hint 欄位，其中包含有效的瀏覽情境名稱或關鍵字，指出網頁預期啟用預先算繪內容的位置：

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

這項提示可讓系統處理 target="_blank" 連結的預先算繪推測：

<a target="_blank" href="next.html">Open this link in a new tab</a>

目前 Chrome 僅支援 "target_hint": "_blank" 和 "target_hint": "_self" (如未指定，則為預設值)，且僅適用於預先算繪，不支援預先擷取。

只有 urls 推測規則需要 target_hint，因為文件規則的 target 是從連結本身得知。

推測規則和 SPA

推測規則僅支援由瀏覽器管理的完整網頁導覽，不支援單頁應用程式 (SPA) 或應用程式殼層網頁。這類架構不會擷取文件，而是擷取 API 或部分資料/網頁，然後在目前網頁中處理及呈現。這類「軟導覽」所需的資料可由應用程式預先擷取，不受推測規則限制，但無法預先算繪。

推測規則可用於從前一個頁面預先算繪應用程式本身。這有助於抵銷部分 SPA 額外的初始載入成本。不過，應用程式內的路徑變更無法預先算繪。

對推測規則執行偵錯

請參閱偵錯推測規則的專屬文章，瞭解 Chrome 開發人員工具的新功能，協助查看及偵錯這個新的 API。

多項推測規則

同一個網頁也可以加入多項推測規則，並附加至現有規則。因此，下列不同方式都會導致 one.html 和 two.html 預先算繪：

網址清單：

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

多個 speculationrules 指令碼：

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

一組 speculationrules 中有多個清單

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

「No-Vary-Search」支援頁面

Browser Support

• 141
• 141
• 154
• x

Source

預先擷取或預先算繪網頁時，某些網址參數 (技術上稱為「搜尋參數」) 可能對伺服器實際提供的網頁不重要，且僅供用戶端 JavaScript 使用。

舉例來說，Google Analytics 會使用 UTM 參數評估廣告活動，但通常不會導致伺服器提供不同的網頁。也就是說，page1.html?utm_content=123 和 page1.html?utm_content=456 會從伺服器傳送相同的網頁，因此可以重複使用快取中的相同網頁。

同樣地，應用程式可能會使用其他僅在用戶端處理的網址參數。

No-Vary-Search 提案允許伺服器指定不會導致傳送資源差異的參數，因此允許瀏覽器重複使用先前快取的文件版本，這些版本僅因這些參數而有所不同。Chrome (和以 Chromium 為基礎的瀏覽器) 支援這項功能，可用於預先擷取和預先算繪的導覽推測。

注意：搭配 No-Vary-Search 使用預先算繪功能時，系統可能會使用不同的搜尋參數 (或完全不使用搜尋參數) 預先算繪網頁。一開始，網址 (例如 location.href 傳回的網址) 會是預先算繪的網址，但如果點選的連結含有 No-Vary-Search 涵蓋的不同搜尋參數，瀏覽器就會使用該預先算繪網頁，並將網址替換為最終網址 (包括正確的搜尋參數)。

因此，任何依賴搜尋參數的 JavaScript，都應在網頁啟用後才執行。如果分析程式碼在啟用後才執行，則 UTM 參數可能不會造成問題。不過，如果用戶端轉譯網頁會根據搜尋參數轉譯不同內容，則可能會造成問題，因此請務必謹慎，確保用戶端轉譯內容在啟用時更新。

推測規則支援使用 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 的初始網頁 HTML /products 相同。不過，網頁內容最終會因用戶端轉譯而有所不同，因為用戶端轉譯會使用 JavaScript 擷取產品資料，並使用 id 搜尋參數。因此，我們會預先擷取該網址，而該網址應傳回 No-Vary-Search HTTP 標頭，表示該網頁可用於任何 id 搜尋參數。

不過，如果使用者在預先擷取完成前點選任何連結，瀏覽器可能尚未收到 /products 網頁。在這種情況下，瀏覽器不知道是否會包含 No-Vary-Search HTTP 標頭。瀏覽器可以選擇再次擷取連結，或等待預先擷取完成，確認是否包含 No-Vary-Search HTTP 標頭。expects_no_vary_search 設定可讓瀏覽器知道網頁回應應包含 No-Vary-Search HTTP 標頭，並等待預先擷取完成。

注意：只使用 expects_no_vary_search 不足以確保重複使用具有不同搜尋參數的網頁，這比較像是提示瀏覽器預期的行為。伺服器也必須傳回 No-Vary-Search HTTP 標頭，瀏覽器才會知道即使搜尋參數不相符，仍可使用快取中的網頁。

您也可以在 expects_no_vary_search 中加入多個參數，並以空格分隔 (因為 No-Vary-Search 是 HTTP 結構化標頭)：

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

推測規則限制和未來強化功能

推測規則僅限於在同一個分頁中開啟的網頁，但我們正努力減少這項限制。

根據預設，預先算繪功能僅限用於同源網頁。您可以啟用預先算繪功能，預先算繪同網站但不同來源的頁面 (例如 https://a.example.com 可預先算繪 https://b.example.com 上的頁面)。如要使用這項功能，推測網頁 (本例中為 https://b.example.com) 必須加入 Supports-Loading-Mode: credentialed-prerender HTTP 標頭，否則 Chrome 會取消推測。

未來版本也可能允許預先算繪非同站的跨來源網頁，前提是預先算繪的網頁沒有 Cookie，且預先算繪的網頁選擇加入類似的 Supports-Loading-Mode: uncredentialed-prerender HTTP 標頭。

推測規則已支援跨源預先擷取，同網站、跨源預先擷取沒有任何限制。只有在跨來源網域的 Cookie 不存在時，系統才支援不同網站的跨來源預先擷取。如果使用者先前造訪該網站時留有 Cookie，系統就不會使用推測，並在開發人員工具中顯示失敗。

注意：如果透過 anonymous-client-ip-when-cross-origin 指令使用私人預先擷取 Proxy，Chrome 仍會傳送匿名預先擷取要求 (不含 Cookie)，但系統會捨棄預先擷取回應。這樣一來，網頁和 Proxy 就無法共同偵測使用者是否擁有第三方網站的 Cookie。如果不使用 Proxy，系統就不會在 Cookie 存在時傳送預先擷取要求。

考量到目前的限制，如要改善內部和外部連結的使用者體驗，可行的做法是預先算繪同源網址，並嘗試預先擷取跨源網址：

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

根據預設，系統會限制跨來源連結的跨來源推測，這是基於安全考量。這項功能比 <link rel="prefetch"> 更進步，因為 <link rel="prefetch"> 雖然也不會傳送 Cookie，但仍會嘗試預先擷取，這會導致預先擷取失敗而需要重新傳送，更糟的是，可能會載入錯誤的網頁。

偵測 Speculation Rules API 支援

您可以使用標準 HTML 檢查，偵測瀏覽器是否支援 Speculation Rules API：

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

透過 JavaScript 動態新增推測規則

以下範例說明如何使用 JavaScript 新增 prerender 推測規則：

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

您可以前往這個預先算繪示範頁面，查看 Speculation Rules API 預先算繪的示範 (使用 JavaScript 插入)。

<script type = "speculationrules">元素直接使用innerHTML插入到 DOM 中，將不會註冊推測規則基於安全考量，且必須如先前所示加入。不過，如果使用 innerHTML 動態插入的內容包含新連結，頁面上的現有規則就會偵測到這些連結。

同樣地，直接在 Chrome 開發人員工具中編輯「Elements」面板來新增 <script type = "speculationrules"> 元素，並不會註冊推測規則，而是必須從控制台執行指令碼，以動態方式將規則新增至 DOM，才能插入規則。

透過代碼管理工具新增推測規則

如要使用 Google 代碼管理工具 (GTM) 等代碼管理工具新增推測規則，必須透過 JavaScript 插入這些規則，而不是直接透過 GTM 新增 <script type = "speculationrules"> 元素，原因與先前所述相同：

透過 Google 代碼管理工具新增推測規則。

請注意，這個範例使用 var，因為 GTM 不支援 const。

取消推測規則

移除推測規則會導致預先算繪作業取消。不過，發生這種情況時，可能已經耗用資源啟動預先算繪，因此如果可能需要取消預先算繪，建議不要預先算繪。另一方面，快取的資源仍可重複使用，因此取消作業可能不會完全浪費，仍可能有利於未來的推測和導覽。

Browser Support

• 138
• 138
• x
• x

Source

您也可以使用 Clear-Site-Data HTTP 標頭搭配 prefetchCache 和 prerenderCache 指令取消推測。

如果伺服器上的狀態有所變更，這項功能就相當實用。例如呼叫「加入購物籃」API，或登入/登出 API。

理想情況下，這些狀態更新會使用 Broadcast Channel API 等 API 傳播至預先算繪頁面，但如果無法這麼做，或在實作這類邏輯之前，取消預測可能會比較容易。

推測規則和內容安全政策

由於推測規則使用 <script> 元素，即使只包含 JSON，如果網站使用 script-src Content-Security-Policy，也必須包含在其中，無論是使用雜湊或 Nonce。

script-src 可新增 inline-speculation-rules，支援從雜湊或 Nonce 指令碼插入的 <script type="speculationrules"> 元素。這項功能不支援初始 HTML 中包含的規則，因此對於使用嚴格 CSP 的網站，必須透過 JavaScript 插入規則。

偵測及停用預先算繪

預先算繪通常能為使用者帶來良好體驗，因為網頁算繪速度很快，通常能立即完成。這對使用者和網站擁有者都有好處，因為預先算繪的網頁可提供更優質的使用者體驗，而這可能是其他方式難以達成的。

不過，有時您可能不希望預先算繪網頁，例如網頁狀態變更時 (根據初始要求或網頁上執行的 JavaScript)。

在 Chrome 中啟用及停用預先算繪

只有在 chrome://settings/performance/ 中啟用「預先載入網頁」設定的 Chrome 使用者，才能使用預先算繪功能。此外，如果裝置記憶體不足，或作業系統處於數據節省模式或節能模式，系統也會停用預先算繪功能。請參閱「Chrome 限制」一節。

偵測並停用預先算繪伺服器端

預先算繪的網頁會與 Sec-Purpose HTTP 標頭一併傳送：

Sec-Purpose: prefetch;prerender

使用 Speculation Rules API 預先擷取的網頁，會將這個標頭設為 prefetch：

Sec-Purpose: prefetch

伺服器可以根據這個標頭做出回應，記錄推測要求、傳回不同內容，或防止預先算繪。如果傳回的最終回應代碼並非成功代碼 (即重新導向後不在 200 至 299 範圍內)，系統就不會預先算繪網頁，並會捨棄所有預先擷取的網頁。另請注意，204 和 205 回應不適用於預先算繪，但適用於預先擷取。

如果不想預先算繪特定網頁，最好的做法是傳回非 2XX 回應代碼 (例如 503)，確保系統不會預先算繪該網頁。不過，為了提供最佳體驗，建議您允許預先算繪，但使用 JavaScript 延遲任何只有在實際瀏覽網頁時才應執行的動作。

在 JavaScript 中偵測預先算繪

頁面預先算繪時，document.prerendering API 會傳回 true。網頁可利用這項功能，在預先算繪期間防止或延遲特定活動，直到網頁實際啟動為止。

預先算繪的文件啟用後，PerformanceNavigationTiming 的 activationStart 也會設為非零時間，代表預先算繪開始到文件實際啟用之間的時間。

您可以透過函式檢查「預先算繪」和「已預先算繪」的網頁，如下所示：

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

如要查看網頁是否已預先算繪 (完整或部分)，最簡單的方法是在網頁啟用後開啟開發人員工具，然後在控制台中輸入 performance.getEntriesByType('navigation')[0].activationStart。如果傳回非零值，表示網頁已預先算繪：

在控制台中測試預先算繪。

提示：Chrome 開發人員工具提供其他偵錯功能，可用於偵錯預先擷取和預先算繪的網頁。詳情請參閱對推測規則執行偵錯一文。

當使用者瀏覽網頁而啟用網頁時，系統會在 document 上調度 prerenderingchange 事件，然後可用於啟用先前預設在載入網頁時啟動，但您想延遲到使用者實際瀏覽網頁時才啟動的活動。

前端 JavaScript 可使用這些 API，偵測預先算繪頁面並採取適當行動。

警告：PerformanceNavigationTiming.type 不會使用 prerender 值，該值適用於舊版原始 <link rel="prerender"...> 導覽類型。這項設定日後可能會有變動，但目前用戶端應使用 document.prerendering API 識別預先算繪頁面，並使用非零的 PerformanceNavigationTiming.activationStart 欄位識別已啟用的預先算繪頁面。

對數據分析的影響

分析功能用於評估網站使用情形，例如使用 Google Analytics 評估網頁瀏覽和事件。或使用實際使用者監控 (RUM) 評估網頁的成效指標。

只有在使用者很有可能載入網頁時，才應預先算繪網頁。因此，只有在機率極高 (超過 80%) 時，Chrome 網址列才會預先算繪。

不過，預先算繪的網頁可能會影響數據分析 (尤其是使用 Speculation Rules API 時)，網站擁有者可能需要新增額外程式碼，才能在啟用時啟用預先算繪網頁的數據分析，因為並非所有數據分析供應商都會預設執行這項操作。

注意：Google Analytics 預設會延遲預先算繪，直到啟用為止。Google 發布商廣告代碼 (GPT) 和 Google AdSense 也會延遲到啟動後才執行。另請參閱其他已知支援預先算繪的供應商。

如要達到這個目的，可以使用 Promise，在文件預先算繪時等待 prerenderingchange 事件，或在文件預先算繪完成時立即解析：

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

另一種方法是延遲分析活動，直到網頁首次顯示為止，這樣就能涵蓋預先算繪的情況，以及在背景開啟分頁時 (例如按一下滑鼠右鍵並在新分頁中開啟)：

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

雖然這可能適用於數據分析和類似用途，但在其他情況下，您可能需要載入更多內容，因此建議使用 document.prerendering 和 prerenderingchange，專門指定預先算繪頁面。

預先算繪期間暫緩載入其他內容

您可以使用先前討論過的 API，在預先算繪階段保留其他內容。這可以是 JavaScript 的特定部分，也可以是您不希望在預先算繪階段執行的整個指令碼元素。

舉例來說，假設有以下指令碼：

<script src="https://example.com/app/script.js" async></script>

您可以將其變更為動態插入的指令碼元素，該元素只會根據先前的 whenActivated 函式插入：

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

這項功能可用於保留不同的指令碼，包括分析指令碼，或根據狀態或其他可能在造訪期間變更的變數算繪內容。舉例來說，系統可能會保留推薦內容、登入狀態或購物籃圖示，確保呈現最新資訊。

雖然使用預先算繪時，這種情況可能更常發生，但上述條件也適用於先前提到在背景分頁中載入的網頁 (因此可以使用 whenFirstVisible 函式取代 whenActivated)。

在許多情況下，最好也檢查一般 visibilitychange 變更的狀態，例如返回背景頁面時，任何購物籃計數器都應更新為購物籃中的最新商品數量。因此，這並非預先算繪特有的問題，只是預先算繪讓現有問題更加明顯。

Chrome 減少手動包裝指令碼或函式需求的方法之一，是如前所述保留特定 API，且不轉譯第三方 iframe，因此只有這類內容需要手動保留。

評估成效

評估成效指標時，分析工具應考量是否要根據啟用時間 (而非瀏覽器 API 回報的網頁載入時間) 評估這些指標。

Core Web Vitals 是 Chrome 透過 Chrome 使用者體驗報告評估的指標，用於衡量使用者體驗。因此，這些指標是根據啟用時間計算。這通常會使 LCP 縮短至 0 秒，因此是改善 Core Web Vitals 的絕佳方法。

自 3.1.0 版起，web-vitals 程式庫已更新，可按照 Chrome 評估 Core Web Vitals 的方式，處理預先算繪的導覽。如果網頁已完全或部分預先算繪，這個版本也會在 Metric.navigationType 屬性中標記這些指標的預先算繪導覽。

評估預先算繪

如果 PerformanceNavigationTiming 的 activationStart 項目不為零，就表示網頁已預先算繪。接著，您可以使用自訂維度或類似功能記錄網頁瀏覽，例如使用先前所述的 pagePrerendered 函式：

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

這樣一來，數據分析就能顯示預先算繪的導覽次數與其他類型的導覽次數，並將任何成效指標或業務指標與這些不同的導覽類型建立關聯。網頁載入速度越快，使用者就越滿意，這通常會對業務指標產生實質影響，如我們的個案研究所示。

評估預先算繪網頁對即時瀏覽的業務影響後，您可以決定是否值得投入更多心力，使用這項技術預先算繪更多瀏覽，或調查網頁未預先算繪的原因。

評估命中率

除了評估預先算繪後造訪的網頁影響，也必須評估預先算繪但「未」隨後造訪的網頁。這可能表示您預先算繪過多內容，耗用使用者的寶貴資源，卻幾乎沒有效益。

如要評估這項指標，請先使用 HTMLScriptElement.supports('speculationrules') 確認瀏覽器支援預先算繪，然後在插入推測規則時觸發數據分析事件，表示已要求預先算繪。(請注意，要求預先算繪並不代表預先算繪已開始或完成，因為如前所述，預先算繪只是給瀏覽器的提示，瀏覽器可能會根據使用者設定、目前的記憶體用量或其他經驗法則，選擇不預先算繪網頁)。

接著，您可以比較這些事件的數量與實際預先算繪網頁瀏覽次數。或者，您也可以在啟用時觸發另一個事件，方便比較。

接著，您可以查看這兩個數字之間的差異，估算「成功命中率」。如果網頁使用 Speculation Rules API 預先算繪，您可以適當調整規則，確保命中率維持在高水準，在「使用使用者資源提供協助」和「不必要地使用資源」之間取得平衡。

請注意，部分預先算繪作業可能是由網址列預先算繪觸發，而非僅由推測規則觸發。如要區分這些導覽，可以查看 document.referrer (網址列導覽 (包括預先算繪的網址列導覽) 會留空)。

請記得查看沒有預先算繪的網頁，因為這可能表示這些網頁不符合預先算繪資格，即使從網址列也無法預先算繪。這表示您可能無法享有這項效能提升功能。Chrome 團隊正在考慮新增額外工具，用於測試預先算繪資格，可能類似 bfcache 測試工具，並可能新增 API，用於揭露預先算繪失敗的原因。

對擴充功能的影響

請參閱「Chrome 擴充功能：擴充 API 以支援即時導覽」專文，其中詳細說明擴充功能作者可能需要考量的預先算繪網頁相關事項。

意見回饋

Chrome 團隊正在積極開發預先算繪功能，並計劃擴大 Chrome 108 版本中提供的功能範圍。歡迎前往 GitHub 存放區或使用Issue Tracker提供意見，我們期待收到並分享這個令人期待的新 API 案例研究。

相關連結

• 推測規則程式碼實驗室
• 對推測規則執行偵錯
• NoState Prefetch 簡介
• Speculation Rules API 規格
• 導覽推測 GitHub 存放區
• Chrome 擴充功能：擴充 API 以支援即時導覽

特別銘謝

縮圖圖片來源：Marc-Olivier Jodoin 發表於 Unsplash 網站上