運用 A/B 測試評估網站速度對業務指標的影響。
過去幾年來，我們確認網站速度效能是決定使用者體驗的重要一環，因此改善網站速度對各種業務指標 (例如轉換率和跳出率) 有益。為因應上述情況，我們也發布了多項文章和個案研究，包括 Cloudflare 的 網站效能如何影響轉換率、Deloitte 的 Milliseconds Make Millions 和 Shopping for Speed on eBay.com 等等。
即使速度顯然明確，許多公司仍難以優先採取能改善網站速度的工作，因為他們不知道這對「使用者」使用者有何影響，進而帶動「自家」業務成長。
如果沒有資料，可以輕鬆延遲網站速度工作，並專心處理其他工作。常見的情況是，某些公司人員已經意識到網站速度的重要性，卻無法建構支援案例，並說服多位相關人員據此進行投資。
本文提供高階指南，說明如何利用 A/B 測試評估網站速度對業務指標的影響，以更有效率的方式製定決策。
步驟 1：選擇要進行 A/B 測試的網頁
您的目標是測試網頁速度是否與業務指標相關。為了方便起見，您可以先限定自己只為了分析一個網頁而設。未來工作可能會展開至多個相同類型的多個網頁，以確認發現項目，然後移至網站的其他部分。您會在這個步驟底部看到一些如何著手的建議。頁面選取程序有以下幾個條件：
- A/B 版本測試只能在行動裝置使用者的裝置上執行。以全球而言，我們輔助的合作夥伴網站平均有超過 50% (而且持續增加！) 的流量來自行動裝置，但這可能會因為區域和產業而顯著增加。由於處理程序和記憶體的限制，且網路穩定性較低，因此行動裝置對速度較慢的網站比較敏感。此外，隨時隨地使用模式 意味著對速度的期望也更高
您選擇測試的網頁應該是轉換漏斗的重要環節。每個網站的用途各有不同，因此每個網站追蹤的成效指標都不同。這些指標通常與使用漏斗分析的使用者歷程相關。舉例來說，電子商務網站上的使用者必須在首頁、類別頁面、產品頁面和結帳頁面完成購物。如果您要爭取轉換，其中一個頁面就是最佳選擇。
網頁僅有單一用途。除非網站有非常具體的目標，否則最好避免使用首頁進行測試。許多商業網站的首頁都是提供各式功能的入口網站，讓分析工作變得雜訊。舉例來說，如果您最佳化新聞網站的單次工作階段瀏覽量，最好排除網站的非商業部分，只著重營利版面和文章。
所選頁面應已取得足夠的流量，因此您無須等待一段時間，就能取得具有統計顯著性的結果。
所選網頁的速度必須相對慢。事實上，速度越慢越好。 這不代表您可以更輕鬆地改善網頁，也意味著資料應該更加清楚。您可以透過 Google Analytics (分析) 速度報表或 Search Console 網站體驗核心指標報表快速掃描，找出速度最慢的網頁。
網頁應該要相對穩定。在測試完成前，請勿更新網頁 (任何會影響業務指標的頁面)。需要考量的外部因素越少，分析結果就越簡潔。
按照上述說明操作，應更清楚地瞭解哪些網頁適合進行測試。廣告到達網頁也是不錯的選擇，因為您可能已有內建的業務指標、A/B 測試和分析。如果你還是不確定，以下為各產業的幾種建議：
- 內容網站：版面、文章
- 店面：類別網頁、產品網頁
- 媒體播放器：影片探索/搜尋網頁、影片播放網頁
- 服務與探索 (旅遊、租車、服務註冊等)：初始表單輸入頁面
步驟 2：評估成效
測量指標的一般方法有兩種：在研究室和實際應用。我們個人發現，評估實境指標 (也稱為 Real User Monitoring (RUM)) 中的指標會更加實用，因為其能反映實際使用者的體驗。可協助您回報 RUM 資料的程式庫和服務包括 Perfume、Firebase 效能監控和 Google Analytics (分析) 事件。
有許多指標可以選擇，因為這些指標的目標是擷取使用者體驗的不同面向。請記住，您的目標是最終確定您的速度和業務指標之間是否存在直接相關性，所以建議您追蹤一些速度指標，以判斷哪一個指標最符合您的業務績效。通常建議從 Core Web Vitals 開始。web-vitals.js 程式庫可協助您評估欄位中的部分網站體驗核心指標，但請注意，瀏覽器並非完全支援。 除了網站體驗核心指標之外，我們還值得瞭解其他網站體驗指標。您也可以定義自訂指標，例如「最初廣告點擊時間」。
步驟 3：建立速度效能變化版本
在這個階段，您將實作變更，建立更快速的測試網頁版本，並與目前版本進行比較。
注意事項：
- 避免對使用者介面或使用者體驗做出任何變更，除了單一網頁的速度加快，也必須讓使用者無法察覺。
- 評估也是這個階段的重要一環。在開發過程中，您應使用 Lighthouse 等研究室測試工具，顯示變更對效能的影響。請注意，更改某個指標通常會影響另一項。網頁上線後，請持續使用 RUM 以獲得更準確的評估。
建立效能變化版本的方法有很多種。針對測試，希望您盡可能盡量簡單。以下是幾個選項。
建立速度更快的頁面
- 使用 Squoosh 等工具，手動最佳化測試頁面上的圖片
- 使用開發人員工具的程式碼覆蓋，手動移除該網頁中未使用的 JavaScript 或 CSS
- 有效率地載入第三方指令碼
- 請使用 Critical 等工具 細分並內嵌重要的 CSS
- 移除不影響使用者體驗的非重要 JavaScript 程式碼，以及無需測試即可進行的操作 (例如某些第三方程式庫)
- 實作瀏覽器層級延遲載入，因為部分瀏覽器並未支援此功能，但仍有可能大幅改善效能 (如果支援的話)
- 移除不重要的 Analytics (分析) 代碼或以非同步方式載入這些代碼
如要瞭解其他值得考量的最佳化項目，請參閱快速載入時間和前端效能檢查清單。您也可以使用 PageSpeed Insights 執行 Lighthouse，找出可改善效能的機會。
放慢網頁速度
這可能是建立變化版本最簡單的方法，可以透過新增簡單的指令碼、減緩伺服器回應時間、載入較大的圖片等方式達成。《金融時報》在測試效能對業務指標的影響時，選擇採用此選項：請參閱更快速的 FT.com。
加快網頁載入速度
如果測試頁面 (例如產品詳細資料頁面) 大多從其他網頁 (例如首頁) 連結，那麼直接從測試群組的首頁預先擷取或預先算繪產品頁面，將加快之後的網頁載入速度。請注意，在這種情況下，A/B 版本測試分割 (步驟 4) 是在首頁完成。此外，這些方法都可能會使第一頁的速度變慢，因此在分析測試結果 (步驟 5) 時，請務必評估這一點，並將此因素納入考量。
步驟 4：建立 A/B 版本測試
如果同一個網頁有兩個版本，其中一個版本較快，下一步就是拆分流量來評估影響。一般來說，執行 A/B 測試的技術和工具有很多，但請注意，並非所有方法都適合評估速度效能影響。
如果您使用最佳化工具或最佳化工具等 A/B 測試工具，強烈建議您設定伺服器端測試 (而非用戶端測試)，因為用戶端 A/B 測試通常需要隱藏網頁內容，直到載入實驗為止，這也意味著 A/B 測試本身會使您想評估的指標產生偏差。如果您只能進行用戶端測試，建議您在另一個網頁上設定實驗，並將測試網頁的連結改為導向測試頁，以便拆分流量。這樣一來，測試頁面本身就不會遭到用戶端測試向下拖曳。
透過伺服器端測試，特定產品詳細資料頁面 (PDP) 上的 AB 測試效能變化示例：
要求會傳送至後端，將使用者分配至網頁的兩個不同版本。雖然一般是良好的設定，但通常需要 IT 資源才能設定伺服器端分割。
以下是用戶端測試設定範例，使用上一頁 (下圖中的首頁) 執行測試 JavaScript：
測試 JavaScript 會操縱出站連結，提供兩個測試群組的使用者連結，讓他們連結至對應的兩個 PDP 版本。這種方式可透過最佳化工具或最佳化工具等常見的 A/B 測試工具輕鬆設定及維護，而且不會影響效能測試，因為測試 JavaScript 會在其他網頁上執行。
或者，您也可以挑選兩個網頁行為和執行方式非常相似的網頁 (例如，假設有兩個非常相似的產品)。將變更套用至其中一個變更，然後比較指標在一段時間內的差異。這表示您使用的 A/B 版本並未經過適當測試，但還是能取得許多深入分析結果。
如果您的測試網頁做為廣告活動的到達網頁，您可以使用廣告聯播網內建的 A/B 測試工具，例如 Facebook 廣告分割測試或 Google Ads 草稿與實驗。如果無法採用這個選項，您可以採用兩個採用相同設定的廣告活動，並將不同的到達網頁設為指定目標。
步驟 5：分析 A/B 版本測試
如果測試時間已夠長，且有足夠的資料可供辨識結果，就可以開始彙整測試並執行分析。實際做法取決於測試的執行方式，因此讓我們來看看其他選項。
如果使用上述工具在廣告到達網頁上執行測試，分析應像讀取結果一樣簡單。如果您使用 Google 的「草稿與實驗」，請使用 ScoreCard 查看比較結果。
最佳化工具或最佳化工具等平台也提供簡單易懂的方式，可用來解讀結果，並判斷網頁載入速度對網頁的影響程度。
如果您使用 Google Analytics (分析) 或類似工具，就必須自行彙整報表。幸好，Google Analytics (分析) 可讓您輕鬆建立自訂報表，從此開始。如果您已使用自訂維度將速度資料傳送至 Google Analytics (分析)，請參閱報表指南瞭解設定方法，並將其納入自訂報表中。請確認您的報表涵蓋實驗日期，且設定為顯示兩個變化版本。這份報表應包含哪些內容？
- 主要是，您必須加入您最重視的業務指標：轉換、網頁瀏覽、廣告觀看次數、轉換率、電子商務指標、點閱率等等。
- 此外，也有助於改善網站速度的標準網頁指標包括跳出率、平均工作階段持續時間和離開百分比。
您可能也需要篩選行動裝置，並務必排除漫遊器和其他非使用者流量。更進階的分析功能也會依照地區、網路、裝置、流量來源、使用者個人資料及類型 (例如新使用者與回訪訪客) 進行篩選。一群使用者對於速度較慢或較不敏感，辨識出這些問題也非常實用。
Looker Studio (舊稱「數據分析」) 或其他資料視覺化工具，可讓您輕鬆整合各種資料來源，包括 Google Analytics (分析)。這不但可以輕鬆進行分析，也能建立資訊主頁，並與許多參與現代網站相關人士的相關人員共用，方便他們進一步購買。舉例來說，《監護人建立了自動化快訊系統》，在最近發布的內容超過頁面大小或速度門檻時警告編輯團隊，並可能招致使用者不滿意。
步驟 6：做出結論並決定後續步驟
當您取得結合效能和業務指標的資料後，就可以檢視結果並開始得出結論。
如果您可以清楚看到改善效能和改善業務指標之間的關聯，請總結結果，並在公司內部進行回報。現在，以「商業語言」討論速度成效後，就越有可能吸引不同的相關人員注意，並將網站速度納入考量。下一步是依據結果設定效能預算，並規劃工作來達成這些預算。由於您知道這類工作將帶來價值，因此能據此決定優先順序。
如果無法找出相關性，請查看下方注意事項，並評估是否應在網站的其他位置執行類似的測試，例如完成整個購物程序或在其他類型的網頁。
注意事項
如果沒有發現網站速度指標和業務指標之間具顯著關聯的原因，可能是由以下原因造成：
- 所選頁面對您要查看的業務指標沒有足夠影響。舉例來說，如果結帳頁面不容易使用或速度過慢，速度較快的產品網頁就不會大幅影響轉換率。建議您查看較具關聯性的指標，例如跳出率、加入購物車比率，或是與測試網頁更直接相關的任何其他指標。
- 兩個版本之間的速度差異不夠顯著。這項評估作業的依據為您所評估的 RUM 指標。
- A/B 測試機制發生問題。流量可能無法正確分配，或是未正確回報分析資料。為瞭解決這個問題，建議您執行 A/A 測試，以相同的測試機制測試同一個網頁版本，確保執行結果不會有任何差異。
- 網站速度對業務指標沒有影響。這種情況很少見，但在目標市場較不對速度敏感的情況下 (例如網站大多透過高強度網路中的強大裝置存取)，或者使用者需求極高，而且選擇有限 (例如專門販售熱門節目門票的售票服務)。請注意，這不代表網站速度較快無法改善使用者體驗，進而影響品牌信譽。
結論
雖然您想要在整個網站上執行速度最佳化，但長期下來，若能先瞭解提升網站速度對使用者和公司所代表的意義，會更有幫助。這裡指的是「我們將 FCP 改善 1.5 秒」和「我們將 FCP 改善 1.5 秒，並將轉換率提高 5%」之間的差異。這樣一來，您就可以決定後續工作的優先順序、取得不同相關人員的認同，讓全公司投入提升網站速度。