網站性能指標這麼多，你到底選對了嗎？

• 2019 年 11 月 22 日
• 筆記

為什麼性能重要？

從用戶體驗角度來看一個網址或者app是否有吸引力，75%的人是認為頁面載入時長是一個核心因素，遠遠高於其他影響用戶體驗的問題，例如：簡潔易用、螢幕適配、設計吸引力等等。

性能對於業務而言，也會直接影響到用戶留存、頁面轉化和用戶體驗等等方面。

業界有許多性能直接影響業務的例子：

• Pinterest減少頁面載入時長40%, 提高了搜索和註冊數15%
• BBC頁面載入時長每增加1秒，用戶流失10%
• DoubleClick發現如果移動網站載入時長超過3秒，53%的用戶會放棄

那麼隨著4G的普及、5G的推廣，是不是網站性能就不會成為一個很嚴重的問題呢？畢竟網路速度會得到極大改善，理論上網頁載入的速度也會越來越快，我們是不是就不用過於關注了？

從全球網站的數據來分析，目前的各方面性能數據都不容樂觀

從2011年起，網站的總資源大小PC端增長了314%，移動端增長了1106%，而相應的頁面載入onLoad的時間PC端增長了3.3%，移動端增長了392%。

可以看到過去8年間，雖然網路環境得到了改善，但是由於移動網站的功能也越來越多，所以整體的載入時長其實是大幅度增加的。而且載入時長中位數達到了18.7s，這個對於終端用戶而言幾乎是不可用的狀態。

衡量性能的誤區

If you can』t measure it, you can』t improve it. 彼得·德魯克 現代管理學之父

在衡量性能上往往有幾個誤區：

• 僅僅收集個體數據

對於性能評測，經常會聽到某人說我測試過XX網站，頁面載入時長在X.XX秒。這是一個非常大的誤導，載入時間因用戶而異，具體取決於其設備功能和網路條件。將載入時間顯示為單個數字會忽略經歷更長載入時長的用戶。

實際上，你的應用程式的載入時間是來自每個用戶的所有載入時間的集合，並且完全表示該載入時間的唯一方法是使用如以下直方圖中的分布：

• 關注單一數據

很多團隊都會犯這個錯誤，而且大多數性能檢測工具往往也主要關注頁面載入時長。

但現實是性能問題可能隨時發生，而不僅僅是在載入過程中。對點擊或點擊無法快速響應的應用以及不能平滑滾動或動畫製作的應用可能與載入緩慢的應用一樣糟糕。

同樣，傳統的性能指標（如onLoad或DOMContentLoaded時間）非常不可靠，因為它們發生時可能會或可能不會對應於用戶認為應用程式載入的時間。

基於用戶體驗的性能指標

基於用戶體驗過程的性能指標往往才是關鍵的，一般分為以下幾種體驗：

• 是否在載入：FP/FCP。可以提示給到用戶說明頁面正在載入中，這時候應該頁面從白屏階段變成一些頁面框架。為了提升首屏載入時間可以通過骨架屏的方式，在獲取服務端數據前提前進行頁面渲染。
• 是否內容有用：FMP。一般頁面會有一些核心元素，又稱為Hero元素，例如播放網站，播放器往往就是核心元素，在這個核心元素渲染出現時候才能告訴用戶這個頁面是否對他有價值。為了提升FMP，可以在核心渲染路徑上優先保證核心元素的渲染，後置其他資訊的渲染。
• 是否可以使用：TTI。這時候通常是指頁面可以接受用戶操作響應，頁面載入完成的時間。
• 是否使用流暢：Long Tasks。在用戶使用過程中，例如點擊、滑動等等操作時候，是否能夠保證頁面的及時響應。通常情況下我們需要保證FPS在60以上，這樣用戶不會感受到明顯的遲鈍感，所以單次JS Long Task執行時間需要在 1s/60 = 16ms以內。

百分位線

概念：TP=Top Percentile，Top百分數，是一個統計學裡的術語，與平均數、中位數都是一類。

