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

Barry Pollard

Chrome 團隊重新針對使用者日後可能瀏覽的網頁重新呈現預先轉譯功能。

預先算繪的簡短歷程

在過去，Chrome 支援 <link rel="prerender" href="/next-page"> 資源提示，但除了 Chrome 以外更廣泛支援此設定，而且它的 API 也不可能表達己見。

這項使用連結 rel=prerender 提示的舊版預先轉譯功能已淘汰，並改用 NoState Prefetch (NoState Prefetch)，該方式會擷取未來網頁所需的資源，但並未完整預先轉譯網頁，也並未執行 JavaScript。NoState Prefetch 可協助改善資源載入方式來提高網頁效能，但無法像完整預先轉譯一樣傳送「即時」頁面載入。

Chrome 團隊目前已重新在 Chrome 中重新推出預先算繪功能。為避免現有用量的複雜問題，並方便日後擴展預先算繪作業，這項新的預先算繪機制將不會使用 <link rel="prerender"...> 語法，因為 NoState Prefetch 仍會保留下來，檢視畫面會在日後淘汰。

系統如何預先算繪網頁？

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

1. 當您在 Chrome 網址列輸入網址時 (也稱為「網址列」)，Chrome 可能會根據您的瀏覽記錄，自動預先轉譯網頁。
2. 當你使用書籤列時，Chrome 可能會在你將滑鼠遊標懸停在書籤按鈕上時，自動預先轉譯網頁。
3. 當您在 Chrome 網址列輸入搜尋字詞時，Chrome 可能會自動預先轉譯搜尋結果網頁，並在搜尋引擎中指示。
4. 網站可以使用 Speculation Rules API，透過程式輔助方式告知 Chrome 要預先轉譯哪些網頁。這會取代 <link rel="prerender"...> 原先的功用，並允許網站根據網頁上的推測規則主動預先轉譯網頁。這些檔案可靜態存在於網頁中，或由 JavaScript 動態插入，以做為網頁擁有者判斷之用。

在上述情況下，預先算繪的運作方式都等同於在隱藏的背景分頁中開啟網頁，然後才「啟用」方法是將前景分頁替換為該預先算繪頁面如果網頁在完全預先算繪前已啟用，目前的狀態就會是「前景」並持續載入 這意味著你的起步較好

由於預先算繪頁面是以隱藏狀態開啟，因此部分造成乾擾行為的 API (例如提示) 並未啟用，且會延遲到頁面啟用後才會執行。在少數無法實現此做法的少數情況下，系統會取消預先算繪。Chrome 團隊正努力以 API 形式公開預先算繪取消的理由，並強化開發人員工具功能，以便更輕鬆地找出這類極端情況。

預先算繪的影響

預先算繪功能可讓網頁近乎立即載入，如以下影片所示：

範例網站已有快速瀏覽的網站，但您可以瞭解預先轉譯機制如何改善使用者體驗。因此，這也可能會直接影響網站的Core Web Vitals，其中幾乎沒有 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 毫秒，或在指標事件上以基本 (但功能強大) 實作推測規則時，預先算繪連結規則的優點如下：

<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 URL 指令碼元素後，系統會取消這些已移除的推測來建立容量。

Chrome 也會防止在特定條件下使用推測，包括：

• Save-Data (儲存資料)。
• 節能模式：啟用且耗電量低時。
• 記憶體限制
• 「預先載入網頁」這項設定會關閉 (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>

在這個示例中，產品 ID 123 和 124 的 /products 初始網頁 HTML 都相同。不過，網頁內容最終會因使用 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，但也會嘗試預先擷取；這會造成需要重新傳送的預先擷取作業，或導致網頁載入錯誤的問題持續發生。

對於由 Service Worker 控管的網頁，預先擷取功能不支援推測規則。我們正在努力提供這項支援。請參考支援 Service 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);
}

您可以在這個預先算繪示範頁面中，查看使用 JavaScript 插入的 Speculation Rules API 預先算繪作業。

使用 innerHTML 將 <script type = "speculationrules"> 元素直接插入 DOM 中，不會基於安全考量註冊推測規則，而必須如先前所示新增。不過，透過 innerHTML 動態插入的內容 (含有新連結) 仍會採用網頁上的現有規則。

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

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

如要使用 Google 代碼管理工具 (GTM) 這類代碼管理工具新增推測規則，則必須透過 JavaScript 插入這些規則，而非像上述一樣直接在 GTM 中新增 <script type = "speculationrules"> 元素：

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

取消推測規則

移除推測規則會導致預先算繪遭到取消，但在此時，系統可能已使用資源啟動預先算繪。因此，如果可能必須取消預先算繪，建議您不要預先算繪。

推測規則和內容安全政策

由於推測規則使用 <script> 元素，即使網站只包含 JSON，但仍需要將這類元素加入 script-src Content-Security-Policy (透過雜湊或 Nonce)。

您可以在 script-src 中新增 inline-speculation-rules，以便支援從雜湊或非 Cron 指令碼插入的 <script type="speculationrules"> 元素。這項功能不支援初始 HTML 中的規則，因此針對使用嚴格 CSP 的網站，JavaScript 需要插入規則。

偵測及停用預先算繪

預先算繪的結果通常都能快速轉譯，因此能為使用者提供良好的體驗。這對使用者和網站擁有者都有好處，因為預先轉譯頁面可為使用者提供更好的使用者體驗，而若以其他方式處理，這類網頁就不會顯示。

不過，有時你不希望系統執行網頁預先算繪作業，例如頁面變更狀態 (視初始要求而定)，或根據網頁上的 JavaScript 執行時。

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

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

偵測及停用伺服器端預先轉譯

預先算繪的頁面會以 Sec-Purpose HTTP 標頭傳送：

Sec-Purpose: prefetch;prerender

使用 Speculation Rules API 預先擷取的網頁會將下列標頭設為僅包含 prefetch：

Sec-Purpose: prefetch

伺服器可根據這個標頭回應，記錄推測要求、傳回不同內容，或防止預先算繪發生。如果傳回失敗的回應代碼 (也就是不是 200 或 304)，系統就不會預先算繪網頁，並捨棄任何預先擷取網頁。

如果您不希望系統預先算繪特定網頁，這是確保不會發生的最佳方法。不過，為了提供最佳體驗，建議您改為允許預先算繪，但延遲所有應該發生的操作，然後再使用 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 即可偵測出適當的預先算繪頁面並採取行動。

對數據分析的影響

Analytics 能評估網站使用情形，例如使用 Google Analytics 評估網頁瀏覽和事件。或使用即時使用者監控 (RUM) 評估網頁成效指標。

只有在使用者很可能載入網頁時，才應預先算繪網頁。因此，Chrome 網址列只有在機率非常高 (超過 80% 的時間) 的情況下，才會執行預先轉譯選項。

不過，特別是使用 Speculation Rules 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，因此只有這層需要手動保留的內容。

評估成效

評估成效指標時，Analytics 應考慮以啟用時間為準進行評估，而不是根據瀏覽器 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 規格
• Navigation 推測 GitHub 存放區
• Chrome 擴充功能：擴充 API，支援即時導覽

特別銘謝

縮圖圖片是由 Marc-Olivier Jodoin 提供，來源為 Unsplash 網站上