運用 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%」之間的差異。這樣一來,您就可以決定後續工作的優先順序、取得不同相關人員的認同,讓全公司投入提升網站速度。