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

爲何性能重要？

從用戶體驗角度來看一個網址或者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

總結

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

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

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

有興趣同窗能夠關注微信公衆號奶爸碼農，分享關於投資、理財、IT的信息：