我們都知道成效的重要性，但當我們談論成效，以及讓網站「快速」這件事時，我們具體指的是什麼？
事實上，成效是相對的：
- 某個網站對某位使用者來說可能速度很快 (使用者擁有效能強大的裝置，且連上速度快的網路)，但對另一位使用者來說速度可能很慢 (使用者擁有效能較低的裝置，且連上速度慢的網路)。
- 兩個網站可能在完全相同的時間內完成載入，但其中一個網站可能「看起來」載入速度較快 (如果它是逐漸載入內容，而不是等到載入完成才顯示內容)。
- 網站可能顯示載入速度很快，但在使用者互動時回應速度緩慢 (或完全沒有回應)。
談論成效時，請務必精確表達，並以指標來評估成效。客觀標準可量化評估，但也請務必確保您評估的指標實用。
定義指標
以往，我們是使用 load 事件來評估網站效能。不過，即使 load 是網頁生命週期中明確的時間點，該時間點不一定會與使用者在意的任何事物相符。
舉例來說，伺服器可以回應立即「載入」的簡易網頁，但會延遲擷取內容或顯示網頁上的任何內容，直到 load 事件觸發後的幾秒鐘後才執行。雖然這類網頁的載入時間在技術上算快，但這並非使用者實際體驗的載入時間。
過去幾年，Chrome 團隊成員與 W3C 網頁效能工作小組合作，致力於將一套新的 API 和指標標準化，以便更準確地評估使用者對網頁效能的體驗。
為確保指標與使用者相關，我們會根據以下幾個關鍵問題進行設定：
| 是否發生這種情況？ | 導航是否已順利啟動？伺服器是否已回應？ |
| 是否實用？ | 是否已轉譯足夠的內容，讓使用者可以與之互動？ |
| 是否可用？ | 使用者可以與頁面互動，還是頁面正在忙碌中？ |
| 是否令人愉悅？ | 互動是否流暢自然，沒有延遲？ |
指標的評估方式
成效指標通常會以下列任一方式評估：
- 實驗室：使用工具在一致且受控的環境中模擬網頁載入
- 在實驗室中：針對實際載入網頁並與網頁互動的使用者
這兩種做法都沒有好壞之分，事實上，您通常會同時使用這兩種做法，確保良好的效能。
實驗室
開發新功能時，在實驗室測試效能至關重要。在功能正式發布前，我們無法評估功能對實際使用者的效能特性，因此在功能發布前先在實驗室進行測試，是避免效能退步的最佳方法。
在實地
另一方面，雖然實驗室測試是評估效能的合理替代方案，但不一定能反映實際使用者對網站的體驗。
網站的成效可能會因使用者的裝置功能和網路狀況而有大幅差異。這也可能因使用者是否 (或如何) 與網頁互動而異。
網頁載入作業也不一定會是確定性的。舉例來說，載入個人化內容或廣告的網站，其成效特徵可能會因使用者而異。實驗室測試無法偵測到這些差異。
如要真正瞭解網站對使用者的成效，唯一的方法就是在使用者載入網站並與其互動時，實際評估網站成效。這類評估通常稱為「真人使用者監控 (RUM)」。
指標的類型
還有其他幾種指標與使用者對成效的看法有關。
- 感知載入速度：網頁載入及轉譯所有視覺元素至螢幕的速度。
- 載入回應速度：網頁載入和執行任何必要 JavaScript 程式碼的速度，以便元件快速回應使用者互動
- 執行階段回應速度：網頁載入後，網頁回應使用者互動動作的速度。
- 視覺穩定性：網頁上的元素是否會以使用者不預期的方式移位，並可能干擾使用者互動？
- 流暢度：轉場和動畫是否以一致的幀率算繪，並從一個狀態流暢地轉換到下一個狀態？
在這些成效指標類型中，沒有任何一項指標能完整呈現網頁的所有成效特徵，希望這點已經很清楚了。
需要評估的重要指標
- 首次顯示內容所需時間 (FCP)：測量從網頁開始載入到畫面顯示網頁任何部分內容的時間。(實驗室、實地)
- 最大內容繪製 (LCP)：評估從網頁開始載入到畫面顯示最大文字區塊或圖片元素的時間。(實驗室、實地)
- Interaction to Next Paint (INP)：評估使用者與網頁互動時的延遲時間，包括輕觸、點擊或鍵盤互動，並根據互動次數，選取網頁最糟的互動延遲時間 (或接近最高值)，做為單一代表性值，用來描述網頁的整體回應速度。(實驗室、實地)
- 總封鎖時間 (TBT)：測量首次顯示內容所需時間 (FCP) 和互動準備時間 (TTI) 之間的總時長，於此期間系統會封鎖主執行緒足夠的時間，防止其對輸入內容做出回應。(lab)
- 累計版面配置位移 (CLS)：評估網頁開始載入至其生命週期狀態變更為隱藏期間，所有非預期版面配置位移的累計分數。(實驗室、實地)
- 第一個位元組時間 (TTFB)：評估網路回應使用者請求所需的時間，包括資源的第一個位元組。(實驗室、實地)
在某些情況下，我們會推出新指標來涵蓋缺少的領域，但在其他情況下，最適合的指標則是專為您的網站量身打造。
自訂指標
前面提到的效能指標，有助於您大致瞭解大多數網站的效能特性。這類指標也適合用於設定一組常見指標，讓網站比較自身成效與競爭對手的差異。
不過，有時某些網站可能會在某些方面有所不同，需要額外的指標才能掌握完整的效能狀況。舉例來說，LCP 指標的目的在於評估網頁的主要內容何時載入完畢，但在某些情況下，最大元素可能不是網頁的主要內容，因此 LCP 可能不相關。
為瞭解決這類情況，網頁效能工作小組也將低階 API 標準化，方便您實作自訂指標：
- User Timing API
- Long Tasks API
- Long Animation Frames API
- Element Timing API
- Navigation Timing API
- Resource Timing API
- 伺服器計時
請參閱自訂指標指南，瞭解如何使用這些 API 評估網站的效能特徵。