以使用者為中心的成效指標

瓦爾頓 (Philip Walton)

我們都聽說成效的重要性。但說到提升網站效能，我們說的具體是什麼？

事實上，效能是相對的：

  • 假設某位使用者 (在裝置效能強大的快速網路中) 都能快速瀏覽網站，但其他使用者操作時的速度可能較為緩慢 (在低階裝置網路中速度較慢)。
  • 兩個網站的載入時間可能在相同的情況下完成，但其中一個網站的載入速度可能「已完成」 (如果以逐步方式載入內容，而不是等到結束後再顯示任何內容)。
  • 網站可能「可以」快速載入，但又回應使用者互動的速度很慢，甚至完全沒有回應。

因此談到效能時，請務必提供精準，並以可量化評估的客觀條件表示成效。這些條件稱為「指標」metrics。

然而，即使指標是以客觀條件為基礎，並且能夠量化評估，並不一定表示這些測量數據非常實用。

定義指標

過去，網站效能是使用 load 事件來評估。不過，雖然 load 是網頁生命週期中明確定義的時刻，但該時刻不一定是使用者關注的任何內容。

舉例來說，伺服器可以在回應中提供最少的網頁回應，隨即「載入」網頁，接著將擷取內容及顯示頁面任何內容，直到 load 事件觸發的數秒為止。雖然這類網頁在技術上可能具有快速的載入時間，但該時間並不一定對應使用者實際體驗網頁載入的情形。

過去幾年來，Chrome 團隊成員不斷與 W3C Web Performance Working Group 合作，攜手將一組新的 API 和指標標準化，以更準確地評估使用者體驗的網頁效能。

為確保指標與使用者息息相關，我們會針對幾個重要問題制定指標：

這是怎麼回事？ 導航是否順利開始？伺服器是否有回應？
這項功能實用嗎？ 是否有足夠的轉譯內容可供使用者進行互動？
是否可用？ 使用者可以與網頁互動，還是忙於瀏覽？
令人開心嗎？ 互動情形是否順暢自然，沒有延遲和卡頓？

指標的評估方式

一般而言，成效指標的評估方式有兩種：

  • 在研究室中：使用工具在一致且受到控管的環境中模擬網頁載入
  • 現場：實際使用者載入網頁並與之互動

這兩種選項都不見得優或更差，因為您通常會想同時使用兩者來確保效能良好。

實驗室

開發新功能時，在研究室中測試效能至關重要。在功能在實際工作環境中發布前，無法評估實際使用者的效能特性，因此在功能發布前於研究室中進行測試，是避免效能迴歸的最佳方法。

在領域

另一方面，雖然在研究室中測試對效能相當合理，但不一定能反映所有使用者在野外的網站體驗。

網站的效能可能會因使用者的裝置功能及網路狀況而有極大差異。但也可能因使用者與網頁的互動 (或方式) 而不同。

此外，網頁載入可能不是很確定的。舉例來說，載入個人化內容或廣告的網站對使用者之間的效能差異可能大不相同。研究室測試無法掌握這些差異。

要確實瞭解網站在使用者體驗上的成效，唯一的方法就是實際評估使用者載入及與網站互動時的效能。這種評估類型通常稱為「真實使用者監控」，簡稱 RUM。

指標的類型

還有幾種其他類型的指標，都與使用者感受到的效能有關。

  • 感知載入速度：網頁載入速度及轉譯所有視覺元素的速度。
  • 載入回應：網頁載入及執行任何必要 JavaScript 程式碼的速度，讓元件能快速回應使用者互動
  • 執行階段回應：頁面載入後，頁面回應使用者互動的速度。
  • 視覺化內容的穩定性：頁面中的元素是否會改變使用者不會預期或乾擾互動的方式？
  • 流暢度：轉換和動畫是否以一致的影格速率算繪，並從一種狀態流暢地算繪？

鑒於上述所有類型的成效指標，我們認為沒有單一指標足以用來擷取網頁的所有效能特性。

需評估的重要指標

雖然這份清單包含評估使用者相關各種效能層面的指標，但並不涵蓋所有項目。舉例來說，目前執行階段回應與流暢度並未涵蓋在內。

在某些情況下，我們會導入新指標來涵蓋遺漏的區域，但在某些情況下，最適合的指標就是專為您的網站量身打造。

自訂指標

上述效能指標有助於大致瞭解網路上大多數網站的效能特性。也很適合建立一組通用指標，以便比較網站與競爭對手的成效。

不過，有時候特定網站可能具有特殊性，就需要使用額外指標才能掌握完整的成效概況。舉例來說，LCP 指標是用來測量網頁主要內容完成載入的時間，但在某些情況下，最大元素並不屬於網頁主要內容，導致 LCP 不相關。

為因應這類情況，網路效能工作小組也已標準化的較低層級 API，可協助您實作自己的自訂指標：

請參閱自訂指標指南，瞭解如何使用這些 API 評估您網站特有的效能特性。