本頁面由 Cloud Translation API 翻譯而成。

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

Barry Pollard

瀏覽器支援

Chrome 團隊致力研究各種選項，針對使用者日後可能瀏覽的頁面，復原完整的預先算繪結果。

預先算繪的簡短歷史記錄

Chrome 過去支援 <link rel="prerender" href="/next-page"> 資源提示，但這項功能並不是 Chrome 以外的廣泛支援，因此並不是十分說明用途的 API。

這項使用連結 rel=prerender 提示的舊版預先算繪功能已淘汰，改用 NoState Prefetch，改為擷取日後網頁所需的資源，但並未完整預先轉譯網頁，也不會執行 JavaScript。NoState 預先擷取可改善資源載入速度，進而改善網頁效能，但不會像完整預先算繪一樣產生「即時」網頁載入。

Chrome 團隊現已在 Chrome 中重新推出完整的預先算繪功能。為避免現有用法的複雜性，並方便日後擴充預先算繪功能，這項新的預先算繪機制不會使用 <link rel="prerender"...> 語法 (這仍適用於 NoState 預先擷取作業)，且檢視畫面將於日後淘汰。

網頁預先算繪的方式為何？

網頁預先算繪的方法有四種，目標是加快瀏覽速度：

在 Chrome 網址列 (也稱為「網址列」) 中輸入網址時，如果 Chrome 很有把握你造訪該網頁，就會為你自動預先轉譯網頁。
當您在 Chrome 網址列中輸入搜尋字詞時，Chrome 可能會指示搜尋引擎自動預先轉譯搜尋結果網頁。
網站可以使用 Speculation Rules API，透過程式輔助方式讓 Chrome 知道要預先轉譯哪些網頁。這會取代原本用於處理的 <link rel="prerender"...>，讓網站根據該網頁上的推測規則主動預先轉譯網頁。這些資訊可以靜態存在於網頁上，或根據網頁擁有者的考量而動態插入 JavaScript。

在這類情況下，預先算繪行為會假設網頁在隱形背景分頁中開啟，接著以該預先算繪頁面取代前景分頁，藉此「啟用」。如果網頁在完全預先算繪前啟用，目前狀態就會進入「前景」狀態並繼續載入，這表示您還是可以先好的開始。

由於預先算繪頁面是以隱藏狀態開啟，因此許多會造成乾擾行為的 API (例如提示) 無法在這個狀態下啟用，必須等到網頁啟用後才會啟用。在少數情況下無法這樣做，系統會取消預先算繪。Chrome 團隊正努力以 API 的形式公開預先算繪取消的理由，也會增強開發人員工具的功能，方便使用者輕鬆找出這類極端案例。

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

預先算繪的影響

預先算繪功能允許近乎即時地載入網頁，如以下影片所示：

預先算繪的影響示例。

此範例網站已具備快速的網站運作效能，但有了這一點，您就可以瞭解預先算繪如何改善使用者體驗。因此，這也會直接影響網站的網站體驗核心指標，也就是幾乎零個 LCP、降低 CLS (因為所有負載 CLS 發生在初始檢視畫面之前發生)，以及改善 INP (因為必須在使用者進行互動前完成載入)。

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

不過，預先算繪功能會使用額外的記憶體和網路頻寬。請注意，不要超預先算繪，但會增加使用者資源的費用。只在使用者很有可能造訪網頁時才預先算繪。

請查看「評估成效」一節，進一步瞭解如何評估數據分析中的實際成效影響。

查看 Chrome 網址列預測

如果是第一項用途，您可以在 chrome://predictors 頁面中查看 Chrome 對網址的預測查詢字串：

Chrome 預測者頁面的螢幕截圖，已根據輸入文字顯示低 (灰色)、中 (琥珀色) 和高 (綠色) 預測查詢字串。 — Chrome 預測者頁面。

綠色線條表示有足夠可信度，可觸發預先算繪。在此範例中，輸入「s」表示適當的信賴水準 (琥珀色)，但當您輸入「sh」時，Chrome 就能確定您幾乎每次都前往 https://sheets.google.com。

這是在更新 Chrome 時擷取的螢幕畫面，並從中已過濾出零可信度預測。不過，如果你自行查看預測值，可能會發現更多項目，也可能需要更多字元才能達到足夠的可信度。

以下預測項目也是網址列建議選項的推移：

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

如果是高於 50% 的信賴水準 (顯示在琥珀色中)，Chrome 會主動預先連線至網域，但不會預先轉譯網頁。
如果是高於 80% 的信賴水準 (以綠色顯示)，Chrome 會預先算繪網址。

