使用 Signed Exchange 最佳化 LCP

如何評估及最佳化 已簽署的廣告交易平台，以便充分發揮這些平台的效益

已簽署交換 (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 測試的進階設定，因此在此使用這項設定有助於確保測試選項相同)。
• 在「測試設定」分頁中，將「連線」設為 4G，並將「要執行的測試數量」調高至 7。
• 按一下「Start Test」。

使用 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 預先擷取成功，您會看到「with SXG」刊登序列不含 HTML 一列，子資源的擷取作業很快就會啟動。例如比較「之前」和「變更後」：

偵錯

如果 WebPageTest 顯示 SXG 正在預先擷取，表示已在管道的所有步驟中順利完成。建議您跳到「最佳化」部分，瞭解如何進一步改善 LCP。否則，您就必須瞭解管道中的何處失敗，以及原因；請繼續閱讀下文。

發布範圍

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

擴充功能會使用 Accept 要求標頭擷取目前網址，指出其偏好 SXG 版本。如果「Origin」旁邊顯示勾號 (✅)，表示系統傳回 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 會根據 SXG 規格移除 Set-Cookie 標頭。

另一個可能的原因是，出現 Vary: Cookie 回應標頭。Googlebot 不需使用者憑證即可擷取 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：

指向 webpkgcache.com" width="800" height="457">

如果 Google 搜尋認為使用者很可能會點擊搜尋結果，也會預先擷取結果：

適用於 webpkgcache.com" width="800" height="147">

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

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

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

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

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

如果沒有 digest 標頭，可能表示系統沒有向 Googlebot 提供 SXG，或是索引在您啟用 SXG 後尚未更新。

如果 SXG 已成功檢索，但尚未連結，可能是因為不符合 SXG 快取規定。我們將在下一節說明這些內容。

擷取

Google 搜尋將 SXG 編入索引時，會將副本傳送至 Google SXG 快取，根據快取規定進行驗證。這個 Chrome 擴充功能會顯示結果：

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

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

在這種情況下，網頁的運作方式會與啟用 SXG 之前相同。Google 會連結到原始主機上的網頁，而不會使用 SXG 預先擷取功能。

如果快取副本已過期，且正由系統於背景重新擷取，您會看到沙漏 (⌛)：

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

最佳化

如果 SXG Validator Chrome 擴充功能顯示所有勾號 (✅)，就表示您擁有可向使用者提供的 SXG！請繼續閱讀，瞭解如何最佳化網頁，才能從 SXG 獲得最大 LCP 改善成果。

max-age

SXG 過期後，Google SXG 快取會在背景擷取新副本。等待擷取期間，系統會將使用者導向原始主機 (非預先擷取) 的網頁。設定 Cache-Control: max-age 的時間越長，系統進行背景擷取的頻率就越低，因此 LCP 可透過預先擷取減少的頻率也會降低。

我們可以從效能與更新間隔之間權衡，而快取可讓網站擁有者根據各個網頁的特定需求，為 SXG 提供 SXG 上限值，介於 2 分鐘至 7 天之間，結果，我們發現：

• 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 天，讓系統執行 Core Web Vitals (CWV) 匯總作業，然後查看新的 CWV 數據即可。然而，在這段時間內，有時可能無法發現這項變更。

有鑑於此，我發現在載入可能受到影響的網頁時進行「放大」非常實用，並且考量「SXG 影響 X% 的網頁瀏覽量，在第 75 個百分位數改善 LCP 可縮短 Y 毫秒」。

目前，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 (分析)) 中建立兩個自訂維度，並將範圍設為「Hit」，一個命名為「isSXG」，另一個命名為「參照網址」。(內建的「來源」維度設有工作階段範圍，因此不會排除同個網站的瀏覽操作)。

使用下列「AND」運算子建立名為「SXGcounterfactual」的自訂區隔：

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

建立這個區隔的複本，並將其命名為「SXG」(除了 isSXG 與 true 完全相符)，

在網站範本中的 Google Analytics (分析) 程式碼片段上方，加入下列程式碼片段。這是這個特殊語法，ASX 在產生 SXG 時會將 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：

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

按一下「提交」，應該就會看到這兩個區隔的 LCP 分佈情形。這樣就能在 Y 中填入「將 LCP 提升 Y 毫秒的時間，也就是第 75 個百分位數」：

注意事項

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

• 快取失敗：如果 Google SXG 快取沒有特定網址的 SXG 最新副本，系統會將你重新導向至你網站上的原始網址。
• 其他搜尋結果類型：Google 搜尋目前僅支援標準網頁搜尋結果的 SXG，以及其他幾種類型。其他 (例如精選摘要和焦點新聞輪轉介面) 則會連結至你網站的原始網址。
• 不符合資格的網址：如果網站上有部分網頁因不支援 SXG (例如無法快取)，可能就可以出現在這個組合中。

系統在載入 SXG 網頁和載入上述非 SXG 網頁時，可能仍有偏誤，但前者的範圍應該會比「Contemporary 研究」章節」頂端列出的偏誤影響小。舉例來說，您的無法快取網頁可能比可快取網頁慢或慢。如果您認為這可能是問題所在，建議您查看僅限於特定 SXG 網址的資料，確認其結果是否與整體研究相符。

如果你的網站有某些 AMP 網頁，啟用 SXG 後可能就無法獲得效能提升，因為 Google 搜尋已經預先擷取這些網頁。建議您新增篩選器來排除這類網頁，進一步「放大」相關變更。

最後，即使要解決所有選擇偏差，生存偏見仍可能導致 LCP 改善項目看起來像 RUM 統計資料就降低。這篇文章已詳細解釋風險，並建議您查看某種類型的放棄指標，來偵測問題是否發生。

研究前後

如要證實當代研究的結果，建議在啟用 SXG 前後比較 LCP。不要將網頁檢視限制在 SXG 網頁，以消除上述可能的偏誤。請改為查看符合 SXG 資格的結果，即上述區隔定義，但沒有 isSXG 限制。

請注意，Google 搜尋最多可能需要數週的時間，才能重新檢索你網站上的所有網頁，確認這些網頁已啟用 SXG。而這幾週內，則有可能出現其他潛在偏見：

• 新的瀏覽器版本或使用者硬體改善項目，可能會加快頁面載入速度。
• 節慶這類重要事件的流量可能會偏離正常情況。

此外，您也可以查看整體第 75 個百分位數的 LCP，藉此確認上述研究。瞭解一部分人口，未必告訴我們整個人口的統計結構。舉例來說，假設 SXG 讓 10% 的頁面載入量提高了 800 毫秒，

• 如果這些項目的載入時間目前為 10%，則完全不會影響第 75 個百分位數。
• 如果這些程式碼的載入時間最緩慢的 10%，但與第 75 個百分位數的 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 效能有其他建議，歡迎告訴我們！請針對 developer.chrome.com 回報錯誤，並提供您建議改善的項目。

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