使用 Signed Exchange 最佳化 LCP

如何評估及改善 Signed Exchange，以發揮最大效益

Signed Exchange (SXG) 是用來改善網頁速度的方法，主要是最大內容繪製 (LCP)。參照網站 (目前為 Google 搜尋) 連結網頁時，使用者可以在使用者點擊連結前，先預先擷取至瀏覽器快取中。

進行預先擷取作業時，你可以讓網頁不需要在轉譯網頁的重要路徑上任何網路！在 4G 連線上，這個網頁會從 2.8 到 0.9 秒 (剩餘的 0.9 網路主要是依 CPU 使用率)：

現今大多數發布 SXG 的人都是使用 Cloudflare 易於使用的自動 Signed Exchange (ASX) 功能 (但也有開放原始碼選項)：

在許多情況下，勾選啟用此功能的方塊就足以獲得上述的實質改善成果。有時還需要再執行幾個步驟，確保這些 SXG 在管道的每個階段都能正常運作，並將網頁最佳化，以充分利用預先擷取功能。

在 Cloudflare 推出後的幾個月中，我一直在各個 論壇上閱讀及回覆問題，瞭解如何為網站提供建議，確保網站能夠充分運用 SXG 部署作業。此文章是我的建議。我會逐步說明如何：

• 使用 WebPageTest 分析 SXG 效能。
• 如果「分析」步驟顯示無法運作，請對 SXG 管道進行偵錯。
• 針對 SXG 預先擷取將網頁最佳化，包括設定最佳 max-age 以及預先載入會禁止轉譯的子資源。
• 選擇適當的實驗和控制組，使用 Google Analytics (分析) 評估 SXG 的改善幅度。

簡介

SXG 是一個檔案，內含網址、一組 HTTP 回應標頭和回應主體 (皆由 Web PKI 憑證加密簽署)。瀏覽器載入 SXG 時，會驗證下列所有項目：

• SXG 尚未到期。
• 簽章適用於網址、標頭、內文和憑證。
• 憑證有效且與網址相符。

如果驗證失敗，瀏覽器就會捨棄 SXG，改為擷取已簽署的網址。如果驗證成功，瀏覽器會載入已簽署的回應，視為直接來自已簽署的網址。這可讓任何伺服器上重新代管 SXG，前提是該伺服器在簽署後並未過期或經過修改。

對於 Google 搜尋，SXG 會「啟用」預先擷取搜尋結果中的網頁。如果網頁支援 SXG，Google 搜尋可以預先擷取該網頁的快取副本 (由 webpkgcache.com 代管)。這些 webpkgcache.com 網址不會影響網頁顯示或行為，因為瀏覽器會遵循已簽署的原始網址。預先擷取功能可讓網頁載入速度更快。

分析

如要瞭解 SXG 的優點，請先使用研究室工具在可重複的情況下分析 SXG 效能。您可以使用 WebPageTest 比較有/未預先擷取 SXG 的刊登序列和 LCP。

在不使用 SXG 的情況下產生測試，如下所示：

• 前往 WebPageTest 並登入。登入後，系統會儲存您的測試記錄，方便日後比較。
• 輸入要測試的網址。
• 前往「進階設定」。(SXG 測試需要進階設定，因此在此確保測試選項相同)。
• 在「Test Settings」分頁中，將連線設為 4G，並將「要執行的測試數量」增加為 7。
• 按一下「開始測試」。

按照上述步驟使用 SXG 產生測試，但在點選「開始測試」之前，先前往「指令碼」分頁，貼上以下 WebPageTest 指令碼，並依指示修改兩個 navigate 網址：

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

以第一個 navigate 網址來說，如果你的網頁尚未出現在任何 Google 搜尋結果中，你可以使用這個預先擷取網頁，根據這個目的產生實際搜尋結果網頁。

如要判斷第二個 navigate 網址，請使用 SXG Validator Chrome 擴充功能造訪您的網頁，然後按一下擴充功能圖示，即可查看快取網址：

這些測試完成後，請前往「Test History」，選取兩項測試，然後按一下「Compare」：

將 &medianMetric=LCP 附加至比較網址，讓 WebPageTest 針對比較每一側選擇執行中位數 LCP 的執行作業。(預設值為速度指數的中位數)。

如要比較瀑布，請展開「刊登序列不透明度」部分並拖曳滑桿。如要觀看影片，請按一下「調整幻燈片設定」，在該對話方塊中向下捲動，然後按一下「觀看影片」。

