在 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 預先擷取功能，以便日後淘汰。

如何預先算繪網頁？

系統可以透過下列四種方式預先算繪頁面，達到加快瀏覽速度：

1. 當你在 Chrome 網址列 (又稱「萬用盒」) 中輸入網址時，如果 Chrome 根據你的先前瀏覽記錄，判斷你很可能會造訪該網頁，就會自動為你預先顯示該網頁。
2. 使用書籤列時，如果您將游標懸停在其中一個書籤按鈕上，Chrome 可能會自動為您預先顯示網頁。
3. 當你在 Chrome 網址列中輸入搜尋字詞時，Chrome 可能會在搜尋引擎指示下，自動預先顯示搜尋結果頁面。
4. 網站可以使用 Speculation Rules 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 會使用 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 不存在時才會支援。如果網站先前曾造訪該網站，系統就不會觸發推測，而且開發人員工具會顯示失敗。

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

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

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

如果頁面由服務工作者控制，則無法使用預先載入功能，也無法使用推測規則。我們正在努力新增這項支援。請關注這篇支援服務 worker 問題的更新。預先轉譯功能支援由 Service 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 使用者。此外，如果記憶體不足的裝置，或是作業系統處於 Save-data 或節能模式，系統也會停用預先算繪功能。請參閱「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，因此只有這層需要手動保留的內容。

評估成效

如要評估成效指標，分析師應考量是否應以啟用時間，而非瀏覽器 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');

這樣一來，Analytics 就能顯示預先算繪的導覽數量 (相較於其他類型的導覽)，也可以將所有成效指標或業務指標與這些導覽類型建立關聯。網頁載入速度越快，使用者滿意度就越高，這往往會對業務指標產生實際影響，如案例研究所示。

評估為即時導覽預先載入網頁的業務影響後，您可以決定是否值得投入更多心力，使用這項技術讓更多導覽預先載入，或是調查為何無法預先載入網頁。

評估命中率

除了評估預先算繪後造訪的網頁所產生的影響外，也請評估預先算繪且未造訪的網頁。這可能表示您預先轉譯的內容過多，導致使用者充分運用寶貴資源，因此幾乎沒什麼好處。

您可以透過在插入預測規則時觸發數據分析事件 (在使用 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 網站上提供