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

Barry Pollard

發布日期：2022 年 12 月 2 日，上次更新日期：2025 年 5 月 30 日

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox: not supported.
  • Safari: not supported.

Source

Chrome 團隊已恢復使用者可能前往的未來網頁完整預先顯示功能。

預先算繪的簡要歷史

過去，Chrome 支援 資源提示，但在 Chrome 以外的環境中並未廣泛支援，且這並非非常具表現力的 API。

這個使用連結 rel=prerender 提示的舊版預先算繪功能已淘汰，改為使用 NoState Prefetch，後者會擷取未來網頁所需的資源，但不會完全預先算繪網頁或執行 JavaScript。NoState Prefetch 確實可改善資源載入作業，進而提升網頁效能，但不會像完整預先算繪那樣提供即時網頁載入作業。

Chrome 團隊現已將完整預先算繪功能重新導入 Chrome。為避免與現有用法產生複雜問題，並讓預先顯示功能日後能擴充，這個新的預先顯示機制不會使用 語法，後者仍會用於 NoState 預先擷取功能，但我們會在日後淘汰這個語法。

如何預先算繪網頁？

網頁可透過四種方式預先算繪，這些方式都旨在加快導覽速度：

  1. 當你在 Chrome 網址列 (又稱「萬用盒」) 中輸入網址時，如果 Chrome 根據你的先前瀏覽記錄，判斷你很可能會造訪該網頁，就可能自動為你預先顯示該網頁。
  2. 使用書籤列時，如果您將游標懸停在其中一個書籤按鈕上，Chrome 可能會自動為您預先顯示網頁。
  3. 當你在 Chrome 網址列中輸入搜尋字詞時，Chrome 可能會在搜尋引擎指示下，自動預先顯示搜尋結果頁面。
  4. 網站可以使用推測規則 API，透過程式輔助方式告知 Chrome 要預先算繪哪些網頁。這項功能取代了 的功能，可讓網站根據網頁上的推測規則，主動預先算繪網頁。這些元素可靜態存在於網頁上，或由 JavaScript 視需要動態插入。

在上述每個情況中，預先算繪的行為都會以在不可見背景分頁中開啟網頁的方式運作，然後透過將前景分頁取代為預先算繪的網頁來「啟用」。如果網頁在完全預先轉譯前就已啟用，則其目前狀態為「前景」，並會繼續載入，這表示您仍可取得良好的起跑點。

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

預先算繪的影響

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

預先算繪的影響範例。

範例網站的速度已經很快，但即使如此，您還是可以看到預先顯示如何改善使用者體驗。因此，這也可能會直接影響網站的網站體驗核心指標，LCP 幾乎為零、CLS 降低 (因為任何載入 CLS 都會發生在初始檢視之前)，以及 INP 改善 (因為載入作業應在使用者互動前完成)。

即使網頁在完全載入前就會啟動，只要網頁載入作業有領先優勢，應該就能改善載入體驗。如果在預先算繪期間啟用連結，預先算繪頁面會移至主要框架並繼續載入。

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

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

查看 Chrome 網址列的預測結果

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

根據輸入的文字，Chrome 預測工具頁面會篩選顯示低 (灰色)、中 (琥珀色) 和高 (綠色) 預測。
Chrome 預測功能頁面。

綠色線表示系統有足夠的信心觸發預先算繪。在這個範例中，輸入「s」會提供合理的信心 (琥珀色)，但輸入「sh」後，Chrome 就會判斷你幾乎一定會前往 https://sheets.google.com。

這張螢幕截圖是在安裝較新的 Chrome 版本時拍攝，並過濾掉零可信度的預測結果，但如果您查看自己的預測器，可能會看到更多項目，且可能需要更多字元才能達到足夠的可信度。

這些預測功能也會影響你可能注意到的地址列建議選項：

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

Chrome 會根據您輸入的內容和所選項目，持續更新預測模型。

  • 如果信心等級超過 50% (顯示為琥珀色)，Chrome 會主動預先連線至網域，但不會預先轉譯網頁。
  • 如果信心等級超過 80% (以綠色顯示)，Chrome 就會預先算繪網址。

Speculation Rules API

針對「Speculation Rules API」預先顯示選項，網頁開發人員可以在網頁上插入 JSON 指示，告知瀏覽器要預先顯示哪些網址：

或使用文件規則 (Chrome 121 以上版本提供)，根據 href 選取器 (根據 URL Pattern API) 或 CSS 選取器，預先轉譯文件中的連結：

Chrome 團隊已準備好推測規則程式碼研究室，將逐步引導您在網站中新增推測規則。

熱切

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

  • 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 選項是一種折衷做法，許多網站都能從下列推測規則中受益，這個規則會在游標懸停在連結上 200 毫秒或在 pointerdown 事件發生時預先算繪連結，這是一種基本但強大的推測規則實作方式：

預先擷取

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

Chrome 限制

Chrome 設有限制，可避免 Speculation Rules API 過度使用：

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

moderate 和 conservative 設定會根據使用者互動方式運作，採用「先進先出 (FIFO)」方式運作：達到上限後，新的推測會導致最舊的推測遭到取消，並由較新的推測取代，以節省記憶體。取消的推測內容可以再次觸發，例如再次將滑鼠游標懸停在該連結上，這會導致該網址重新推測，並推送最舊的推測內容。在這種情況下，先前的推測會在該網址的 HTTP 快取中快取任何可快取的資源，因此推測的時間越長，成本就會越低。因此，我們將限制設為 2 這個適中的門檻。靜態清單規則不會因使用者操作而觸發，因此瀏覽器無法得知哪些規則需要執行，也無法得知何時需要執行，因此上限較高。

