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

Barry Pollard

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

預先轉譯簡史

過去，Chrome 支援 <link rel="prerender" href="/next-page"> 資源提示，但在 Chrome 以外的環境中並未廣泛支援，而且也不是特別有表達力的 API。

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

Chrome 團隊現已將完整預先算繪功能重新導入 Chrome。為避免與現有用法產生複雜問題，並且讓預先顯示功能日後能擴充，這個新的預先顯示機制不會使用 <link rel="prerender"...> 語法，而這個語法會保留給 NoState Prefetch 使用，並且日後會淘汰。

如何預先算繪網頁？

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

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

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

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

預先算繪的影響

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

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

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

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

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

查看 Chrome 網址列的預測結果

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

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

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

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

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

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

Speculation Rules API

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

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

或使用文件規則 (Chrome 121 以上版本提供)，根據 href 選取器 (根據 URL Pattern 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>

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

熱切

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 事件發生時預先算繪連結，這項做法是推測規則的基本實作方式，但功能強大：

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

預先擷取

您也可以使用推測規則只預先擷取網頁，而不需要進行完整的預先算繪。這通常是預先算繪的良好起點：

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

Chrome 限制

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

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

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

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

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

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

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

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

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

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

如果您偏好根據動作 (例如游標懸停或點按連結) 動態插入內容，就像許多程式庫過去使用 <link rel=prefetch> 一樣，建議您查看文件規則，因為這些規則可讓瀏覽器處理許多用途。

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

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 檔案的網址。如果你需要選取部分或所有同源連結，這項功能就特別實用。

推測規則和 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」支援頁面

預先載入或預先算繪網頁時，某些網址參數 (技術上稱為「搜尋參數」) 可能對伺服器實際傳送的網頁不重要，且只供用戶端 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://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，因此不會觸發推測，並在 DevTools 中顯示失敗。

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

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

為了安全起見，預設會限制跨來源連結的跨來源推測。這項功能相較於 <link rel="prefetch"> 更適合跨來源目的地，因為後者也不會傳送 Cookie，但仍會嘗試預先載入，這會導致預先載入作業浪費資源，需要重新傳送，或更糟糕的是，導致錯誤的網頁載入。

如果頁面由服務工作者控制，則無法使用預先載入功能，也無法使用推測規則。我們正在努力新增這項支援。請關注這篇支援服務 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 將 <script type = "speculationrules"> 元素直接插入 DOM 時，系統不會註冊推測規則 (出於安全性考量)，因此必須如先前所述新增這項元素。不過，使用 innerHTML 動態插入的內容 (含有新連結) 會由網頁上的現有規則挑選。

同樣地，直接編輯 Chrome 開發人員工具中的「Elements」面板來新增 <script type = "speculationrules"> 元素，並不會註冊推測規則。相反地，必須從控制台執行用於動態新增此元素至 DOM 的腳本，才能插入規則。

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

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

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

取消推測規則

移除推測規則會導致預先算繪作業遭到取消，但在發生這種情況時，資源可能已用於啟動預先算繪作業，因此如果可能需要取消預先算繪作業，建議不要執行預先算繪作業。

推測規則和內容安全政策

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

您可以將新的 inline-speculation-rules 新增至 script-src，以便支援從雜湊或 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。如果傳回的值不為零，表示頁面已預先轉譯：

當使用者瀏覽網頁時，系統會啟用網頁，並在 document 上調度 prerenderingchange 事件，以便啟用先前在網頁載入時預設會啟動的活動，但您希望延後啟用，直到使用者實際瀏覽網頁為止。

透過這些 API，前端 JavaScript 就能適當偵測並處理預先算繪的網頁。

對數據分析的影響

數據分析可用於評估網站使用情形，例如使用 Google Analytics 評估網頁瀏覽次數和事件。或者，您也可以使用真人使用者監控 (RUM) 評估網頁的效能指標。

只有在使用者極有可能載入網頁時，才應預先轉譯網頁。因此，Chrome 網址列預先顯示選項只會在發生這種高機率情況 (超過 80%) 時才會出現。

不過，尤其是在使用「推測規則」API 時，預先算繪的網頁可能會影響數據分析，網站管理員可能需要新增額外程式碼，只在啟用時為預先算繪的網頁啟用數據分析，因為並非所有數據分析供應商都會在預設情況下啟用這項功能。

您可以使用 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，因此 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 後的成果，並與您分享相關案例。

相關連結

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

特別銘謝

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