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

Philip Walton

我們都知道成效有多重要。但對效能來說，所謂的「快速」網站，到底是指什麼？

事實上，成效是相對的：

  • 對單一使用者來說，網站速度快 (例如裝置速度飛快，且裝置速度飛快)，但另一位使用者 (如果網路速度緩慢，而低階裝置) 的速度可能較慢。
  • 兩個網站可在相同時間內完成載入，但其中一個網站可能「會」更快載入內容，而不是等到畫面結束再顯示任何內容。
  • 網站可能會「看起來」快速載入，但隨後對使用者互動的回應速度很慢 (甚至完全不回應)。

談論成效時，請務必設定精確，並提及 指標的成效。可以量化的目標條件 但同樣重要的是確保您要評估的指標 很實用

定義指標

以往，使用 load 事件評估網站效能。不過，即使 load 是頁面生命週期中定義明確的時刻，但該時刻不一定與使用者關注的內容對應。

例如，伺服器可能以最低限度「載入」的網頁回應則會延遲擷取內容或顯示頁面上任何內容，直到 load 事件觸發的幾秒後為止。就技術層面而言，這類網頁的載入時間較短，但該時間與使用者實際載入網頁的方式不同。

Chrome 團隊在過去幾年間與 W3C Web Performance Working Group 合作，致力將一組新的 API 和指標標準化，以便更準確地評估網頁效能。

為了確保指標與使用者切身相關，我們會根據幾個關鍵問題構思：

這是發生的情況嗎？ 導覽是否順利啟動？伺服器是否有回應？
這項功能實用嗎？ 內容是否足夠讓使用者與時互動？
是否可用？ 使用者可以與網頁互動，還是過於忙碌？
覺得有趣嗎？ 互動是否流暢自然，沒有延遲？

指標的評估方式

一般來說，成效指標的評估方式有以下兩種：

  • 在研究室中：在控管的一致環境中使用工具模擬網頁載入
  • 在領域：實際載入網頁並進行互動的使用者

這兩種方式的效果可能都優於其他選項；事實上，為確保良好成效，您通常會希望兩者搭配使用。

實驗室

在開發新功能時，務必在研究室中測試效能非常重要。在功能發布正式版前，無法評估實際使用者的效能特性，因此在功能發布前於研究室中測試，是避免效能迴歸的最佳做法。

實地

另一方面，雖然在研究室中測試是提升成效的合理指標，但不一定能反映使用者實際的網站體驗。

視使用者的裝置功能和網路狀況而定，網站的效能可能會有極大差異。這個指標也可能因為使用者與網頁互動的方式 (或方式) 而異。

網頁載入也不一定具有確定性。舉例來說，網站如果載入個人化內容或廣告，在不同的使用者成效方面可能會有極大差異。研究室測試不會擷取這些差異。

想要真正瞭解網站對使用者的成效，唯一的方法就是在使用者載入並與網站互動時實際評估網站效能。這類評估方式通常稱為即時使用者監控 (RUM)。

指標的類型

另外還有幾種指標與使用者感知成效相關，

  • 感知的載入速度：網頁能有多快載入網頁並顯示所有視覺元素到螢幕上。
  • 載入速度：網頁載入速度：網頁能載入並執行任何必要的 JavaScript 程式碼，讓元件能快速回應使用者互動
  • 執行階段回應速度：網頁載入後，網頁回應使用者互動的速度。
  • 視覺穩定性：網頁上的元素是否會以使用者非預期的方式改變，並有可能幹擾使用者與他們的互動？
  • 流暢度：轉場效果和動畫是否以一致的影格速率和流動方式流暢地從一種狀態轉換到下一個狀態？

相信有鑑於上述所有成效指標，我們預期沒有任何單一指標足以代表網頁的所有成效特性。

需要評估的重要指標

在某些情況下，我們會推出新指標來涵蓋遺漏的部分，但在其他情況下，最佳指標則是特別針對您的網站量身打造的。

自訂指標

藉由本文介紹的成效指標，您可以大致瞭解網路上大多數網站的成效特性。此外，這項工具也適合擁有一組常用網站指標，用來比較自家網站與競爭對手的成效。

不過，網站有時會有特殊狀況，就需要另外指標才能掌握整體成效。例如，LCP 指標可用來評估網頁的主要內容載入完成的時間，但有時最大的元素並不屬於網頁的主要內容，因此 LCP 可能不相關。

為解決這類情況，Web Performance Working Group 也已經將低階 API 標準化，方便您實作自己的自訂指標：

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