如果 SXG 預先擷取成功，您會發現「使用 SXG」刊登序列並不包含 HTML 的資料列，且子資源的擷取作業會更快啟動。舉例來說，在此比較「之前」和「之後」：

偵錯

如果 WebPageTest 顯示 SXG 已預先擷取，表示已在管道的所有步驟中順利完成；您可以跳到「最佳化」部分，瞭解如何進一步改善 LCP。否則，您將需要找出管道中失敗的原因和原因；接著繼續閱讀以瞭解詳情。

發布範圍

確認系統產生了 SXG 網頁。如要這麼做，您必須偽裝成檢索器。最簡單的方法是使用 SXG Validator Chrome 擴充功能：

這項擴充功能會使用 Accept 要求標頭擷取目前的網址，指出它偏好 SXG 版本。如果「來源」旁邊顯示勾號 (✅)，代表傳回 SXG；您可以跳到「索引」部分。

如果看到跨標記 (❌)，表示系統並未傳回 SXG：

如果已啟用 Cloudflare ASX，則交叉標記 (❌) 最有可能是因為快取控制回應標頭造成了限制。ASX 查看含有下列名稱的標頭：

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

如果有任何標頭包含下列任一標頭值，則會造成 SXG 無法產生：

• private
• no-store
• no-cache
• max-age小於 120，除非由 s-maxage 覆寫大於或等於 120

在這種情況下，ASX 不會建立 SXG，因為 SXG 可能會針對多次造訪和多位訪客快取及重複使用。

交叉標記的另一個可能原因 (❌) 是這些有狀態回應標頭 (Set-Cookie 除外) 的其中一個。ASX 會移除 Set-Cookie 標頭，以符合 SXG 規格。

另一個可能的原因是存在 Vary: Cookie 回應標頭。Googlebot 會在沒有使用者憑證的情況下擷取 SXG，並且可能為多個訪客提供這些 SXG。如果您根據不同使用者的 Cookie 提供不同的 HTML，他們可能會看到不正確的體驗，例如未登入的檢視畫面。

或者，你也可以使用 Chrome 擴充功能，例如 curl：

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

或 dump-signedexchange：

dump-signedexchange -verify -uri $URL

如果 SXG 存在且有效，將會看到使用者可理解的 SXG 印出內容。否則系統會顯示錯誤訊息。

建立索引

確認 Google 搜尋已成功將 SXG 建立索引。開啟 Chrome 開發人員工具，然後為您的網頁執行 Google 搜尋。如果 Google 建立了 SXG 索引，Google 的網頁連結就會包含指向 webpkgcache.com 副本的 data-sxg-url：

如果 Google 搜尋判斷使用者可能會點選搜尋結果，也會預先擷取：

<link> 元素會指示瀏覽器將 SXG 下載至其預先擷取快取中。當使用者按一下 <a> 元素時，瀏覽器會使用該快取的 SXG 來轉譯網頁。

您也可以前往開發人員工具的「網路」分頁並搜尋包含 webpkgcache 的網址，查看預先擷取的證據。

如果 <a> 指向 webpkgcache.com，表示 Signed Exchange 的 Google 搜尋索引正在運作。您可以跳至「內容擷取」部分。

否則，可能是因為您啟用 SXG 後，Google 尚未重新檢索您的網頁。請嘗試使用 Google Search Console 網址檢查工具：

出現 digest: mi-sha256-03=... 標頭表示 Google 已成功檢索 SXG 版本。

如果 digest 標頭不存在，這可能表示 SXG 並未提供給 Googlebot，或者自您啟用 SXG 後仍未更新索引。

如果 SXG 成功完成檢索，卻仍未連結至該 SXG，可能是因為無法符合 SXG 快取要求。下節將會詳細說明。

擷取

Google 搜尋為 SXG 建立索引後，會將 SXG 的副本傳送到 Google SXG 快取，然後再根據快取規定進行驗證。Chrome 擴充功能會顯示以下結果：

如果看到勾號 (✅)，可以直接跳到「最佳化」部分。

如果不符合規定，您會看到交叉標記 (❌) 和警告訊息：

在這個事件中，頁面運作方式與啟用 SXG 前相同。Google 會連結到原始主機上的網頁，但不會使用 SXG 預先擷取。

如果快取副本已過期且正在背景重新擷取，您會看到一個沙漏 (⌛)：

