技术分享｜前端性能 关键性能指标以及测量工具介绍
源寶導讀：對于一款商業軟件產品而言，其性能表現往往會直接關系到它的生死存亡，這種說法一點也不夸張，數據顯示，40％的人放棄了加載時間超過3秒的網站。但是一個網頁的加載時間，響應時間的“快”“慢”衡量方式卻因人而異，難以測量。現在我們來介紹一些，客觀專業的，可以衡量的前端性能關鍵指標以及測量工具。
一、關鍵性能指標以及說明
首先是一組軟件性能對用戶影響的調研數據：
?40％的人放棄了加載時間超過3秒的網站
?47％的消費者希望在2秒或更短的時間內完成網頁加載
?頁面響應時間，每延遲1秒就可以使轉化率降低7％
?當頁面加載時間從1秒增加到3秒時，跳出的概率增加32%
再來一組軟件性能對收益影響的調研數據：
Google搜索延遲400ms導致搜索量下降?0.59%
Bing?延遲?2s導致收入下降?4.3%
Yahoo?延遲?400ms導致流量下降?5-9%
這些直觀的數字，深刻地反映了軟件性能對一款產品能否成功應用的重要影響，所以我們一定要認真對待。
既然我們已經知道了性能的重要性，那如何進行科學的描述與表達呢？在日常的一些交流中，我們通常使用的是一些定性的、感性的表達，例如：
首屏加載速度
用戶操作網頁時的響應速度
網頁響應用戶時的流暢速度
但是這些無法量化，因人而異，無法測量，現在我們來介紹一些，客觀專業的，可以衡量的指標。
1、FCP(First Contentful Paint)
顧名思義，FCP是衡量某個頁面，從開始加載到頁面中第一個元素被渲染之間的時間（元素包含文本、圖片、canvas等）。
這個指標常用來衡量白屏的時間，性能指標如下表所示：
fast | moderate | slow | |
FCP time(s) | 0-2 | 2-4 | >4 |
往往很多頁面會在頁面準備進行JS加載之前，加入Loading或者骨架圖，給用戶更好的體驗。
但是其實這并非是用戶真正想要看到的內容，如何衡量用戶真正想看到內容呢，我們來看看第二個指標。
2、LCP(Largest Contentful Paint) （核心指標之一）
LCP是用來衡量標準視口內可見的最大內容元素的渲染時間（元素包括img、video、div及其他塊級元素）。
這個指標常常用來衡量用戶感知的加載時間，LCP的指標性能如下表所示：
fast | moderate | slow | |
LCP time(s) | 0-2.5 | 2.5-4 | >4 |
我們通過一張圖來了解一下FCP和LCP的關系
在我們日常的項目中，FCP和LCP嘗嘗用來審視頁面首屏加載速度。
但是頁面不僅只是展現首屏， 我們還會進行操作和交互，接下來我們介紹幾個指標 TTI，FID，TBT，來反應頁面加載到操作時的流暢速度和響應速度。
3、TTI（Time to Interactive）
TTI是用來測量頁面所有資源加載成功并能夠可靠地快速響應用戶輸入的時間。
他的意義很好理解，但是他的測量方式就會比較麻煩，必須要滿足以下幾個條件：
從 FCP 指標后開始計算
持續 5 秒內無長任務（執行時間超過 50 ms）且無兩個以上正在進行中的 GET 請求
往前回溯至 5 秒前的最后一個長任務結束的時間
4、FID(First Input Delay) (核心指標之一)
FID是測量從用戶第一次與頁面交互的時間到瀏覽器實際上能夠響應這種交互的時間。交互包括用戶點擊一個鏈接或者一個按鈕等。
這個指標比較好理解，用戶交互事件觸發到頁面響應中間耗費了多長時間，這個指標也就是我們說的響應速度和流暢速度。
fast | moderate | slow | |
FID time(ms) | <100ms | 100-300ms | >300ms |
5、TBT（Total Blocking Time）
TBT其實也是字面意思，衡量從FCP到TTI之間主線程被阻塞時長的總和。
但是大家可能會有疑問，因為JS本身是單線程的，什么才是被阻塞呢？
其實在我們介紹TTI的時候已經介紹過，JS有一個長任務的概念，我們把執行時間>50ms的任務稱為長任務，那么每個任務超過50ms的部分就是他的阻塞時間。
TBT就是阻塞時間的總和，舉例子，如果在FCP和TTI之間進行了3個長任務，分別為 60ms 100ms 200ms
那么我們TBT 則等于 (60-50)+(100-50)+(200-50) =?210 ms
這個指標并非直接體現性能，但是他是我們去優化FID的重要依據。
我們現在了解和如何評估頁面的加載速度，響應速度和流程程度。
但是大家在開發過程中可能還會有一種情況，比如：
頁面內容已經加載完，但是樣式還沒有加載完成，那么等待樣式加載完成，會出現文檔"跳躍"的情況。
圖片沒有設置寬度和高度，當圖片比較大的時候，圖片突然加載后，整個頁面也會出現布局的"波動"
這樣的"波動"和"跳躍"其實都顯示的是頁面的不穩定，所以我們再來了解一個指標：CLS
6、CLS（Cumulative Layout Shift）（關鍵指標）
CLS代表著累計位移偏移，記錄了頁面上非預期的位移波動，主要通過位移影響的面積和位移距離來計算。
比如頁面渲染過程中突然插入一張巨大的圖片導致其他元素發生偏移等，這個也是相當影響用戶體驗的內容。
如上圖所示，我們計算方式是
移動距離 = 20%?
影響面積 = 45% 前后總共影響的屏幕面積
那么 CLS 為? 0.2 * 0.45 = 0.09
CLS的指標如下表所示：
GOOD | NEEDS | POOR | |
CLS number | <0.1 | 0.1-0.25 | >0.25 |
到這里我們已經了解了很多指標
如何去衡量頁面加載速度：FCP、LCP
如何去衡量頁面的操作流暢度：FID、TTI、TBT
如何去衡量頁面的視覺穩定程度：CLS
但是在我們日常的關注性能的時候，只需要死磕最重要的三個核心指標，他們往往是影響頁面感知性能的最關鍵點。
二、常見指標檢測工具及使用方法簡介
1、通過谷歌瀏覽器的Performance來錄制頁面的指標
我們的老朋友，Chrome的DevTools
我們切換到Performace中，點擊左上角的就可以開始錄制。
但是值的注意是的，因為目前電腦的CPU和手機的CPU還是無法比較。
當我們想要去錄制手機性能時，需要點擊配置，把CPU降速4倍（選擇4x slowdown）才可以更好模擬手機的運行效果，這樣我們可以不被電腦的"高性能"蒙騙。
2、重要的性能優化好幫手：Lighthouse
同樣谷歌DevTools自帶Lighthouse 可以快速生成一個報告。
但是也更加推薦使用?lighthouse?使用NPM安裝并且通過命令行生成。
通過命令行生成的有2個好出，一是可以把每次報告保存下來，二是可以自動化定期檢測性能和發現問題。
通過Lighthouse生成出來的報告如下圖：
不僅僅可以給出詳細的報告，并且還給了非常多的優化建議和優化路徑，這個也是我們做性能優化的最重要的工具
最重要的是Lighthouse 給出的所有建議，都非常重要和直觀。
3、如果你希望在JS中獲取這些指標
你可以使用：web-vitals
這樣我們可以自己去獲取每個用戶在真實情況中的指標，并且上報到服務端記錄下來，作為我們性能優化的依據和素材。
4、在線化報告生成，更加接近真機效果??www.webpagetest.org
webpagetest可以生成詳細的報告，也可以自己部署鏡像去生成，并且所有的手機端是在真機下運行的。
也有非常詳細的指標甚至整個渲染過程的視頻
相比Lighthouse 那么webpagetest則更像是輔助你分析性能的工具，可以展現給你所有的數據，等待著你去挖掘如何優化。
不過因為webpagetest是在線化的，所以在使用的時候需要科學上網，在高峰時期甚至還需要排隊生成報告。
三、總結
針對商業軟件產品而言，其性能表現往往會直接關系到它的生死存亡。
本次我們了解了性能優化的常見指標，以及他們的計算方式，同時我們也推薦了如何用工具去獲得這些指標。
這些指標相當于是前端性能優化系列的入門課程，在后續的分享中，會分享如何優化這些指標已經如何在項目中落地。
小伙伴們是否等不及用這個工具去測試一下自己產品的前端性能呢。?
?
------ END ------
作者簡介
劉同學：?開發SM，目前負責數據分析平臺相關開發工作。
總結
以上是生活随笔為你收集整理的技术分享｜前端性能 关键性能指标以及测量工具介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GraphQL 到底有什么魔力？
- 下一篇： 在.Net环境下使用elasticsea