Web性能評價(jià)指標(biāo)

作者：Thoughtworks洞見 2023-03-30 19:28:51

談?wù)撔阅埽匾氖蔷_，并且根據(jù)能夠進(jìn)行定量測量的客觀標(biāo)準(zhǔn)來論及性能。通過什么信息來分析系統(tǒng)性能，如何判定好壞？Google提供了思考性能問題的方法論，以用戶為中心的性能模型 - RAIL。

作者 | 李玲

同一個(gè)網(wǎng)站，有的用戶說好用，有的用戶投訴慢，Web性能差嗎？

從用戶角度出發(fā)，收集用戶的使用反饋，很多吐槽都提到了慢，經(jīng)調(diào)研用戶最關(guān)注的是速度，所以Web性能主要指網(wǎng)站加載、響應(yīng)速度。它包括客觀的指標(biāo)和用戶在訪問應(yīng)用時(shí)所感受到的性能情況。主觀的用戶性能感知受到用戶設(shè)備、網(wǎng)速快慢和用戶的主觀感受影響，導(dǎo)致性能是相對的。

而談?wù)撔阅埽匾氖蔷_，并且根據(jù)能夠進(jìn)行定量測量的客觀標(biāo)準(zhǔn)來論及性能。通過什么信息來分析系統(tǒng)性能，如何判定好壞？Google提供了思考性能問題的方法論，以用戶為中心的性能模型 - RAIL。

RAIL性能模型

用戶感知到的“性能”是什么?

0 - 16ms 動(dòng)畫流暢
0 - 100ms 即時(shí)響應(yīng)
1s + 慢，用戶失去耐心
10s 以上非常慢，用戶可能放棄使用

將用戶體驗(yàn)根據(jù)關(guān)鍵動(dòng)作分為4個(gè)獨(dú)立的模塊：response （響應(yīng)）、animation（動(dòng)畫）、idle（瀏覽器空置狀態(tài)）和load（加載），結(jié)合用戶對時(shí)間的感知，明確了對用戶體驗(yàn)影響最大的性能目標(biāo)。

如果在每個(gè)模塊上，都可以達(dá)到性能優(yōu)化的目標(biāo)值，那么最終用戶感受到的將會(huì)是極致的體驗(yàn)。

目標(biāo)與準(zhǔn)則

(1) Response 100ms內(nèi)完成交互

50ms內(nèi)處理完事件
對耗時(shí)長的操作提供即時(shí)反饋，比如說“加載中”的標(biāo)識。如果用戶點(diǎn)擊后沒有得到任何反饋，用戶會(huì)質(zhì)疑系統(tǒng)是否有問題

(2) RAnimation 流暢的視覺效果

動(dòng)畫并不止酷炫的效果，只要是視圖變化都算動(dòng)畫，包括滾動(dòng)，拖拽
16ms內(nèi)生成一幀，達(dá)到60fps

(3) RIdle 即時(shí)響應(yīng)用戶

盡可能增加空閑時(shí)間
利用空閑時(shí)間
始終以用戶操作為最高優(yōu)先級

(4) RLoad 5s內(nèi)可操作

1s內(nèi)渲染出主要內(nèi)容
如果無法快速展示頁面全部內(nèi)容，可以逐步渲染，使其看起來渲染快

與用戶體驗(yàn)相關(guān)的關(guān)鍵性能指標(biāo)

在 100 毫秒內(nèi)響應(yīng)用戶輸入。
播放動(dòng)畫或執(zhí)行滾動(dòng)時(shí)，在 10 毫秒內(nèi)生成一幀。
最大限度延長主線程空閑時(shí)間。
在 5000 毫秒內(nèi)加載交互式內(nèi)容。

RAIL性能模型提供了分析系統(tǒng)性能的思路，與用戶體驗(yàn)相關(guān)的關(guān)鍵性能指標(biāo)和實(shí)現(xiàn)目標(biāo)的準(zhǔn)則建議。了解用戶對不同關(guān)鍵動(dòng)作所期望的性能，使用Chrome DevTools對加載或運(yùn)行時(shí)的活動(dòng)進(jìn)行深入分析，識別性能問題。

Google又提出了更明細(xì)的以用戶為中心的性能指標(biāo)，幫助我們更好的了解真實(shí)用戶對Web的整體體驗(yàn)。

以用戶為中心的性能指標(biāo)

如何定義性能指標(biāo)？

從用戶角度出發(fā)，考慮以下關(guān)鍵問題，從用戶體驗(yàn)和關(guān)心的關(guān)鍵節(jié)點(diǎn)定義性能指標(biāo)

是否正在發(fā)生？導(dǎo)航是否成功啟動(dòng)？服務(wù)器有響應(yīng)嗎？
是否有用？是否渲染了足夠的內(nèi)容讓用戶可以深入其中？
是否可用？頁面是否繁忙，用戶是否可以與頁面進(jìn)行交互？
是否令人愉快？交互是否流暢自然，沒有延遲和卡頓？

性能指標(biāo)

? First contentful paint 首次內(nèi)容繪制 (FCP)：頁面開始加載到頁面顯示任何內(nèi)容的時(shí)間。

代表服務(wù)器有響應(yīng)，增大用戶繼續(xù)等待的信心

? Largest contentful paint 最大內(nèi)容繪制 (LCP)：頁面開始加載到最大文本塊或圖像元素在屏幕上完成渲染的時(shí)間。