此外，SXG 上的 Google 開發人員文件也提供了手動查詢快取的操作說明。

最佳化

如果 SXG 驗證工具 Chrome 擴充功能顯示所有勾號 (✅)，代表你擁有可提供給使用者的 SXG！請繼續閱讀下文，瞭解如何最佳化您的網頁，以達到 SXG 的「最高」LCP。

max-age

當 SXG 過期時，Google SXG 快取會在背景擷取新副本。在等待擷取期間，系統會將使用者導向原始主機上的網頁，而不是預先擷取的網頁。設定 Cache-Control: max-age 的時間越長，這項背景擷取作業發生的頻率就越低，因此預先擷取降低 LCP 的頻率也越高。

這在效能和更新間隔之間有所取捨，快取可讓網站擁有者在 2 分鐘到 7 天之間為 SXG 提供 max-age，以滿足每個網頁的特定需求。我們預期會發現：

• max-age=86400 (1 天) 以上可獲得成效
• max-age=120 (2 分鐘) 沒有

我們深入研究了資料，希望藉此進一步瞭解兩者之間的價值。

user-agent

有一次，我在使用預先擷取的 SXG 時，發現 LCP 增加。我執行了 WebPageTest，比較未啟用和使用 SXG 預先擷取功能而取得的中位數結果。按一下下方的「設定後」：

我看到預先擷取功能運作正常，HTML 會從重要路徑中移除，因此所有子資源都可以提早載入。但 LCP (綠色虛線) 已從 2 秒增加到 2.1 秒。

為找出這個原因，我查看了電影膠捲。我發現這個網頁在 SXG 的轉譯方式不同。在純文字 HTML 中，Chrome 認為 LCP 的「最大元素」是廣告標題。不過，在 SXG 版本中，網頁加入了延遲載入橫幅廣告，將標題推向需捲動位置，並導致新的最大元素變成延遲載入的 Cookie 同意對話方塊。所有轉譯速度比以往更快，但變更版面配置會導致指標回報速度變慢。

我深入探究，發現版面配置會有差異的原因，原因是網頁因 User-Agent 而異，且邏輯中發生錯誤。儘管 SXG 檢索標頭已指示行動版網頁，該網頁還是提供電腦版網頁。問題修正後，瀏覽器再次將網頁標題正確識別為最大的元素。

現在點選「所需時間」後，我發現預先擷取的 LCP 下降至 1.3 秒：

所有板型規格都會啟用 SXG。為了做好準備，請確定符合下列其中一項條件：

• 您的網頁並未在 User-Agent 前Vary (例如網頁使用回應式設計或獨立的行動版/電腦版網址)。
• 如果您的網頁使用動態服務，則會使用 <meta name=supported-media content=...> 自行加註 (適用於行動裝置或電腦)。

子資源

SXG 可用來預先擷取子資源 (包括圖片) 以及 HTML。Cloudflare ASX 會掃描 HTML 中的相同來源 (第一方) <link rel=preload> 元素，並將其轉換為與 SXG 相容的連結標頭。詳情請參閱原始碼和這裡。

如果成功的話，你會看到來自 Google 搜尋的其他預先擷取內容：

如要針對 LCP 進行最佳化，請仔細檢查您的刊登序列，找出轉譯最大元素的關鍵路徑上有哪些資源。如果無法預先擷取，請考慮是否能離開關鍵路徑。請留意會隱藏網頁的指令碼，直到網頁載入完成為止。

Google SXG 快取允許最多 20 個子資源預先載入，且 ASX 會確保未超出此上限。不過，新增過多子資源預先載入項目卻有風險。瀏覽器只會在所有這些項目擷取完畢的情況下，才會使用預先載入的子資源，以便防範跨網站追蹤。網路中的子資源越多，使用者就不太可能在點閱網頁前完成預先擷取作業。

SXG 驗證工具目前不會檢查子資源。在此期間，請使用 curl 或 dump-signedexchange 進行偵錯。

測量

針對 WebPageTest 改善了 LCP 改善措施後，評估 SXG 預先擷取作業對網站整體效能的影響很有幫助。

伺服器端指標

評估伺服器端指標 (例如第一個位元組時間 (TTFB)) 時，請注意，您的網站只會向接受格式的檢索器提供 SXG。將 TTFB 的評估範圍限制為實際使用者 (而非機器人) 發出的要求。產生 SXG 可能會提高檢索器要求的 TTFB，但不會影響訪客體驗。