應用：TP50、TP90和TP99等指標常用於系統性能監控場景，指高於50%、90%、99%等百分線的情況。

在統計性能數據的時候，通常會採用百分位線的方式來統計，而不是採用平均數。因為實際用戶的設備和網路環境千差萬別，實際的頁面載入性能指標會有很大的差異性，為了避免個別極端數據導致整體數據失真，採用百分位線數據是比較合理的。

秒開率

在移動互聯網時代，尤其對於App中的頁面，秒開是一種對於用戶而言最佳的體驗，如果能夠在1秒內載入完成頁面，對於用戶而言他幾乎是可以獲得類似原生的體驗，並且不會有產生太多的焦慮感。

通常而言，可以根據業務情況設定不同的頁面打開的標準，例如：FCP、FMP或者TTI，然後統計在真實用戶數據中，低於1s內的數據佔比即是秒開率。在業界優秀的公司，例如手淘的頁面秒開率基本都達到80%以上。

RAIL模型

RAIL模型也是一個基於用戶體驗的性能衡量標準

Response: 在50ms內處理事件

目標：在100ms內完成用戶輸入啟動的轉換。用戶花費大部分時間等待站點響應他們的輸入，而不是等待站點載入。

Animation：在10ms中生成動畫的下一幀

目標：在10ms或更短的時間內在動畫中生成每個幀。從技術上講，每幀的最大預算為16毫秒（1000毫秒/每秒60幀≈16毫秒），但瀏覽器需要大約6毫秒來渲染每幀，因此每幀10毫秒的準則。

Idle：最大化空閑時間

目標：最大化空閑時間以提高用戶輸入響應時間

Load：在5秒內實現網站完全載入

目標：在首次載入頁面時候，在3G連接速度較慢的中等配置的移動設備上在5秒或更短時間內實現頁面完全載入並且可以進行交互。

數據收集

數據收集分為兩類：實驗室數據和真實用戶數據。實驗室數據往往是在一個可控的內部測試環境中，模擬用戶的操作，通過本地的測試工具獲得相應數據。真實用戶數據就是通過真實數據的採集匯總，用於判斷真實用戶體驗，數據指標較少且不易調試。

實驗室數據

對於實驗室數據的收集，通常會使用Lighthouse和Chrome Devtools。

• Lighthouse：提供關於性能、無障礙化、PWA、SEO等最佳實踐的建議

• Chrom Devtools：提供了一系列開發者工具，針對性能可以很容易的分析網路傳輸、頁面載入、JS執行時間等等數據。

真實用戶數據

2012年W3C制定了Navigation Timing的標準，目前主流的瀏覽器都已經支援，通過window.performance可以獲取頁面載入過程中各個階段的時間點，從而可以採集到真實用戶的性能數據。

一些核心時間可以通過以下時間點進行計算：

• DNS查詢：domainLookupEnd – domainLookupStart
• TCP連接：connectEnd – connectStart
• FP首次渲染：domloading – navigationStart
• TTI（頁面可交互時間）：domInteractive – navigationStart
• DOMReady：domContentLoadedEventEnd – navigationStart
• onload：loadEventEnd – navigationStart

當然還有一些核心指標，例如首屏載入時間、FMP時間等，不太容易直接通過windows.performance獲取得到，這時候可能需要手動打點上傳或者通過特定Dom元素檢測來獲得數據。

總結

性能是非常關鍵而且極其重要的一個功能，在系統設計最初就應該考慮性能指標相關的要求，並且在本地環境進行性能調優的嘗試，同時在系統上線後，不斷收集真實用戶的數據，並且進行持續調優。

性能指標的制定一定要和真實用戶的體驗相關聯，不要僅僅依賴某個單一數據。性能優化的方式多種多樣，首先需要在觀念上認同其重要性，然後在研發全流程制定性能預算、開發規範、模擬調優、線上數據收集、指標運營等等。

用戶體驗優化是一條可以持續精進的道路，選擇合適的性能指標是一個好的開始。