代表有用，有助于讓用戶確信頁面有效

? First input delay 首次輸入延遲 (FID)：用戶第一次與網(wǎng)站交互（比如單擊鏈接、點(diǎn)按按鈕等）直到瀏覽器實(shí)際能夠?qū)换プ龀鲰憫?yīng)所經(jīng)過的時(shí)間。

確保頁面的有效性、可交互性

? Time to Interactive 可交互時(shí)間 (TTI)：頁面開始加載到能夠快速、可靠地響應(yīng)用戶輸入所需的時(shí)間。

確保頁面的有效性、可交互性

? Total blocking time 總阻塞時(shí)間 (TBT)：FCP 與 TTI 之間主線程被阻塞的總時(shí)間，期間無法可靠穩(wěn)定地響應(yīng)用戶。

確保頁面的可用性，體現(xiàn)了不可交互程度的嚴(yán)重性。

? Cumulative layout shift 累積布局偏移 (CLS)：頁面在開始加載和其生命周期狀態(tài)變?yōu)殡[藏期間發(fā)生的所有意外布局偏移的累積分?jǐn)?shù)。

確保頁面令人愉快

圖片來源：https://www.lambdatest.com/blog/core-web-vitals-expert-tips-to-improve-website-performance/

從程序員角度解讀

下圖展示了加載一個(gè)頁面，瀏覽器主線程和網(wǎng)絡(luò)的使用情況，以及各個(gè)指標(biāo)的耗時(shí)。

用戶訪問頁面，導(dǎo)航開始，瀏覽器與服務(wù)器建立連接，獲取HTML資源，再發(fā)出數(shù)個(gè)網(wǎng)絡(luò)請求來獲取所需的js，css資源。
這些資源下載完畢后，會(huì)在主線程上解析處理執(zhí)行。這就導(dǎo)致主線程會(huì)階段性地處于忙碌狀態(tài)（圖中米黃色任務(wù)塊）。
DOM樹構(gòu)建完成后，開始繪制，頁面渲染出部分內(nèi)容。首次內(nèi)容繪制節(jié)點(diǎn)即為FCP。
如果用戶在FCP后嘗試與頁面進(jìn)行交互（例如單擊一個(gè)按鈕），由于主線程正處于忙碌狀態(tài)，響應(yīng)會(huì)有一段延遲，延遲的這段時(shí)間即為首次輸入延遲FID。用戶會(huì)將較長的延遲認(rèn)為頁面響應(yīng)緩慢或者頁面已損壞，因此很可能直接離開。
5秒安靜窗口：沒有長任務(wù)切不超過兩個(gè)正在處理的網(wǎng)絡(luò)GET請求，此時(shí)瀏覽器主線程空閑并能可靠地響應(yīng)用戶。
可交互時(shí)間TTI是安靜窗口前的最后一個(gè)長任務(wù)的結(jié)束時(shí)間，是頁面從開始加載到主要子資源完成渲染，并能夠快速、可靠地響應(yīng)用戶輸入所需的時(shí)間。TTI越小越好，說明用戶等待的時(shí)間短。
用戶收到的阻塞程度則由TTB來體現(xiàn)，每當(dāng)出現(xiàn)長任務(wù)（在主線程上運(yùn)行超過 50 毫秒的任務(wù)）時(shí)，主線程都被視作"阻塞狀態(tài)"，瀏覽器無法中斷正在進(jìn)行的任務(wù)，長任務(wù)超過 50 毫秒的部分為阻塞時(shí)間，總阻塞時(shí)間是在 FCP 和 TTI 之間發(fā)生的每個(gè)長任務(wù)的阻塞時(shí)間總和，體現(xiàn)了不可交互程度的嚴(yán)重性。

圖片來源：https://web.dev/fid/

指標(biāo)閾值

Google將用戶體驗(yàn)的質(zhì)量分為三個(gè)等級：好、需要改進(jìn)或差，并設(shè)置了以下閾值：

圖片來源：https://developers.google.com/speed/docs/insights/v5/about

這些閾值可以作為行業(yè)性能基線，比較我們系統(tǒng)性能指標(biāo)得分和這些閾值可以了解我們系統(tǒng)對應(yīng)性能指標(biāo)的好壞。

自定義性能指標(biāo)

以用戶為中心的性能指標(biāo)提供了很好的性能基線，但很多情況我們需要測量更多的指標(biāo)來刻畫網(wǎng)站的完整體驗(yàn)。例如：

加載資源的緩存命中率：緩存機(jī)制設(shè)置的是否合理

長任務(wù) ：運(yùn)行開銷大的代碼是否阻塞主線程，比如頻繁計(jì)算/過濾50M的數(shù)據(jù)
元素渲染時(shí)間：長列表需要多久能繪制到頁面上
服務(wù)器響應(yīng)時(shí)間：CDN是否正確設(shè)置
API的耗時(shí)：在用戶使用應(yīng)用的生命周期中，增刪改查操作占據(jù)很大的比例。用戶也許能忍受用5分鐘打開一個(gè)頁面，但無法接受每次提交都要等很久。API也是我們分析性能的重點(diǎn)。

根據(jù)系統(tǒng)和需要評估的性能，自定義性能指標(biāo)，更全面地衡量系統(tǒng)性能。