推測規則 API

針對第三個預先算繪選項，網頁程式開發人員可以在網頁中插入 JSON 指示，告知瀏覽器要預先轉譯哪些網址：

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

另一種是根據「文件規則」 (適用於 Chrome 121 版)，根據 href 或 CSS 選取器預先算繪文件中的連結：

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

渴望

瀏覽器支援

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 選項是中間位置，許多網站可以從以下推測規則中受益。這項推測規則會在懸停或指標畫面時預先算繪所有連結，做為基本 (但功能強大) 的推測規則實作。

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

預先擷取

推測規則也可用於在沒有完整預先轉譯的情況下，預先擷取網頁。這通常可做為預先算繪的好方法：

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

注意：與剛剛預先擷取至 HTTP 快取的舊版 <link rel="prefetch"> 資源提示不同，使用推測規則載入的文件的處理方式與瀏覽 (但不會轉譯而之後) 相同，並且儲存在記憶體中，因此只要有需要，瀏覽器就能更快使用。這樣就能預先擷取無法在 HTTP 快取中快取的文件。由於使用 <link rel="prefetch"> 預先擷取文件有問題，建議您往後對這些內容套用推測規則，並將 <link rel="prefetch"> 僅用於預先擷取子資源。

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 的文件規則來判斷使用者與連結的互動。
動態插入的推測規則：可根據應用程式邏輯、與使用者個人化，或根據其他經驗法則來判定。

如果使用以滑鼠懸停或按下連結等動作為基礎的動態插入功能，建議您查看文件規則，因為以往許多程式庫都使用 <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 開發人員工具的偵錯規則專屬文章，瞭解新的 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 會取消預先算繪作業。

日後的版本可能也會允許跨來源網頁預先算繪 (網站會選擇使用類似的 Supports-Loading-Mode: uncredentialed-prerender HTTP 標頭)，並在新分頁中啟用預先算繪功能。

偵測推測規則 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 預先算繪示範。

取消推測規則

移除推測規則會導致預先算繪取消，但屆時已花費的資源很可能已用於啟動預先算繪。因此，如果很有可能需要取消預先算繪，建議不要進行預先算繪。

推測規則和內容安全政策

由於推測規則會使用 <script> 元素，即使元素只包含 JSON，但網站使用雜湊值或 Nonce 時，仍須將這類元素加入 script-src Content-Security-Policy 中。

您可以在 script-src 中新增 inline-speculation-rules，藉此支援從雜湊或非加密指令碼插入的 <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 或 304 的回應代碼)，系統就不會預先轉譯網頁，也會捨棄任何預先擷取網頁。

如果您不希望 Google 預先算繪特定網頁，這是確保不會發生這類情況的最佳方法。不過，為了提供最佳體驗，建議您改為允許預先算繪，但使用 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 欄位來找出自啟用至今「預先算繪」的網頁。

對數據分析的影響

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 whenActivated = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

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

評估效能

評估成效指標時，Analytics (分析) 應考慮根據啟用時間進行評估，而不是根據瀏覽器 API 回報的頁面載入時間。

針對網站體驗核心指標，Chrome 透過 Chrome 使用者體驗報告進行評估，評估的是使用者體驗。因此是以啟用時間為衡量標準。舉例來說，這通常會導致 0 秒的 LCP 值，表示這是改善網站體驗核心指標的好方法。

自 3.1.0 版起，我們更新了 web-vitals 程式庫，以處理預先算繪的導覽，做法與 Chrome 評估網站體驗核心指標的方式相同。如果網頁已完整或部分預先算繪，這個版本也會在 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 提供的縮圖

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

預先算繪的簡短歷史記錄

網頁預先算繪的方式為何？

預先算繪的影響

查看 Chrome 網址列預測

推測規則 API

渴望

預先擷取

Chrome 限制

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

Speculation-Rules HTTP 標頭

推測規則和 SPA

偵錯推測規則

多項推測規則

「No-Vary-Search」支援頁面

推測規則限制和日後推出的強化功能

偵測推測規則 API 支援

透過 JavaScript 動態新增推測規則

取消推測規則

推測規則和內容安全政策

偵測及停用預先算繪

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

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

偵測 JavaScript 中的預先算繪

對數據分析的影響

評估效能

評估預先算繪

評估命中率

對擴充功能的影響

意見回饋：

相關連結

特別銘謝

`Speculation-Rules` HTTP 標頭

「`No-Vary-Search`」支援頁面