用戶端指標

SXG 對用戶端指標 (尤其是 LCP) 帶來最快的速度優勢。若要評估這類變數的影響，您可以只啟用 Cloudflare ASX，然後等待 Googlebot 重新檢索程式碼，再等待 28 天，讓網站體驗核心指標 (CWV) 匯總，再查看新的 CWV 數據。然而，這段期間內如有其他變更混用，可能很難看出這項變更。

相反地，我發現對可能受影響的網頁載入「放大」會有幫助，並針對可能受影響的網頁進行「放大」，例如「SXG 會影響 X% 的網頁瀏覽量，並在第 75 個百分位數改善 LCP 效能」。

目前 SXG 預先擷取只會在特定情況下發生：

• Chromium 瀏覽器 (例如 Chrome 或 Edge，但 iOS 版除外) 或 M98 以上版本
• Referer: google.com 或其他 Google 搜尋網域。(請注意，在 Google Analytics (分析) 中，參照連結網址代碼適用於工作階段中的所有網頁瀏覽，而 SXG 預先擷取僅適用於從 Google 搜尋直接連結的第一次網頁瀏覽)。

請參閱暫時研究部分，瞭解如何衡量「網頁瀏覽量的 X%」以及「改善 LCP 縮短 Y 毫秒」。

當代研究

查看實際使用者監控 (RUM) 資料時，您必須將載入頁面分割為 SXG 和非 SXG。這個做法時，請務必限制要查看的網頁組合，這樣非 SXG 端就會符合 SXG 的資格條件，以免選取偏誤。否則，下列所有項目都「只會」存在於非 SXG 網頁載入組合中，而這類 LCP 可能各有差異：

• iOS 裝置：因這些裝置的硬體或網路速度不同。
• 舊版 Chromium 瀏覽器：原因也相同。
• 電腦裝置：基於相同原因，或網頁版面配置會選擇不同的「最大元素」。
• 同網站瀏覽 (訪客點選網站中連結)：因為他們可以重複使用先前載入網頁時快取的子資源。

在 Google Analytics (分析) (通用 Analytics (分析)) 中，使用範圍「命中」建立兩個自訂維度，分別命名為「isSXG」和「參照網址」。(內建的「來源」維度包含工作階段範圍，因此不會排除相同網站瀏覽)。

使用以下篩選器並加上「AND」結合，建立名為「SXGCounterfactual」的自訂區隔：

• referrer開頭是 https://www.google.
• Browser與「Chrome」完全相符
• Browser 版本與規則運算式 ^(9[8-9]|[0-9]{3}) 相符
• isSXG與「false」完全相符

建立名為「SXG」的區隔副本，但 isSXG 必須與 true 完全相符。

將以下程式碼片段加入網站範本的 Google Analytics (分析) 程式碼片段上方。這是一種特殊語法，在產生 SXG 時，ASX 會將 false 變更為 true：

<script data-issxg-var>window.isSXG=false</script>

建議自訂 Google Analytics (分析) 報表指令碼來記錄 LCP。如果您使用的是 gtag.js，請修改 'config' 指令來設定自訂維度 (將 'dimension1' 和 'dimension2' 換成 Google Analytics (分析) 要使用的名稱)：

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

如果您使用 analytics.js，請按照這裡的說明修改 'create' 指令。

等候幾天後，請前往 Google Analytics (分析)「事件」報表，新增 SXG 區隔的細查資料。這樣「SXG 會影響 X% 的網頁瀏覽量」就會填入 X：

最後，前往網站體驗指標報表，依序選取「選擇區隔」>「SXGCounterfactual」和「SXG」。

按一下「提交」，您應該會看到兩個區隔的 LCP 分佈情形。如此應填入 Y 欄「在第 75 個百分位數提高 LCP 效能：Y 毫秒」：

注意事項

套用上述所有篩選器後，SXG 計數器網頁載入時應該包含：

• 快取失敗：如果 Google SXG 快取沒有特定網址的 SXG 最新副本，便會重新導向至網站中的原始網址。
• 其他搜尋結果類型：Google 搜尋目前僅適用於標準網頁搜尋結果和部分其他類型的搜尋結果。而精選摘要和焦點新聞輪轉介面等其他元素則會連結到網站的原始網址。
• 不適用的網址：如果網站上的部分網頁不符合 SXG 的使用資格 (例如因為無法快取)，這些網頁就可能會出現在這個組合中。