immediate 和 eager 限制也是動態的，因此移除 list 網址指令碼元素會取消這些移除的推測，進而創造容量。

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

  • 節省資料。
  • 開啟節能模式並在電量不足時，系統會啟用節能模式。
  • 記憶體限制。
  • 關閉「預先載入網頁」設定 (Chrome 擴充功能 (例如 uBlock Origin) 也會明確關閉這項設定)。
  • 在背景分頁中開啟的網頁。

在啟用前，Chrome 也不會在預先算繪的網頁上算繪跨來源 iframe。

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

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

您可以將推測規則靜態納入網頁的 HTML，也可以透過 JavaScript 動態插入網頁：

  • 靜態內含的推測規則：舉例來說，如果大部分使用者經常會點選最新文章，新聞媒體網站或網誌可能會預先轉譯最新文章。此外，您也可以使用含有 moderate 或 conservative 的文件規則，在使用者與連結互動時推測。
  • 動態插入的推測規則：這可以根據應用程式邏輯、使用者個人化設定，或其他推測法。

如果您偏好根據動作 (例如游標懸停或點按連結) 動態插入內容 (許多程式庫過去曾使用 執行這項操作)，建議您查看文件規則，因為瀏覽器可處理許多用途。

您可以在主框架的 或 中新增推測規則。系統不會執行子畫面中的推測規則，且只有在預先轉譯網頁啟用時，才會執行該網頁中的推測規則。

Speculation-Rules HTTP 標頭

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: not supported.

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

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: not supported.

Source

您也可以在個別規則層級的推測規則 JSON 語法中新增「標記」：

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

或在規則集合中的所有推測規則的整體層級：

{
  "tag": "my-rules",
  "prefetch": [
    "urls": ["next.html"]
  ],
  "prerender": [
    "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 會自動插入推測規則，但會封鎖非 Edge 快取頁面的推測，以免這項功能導致原始伺服器使用量增加。標記可讓他們識別預設規則集啟動的推測，但仍允許網站新增的任何規則傳送至來源。

代碼標記也可用於工具，例如我們想在開發人員工具中新增代碼標記。

推測規則 target_hint 欄位

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

推測規則也可以包含 target_hint 欄位，其中包含有效的瀏覽內容名稱或關鍵字，指出網頁預期預先顯示的內容應在何處啟用：

這項提示可讓系統為 target="_blank" 連結處理預先轉譯的推測內容：

Open this link in a new tab

目前 Chrome 僅支援 "target_hint": "_blank" 和 "target_hint": "_self" (未指定時的預設值)，且僅限預先算繪，不支援預先擷取。

target_hint 僅適用於 urls 推測規則，因為文件規則的 target 可從連結本身得知。

推測規則和 SPA

推測規則僅適用於由瀏覽器管理的完整網頁導覽，不適用於單頁應用程式 (SPA) 或應用程式殼頁面。這些架構不會使用文件擷取功能，而是會使用 API 或部分擷取資料或頁面，然後在目前頁面中處理並顯示這些資料。應用程式可在預測規則之外，預先擷取這些所謂的「軟性導覽」所需的資料，但無法預先轉譯。

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

對推測規則執行偵錯

請參閱專門針對推測規則偵錯的文章，瞭解新的 Chrome 開發人員工具功能，以便查看及偵錯這項新 API。

多個推測規則

您也可以在同一個網頁中加入多個推測規則，並附加至現有規則。因此，以下各種方式都會導致 one.html 和 two.html 預先顯示：

網址清單：

多個 speculationrules 指令碼：

一組 speculationrules 內有多個清單

Browser Support

  • Chrome: 127.
  • Edge: 127.
  • Firefox: not supported.
  • Safari: not supported.

Source

預先載入或預先算繪網頁時，某些網址參數 (技術上稱為「搜尋參數」) 可能對伺服器實際提供的網頁不重要，且只供用戶端 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 標頭預期傳回的位置。這麼做有助於在看到回應前，進一步避免不必要的下載作業。



Product 123
Product 124

在本範例中，/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 標頭，並等待預先載入作業完成。

您也可以在 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 不存在時才會支援。如果使用者先前造訪過該網站，則系統不會使用推測，並會在 DevTools 中顯示失敗。

考量目前的限制，如果您想改善使用者對內部連結和外部連結的體驗，不妨考慮預先算繪同來源網址，並嘗試預先擷取跨來源網址：

為了確保安全性，預設會限制跨來源連結的跨來源推測。這項功能相較於 更適合跨來源目的地，因為後者也不會傳送 Cookie，但仍會嘗試預先載入，這麼做會導致預先載入作業無效，需要重新傳送，更糟的是，還會導致錯誤的網頁載入。

如果頁面由服務工作者控管，則無法使用預先擷取功能，也無法套用 SpeculationRules。我們正在努力新增這項支援。請關注這篇支援服務 worker 問題的更新。服務工作控制的網頁支援預先顯示功能。

偵測 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 插入功能。

使用 innerHTML 將

您可以將這個元素變更為動態插入的指令碼元素，只根據先前的 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，因此 Chrome 只會手動保留頂層內容。

衡量成效

在評估成效指標時，分析師應考慮是否應以啟用時間，而非瀏覽器 API 回報的網頁載入時間來評估這些指標。

至於 Core Web Vitals，則是透過 Chrome 使用者體驗報告評估，用於評估使用者體驗。因此，這些指標的計算依據是啟用時間。這通常會導致 LCP 為 0 秒，顯示這是改善網站體驗核心指標的絕佳方法。

自 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 的案例研究，並與您分享。

特別銘謝

縮圖圖片來源：Marc-Olivier Jodoin 在 Unsplash 網站上提供