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

瀏覽器支援

  • Chrome:109。
  • Edge:109。
  • Firefox:不支援。
  • Safari:不支援。

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

預先轉譯簡史

在過去,Chrome 支援 <link rel="prerender" href="/next-page"> 資源提示,但除了 Chrome 以外,這也沒有廣泛支援,而且它的 API 並不是十分說明性的 API。

這個使用連結 rel=prerender 提示的舊版預先算繪功能已淘汰,改為使用 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,並強化開發人員工具功能,以便更輕鬆地找出這類極端情況。

預先算繪的影響

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

預先算繪的影響範例。

範例網站已有快速瀏覽的網站,但您可以瞭解預先轉譯機制如何改善使用者體驗。因此,這也會直接影響網站的網站體驗核心指標,LCP 幾乎為零,CLS 減少 (因為任何載入 CLS 都會發生在初始檢視之前),以及 INP 改善 (因為載入作業應在使用者互動前完成)。

即使網頁在完全載入前就啟動,即使開始載入網頁,仍然可以改善載入體驗。如果在預先算繪期間啟用連結,系統會將預先算繪頁面移至主要框架,並繼續載入。

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

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

查看 Chrome 網址列的預測結果

如果是第一種用途,您可以前往 chrome://predictors 頁面查看 Chrome 的網址預測查詢字串:

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

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

這張螢幕截圖是在較新的 Chrome 安裝過程中擷取的,並篩除了零信賴預測資料。不過,假如您查看自己的預測器,可能會得到較多項目,甚至需要更多字元才能達到高信賴水準。

這些預測工具也是您在網址列中或許已註意到的建議選項:

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

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 團隊已準備好推測規則程式碼研究室,將逐步引導您在網站中新增推測規則。

熱力

瀏覽器支援

  • Chrome:121。
  • Edge:121。
  • Firefox:不支援。
  • Safari:不支援。

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

  • immediate用於盡快推測,亦即發現推測規則時就開始推測。
  • eager這與 immediate 設定的運作方式相同,但我們日後會想將這項作業放在 immediatemoderate 之間。
  • moderate如果您將游標懸停在連結上 200 毫秒 (或發生 pointerdown 事件,以較快者為準,在行動裝置上沒有 hover 事件),就會執行推測。
  • conservative在點下游標或觸碰時推測。

list 規則的預設 eagernessimmediate。您可以使用 moderateconservative 選項,將 list 規則限制為僅和使用者與特定清單互動的網址。不過,在許多情況下,搭配適當 where 條件的 document 規則可能會更合適。

document 規則的預設 eagernessconservative。由於文件可能包含多個網址,因此請謹慎使用 immediateeagerdocument 規則 (另請參閱下方的「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:

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

moderateconservative 設定 (取決於使用者互動) 的運作方式為首次使用 (FIFO):達到上限後,系統會取消最舊的推測結果,並替換為新的推測結果,以節省記憶體。取消的推測作業可以再次觸發,例如再次將滑鼠游標懸停在該連結上,這會導致該網址重新推測,並推送最舊的推測。在這種情況下,先前的推測會在網址的 HTTP 快取中快取任何可快取資源,這樣日後進行推測時的費用應該就會比較低。因此,這項限制已設為 2 的適度門檻。靜態清單規則不會因使用者操作而觸發,因此瀏覽器無法得知哪些規則需要執行,也無法得知何時需要執行,因此上限較高。

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

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

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

此外,Chrome 在啟用前,也不會在預先算繪的頁面上顯示跨來源 iframe。

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

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

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

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

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

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

Speculation-Rules HTTP 標頭

瀏覽器支援

  • Chrome:121。
  • Edge:121。
  • Firefox:不支援。
  • Safari:不支援。

資料來源

您也可以使用 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.htmltwo.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>

瀏覽器支援

  • Chrome:121。
  • Edge:121。
  • Firefox:不支援。
  • Safari:不支援。

資料來源

預先載入或預先算繪網頁時,某些網址參數 (技術上稱為「搜尋參數」) 可能對伺服器實際提供的網頁不重要,且只供用戶端 JavaScript 使用。

舉例來說,Google Analytics 會使用 Urchin 流量監視器 (UTM) 參數來評估廣告活動,但通常不會導致伺服器傳送不同的網頁。這表示 page1.html?utm_content=123page1.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 123124 相同。不過,最終的網頁內容會因用戶端算繪而有所不同,因為用戶端會使用 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,但仍會嘗試預先載入,這會導致預先載入作業浪費資源,需要重新傳送,或更糟糕的是,導致錯誤的網頁載入。

針對 Service Worker 控管的網頁,不支援預先擷取功能。我們正在努力提供這項支援。請關注這篇支援服務 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」面板來新增 <script type = "speculationrules"> 元素,並不會註冊推測規則。相反地,必須從控制台執行用於動態新增此元素至 DOM 的腳本,才能插入規則。

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

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

在 Google 代碼管理工具中設定自訂 HTML 代碼
透過 Google 代碼管理工具新增推測規則。

請注意,這個範例使用 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://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。網頁可以使用這個屬性,在預先算繪期間防止或延遲特定活動,直到網頁實際啟動為止。

一旦預先算繪文件啟用,PerformanceNavigationTimingactivationStart 也會設為非零時間,代表從開始預先算繪到實際啟用文件之間的時間。

您可以使用函式檢查預先顯示預先顯示的頁面,如下所示:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

如要查看網頁是否已預先算繪 (全部或部分),最簡單的方法是在網頁啟用後開啟開發人員工具,然後在控制台中輸入 performance.getEntriesByType('navigation')[0].activationStart。如果傳回的值不為零,表示頁面已預先轉譯:

Chrome 開發人員工具中的主控台顯示正值 activationStart,表示網頁已預先算繪
在控制台中測試預先算繪。

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

透過這些 API,前端 JavaScript 即可偵測出適當的預先算繪頁面並採取行動。

對數據分析的影響

Analytics 能評估網站使用情形,例如使用 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.prerenderingprerenderingchange 來指定預先顯示頁面。

在預先算繪期間保留其他內容

您可以使用先前討論過的相同 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 秒,展示這能有效改善 Core Web Vitals。

自 3.1.0 版起,web-vitals 程式庫已更新,以便以 Chrome 評估 Core Web Vitals 的方式處理預先算繪的導覽。如果網頁已完全或部分預先呈現,這個版本也會在 Metric.navigationType 屬性中,為這些指標標示預先算繪的導覽。

評估預先算繪作業

您可以透過 PerformanceNavigationTimingactivationStart 項目是否為非零值,判斷網頁是否已預先算繪。這樣就能使用自訂維度記錄這項資訊,或是在記錄網頁瀏覽時以類似方式記錄 (例如使用先前提到的 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 後的成果,並與您分享相關案例。

特別銘謝

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