SXG 頁面載入量和上述非 SXG 頁面載入之間可能存在其他偏誤，但規模應低於「暫時性研究章節」頂部提到的偏誤。舉例來說，假設無法快取的網頁比可快取的網頁速度較慢或更快。如果您認為這可能是問題所在，建議您查看限定於特定 SXG 網址的資料，看看結果是否與整體研究相符。

如果你的網站含部分 AMP 網頁，SXG 網路擷取內容並不適用於 Google 搜尋，因此在啟用 SXG 後可能無法改善效能。建議您新增篩選器來排除這類網頁，進一步「放大」相關變更。

最後，即使解決所有選擇偏誤，仍有存續偏見的風險，在 RUM 統計資料中看起來像是降級。這篇文章很適合用來說明風險，並建議查看某種形式的放棄指標，以便偵測是否出現這種情況。

研究前後

如要證實這項研究的結果有效，建議您比較啟用 SXG 前後的 LCP。請勿限定 SXG 網頁瀏覽量，以免發生上述偏誤。請改為查看符合 SXG 資格的結果 (即上述區隔定義，但沒有 isSXG 限制)。

請注意，Google 搜尋可能需要幾週的時間重新檢索你網站上的所有網頁，才能找出已啟用 SXG 的網頁。在那幾週內，可能會出現其他潛在的偏誤：

• 新的瀏覽器版本或使用者硬體改善項目可能會加快網頁載入速度。
• 重要事件 (例如假日) 可能會使流量異常。

此外，根據第 75 個百分位數的整體 LCP 研究也有助於確認上述研究，也很有幫助。瞭解部分母體，未必能瞭解整體母體。舉例來說，SXG 可將 10% 的網頁載入提升了 800 毫秒。

• 如果這已經是頁面載入速度最快的 10%，那麼也完全不會影響第 75 個百分位數。
• 假如網頁載入速度最慢的 10%，但比 LCP 開始時速度慢了 800 毫秒，那麼就完全不會影響第 75 個百分位數。

這些是極端例子，可能不足以反映真實情況，但希望能夠說明問題發生。實際上，SXG 很可能會影響大多數網站的第 75 個百分位數。跨網站瀏覽通常是最慢的部分，預先擷取的改善做法往往相當明顯。

選擇不顯示部分網址

最後，與 SXG 效能比較的方法之一，可能是為網站上的部分網址停用 SXG。舉例來說，您可以設定 CDN-Cache-Control: no-store 標頭，防止 Cloudflare ASX 產生 SXG。我們不建議這麼做。

選項偏誤的風險可能比其他研究方法大。舉例來說，無論您將網站首頁或類似熱門網址加入控制組或實驗組，這項差異可能都會有很大的影響。

區隔研究

成效評估的理想方式是進行對照研究。很抱歉，您目前無法執行這類測試。我們預計日後會支援這類測試。

預留研究具有以下屬性：

• 在實驗群組中， SXG 的網頁瀏覽量隨機比例會「保留」並改為非 SXG。如此一來，就能比較對等的使用者、裝置、情境和網頁。
• 在 Analytics (分析) 中，這些保留的網頁 (又稱「反事實實際」) 瀏覽量會加上標籤。如此一來，您就能「放大」資料檢視，我們就可以將控制項中的 SXG 網頁載入與實驗中的 SXG 計數器數據進行比較。進而減少來自其他網頁載入的雜訊，以免 SXG 預先擷取功能受到影響。

這種做法可以消除上述潛在來源偏誤，但這不會影響 LCP 存續偏見的風險。這兩種資源都需要啟用瀏覽器或參照網址才能啟用。

結論

大功告成！可真多。希望這款工具能更全面地說明如何在實驗室測試中測試 SXG 效能，以及如何透過實驗室測試在緊密的意見回饋迴圈中最佳化效能，最後則是在實際環境中評估成效的方式。將上述所有問題整合在一起，有助您充分發揮 SXG 的效益，並確保 SXG 能為您的網站和使用者帶來益處。

如果您對於如何擷取 SXG 效能有其他疑問，歡迎告知我們！對 developer.chrome.com 回報錯誤，並附上建議的改善項目。

如要進一步瞭解 Signed Exchange，請參閱 web.dev 說明文件和 Google 搜尋說明文件。