還在看那些老掉牙的性能優化文章麼？這些最新性能指標瞭解下

性能優化相關的文章其實網上挺多，可是大部分都是在講如何優化性能，也就是講方法論。可是在實際工做中，如何量化性能優化也是至關重要的一環。今天本文會介紹谷歌提倡的七個用戶體驗指標（也能夠認爲是性能指標），每一個指標分別根據如下幾點講解：

1. 指標自己的做用、測量、推薦時間區間等
2. 如何指標進行優化，該內容會在文末統一講解

FP & FCP

首次繪製，FP（First Paint），這個指標用於記錄頁面第一次繪製像素的時間。

首次內容繪製，FCP（First Contentful Paint），這個指標用於記錄頁面首次繪製文本、圖片、非空白 Canvas 或 SVG 的時間。

這兩個指標看起來大同小異，可是 FP 發生的時間必定大於等於 FCP，以下圖是掘金的指標：

FP 指的是繪製像素，好比說頁面的背景色是灰色的，那麼在顯示灰色背景時就記錄下了 FP 指標。可是此時 DOM 內容還沒開始繪製，可能須要文件下載、解析等過程，只有當 DOM 內容發生變化纔會觸發，好比說渲染出了一段文字，此時就會記錄下 FCP 指標。所以說咱們能夠把這兩個指標認爲是和白屏時間相關的指標，因此確定是最快越好。

上圖是官方推薦的時間區間，也就是說若是 FP 及 FCP 兩指標在 2 秒內完成的話咱們的頁面就算體驗優秀。

LCP

最大內容繪製，LCP（Largest Contentful Paint），用於記錄視窗內最大的元素繪製的時間，該時間會隨着頁面渲染變化而變化，由於頁面中的最大元素在渲染過程當中可能會發生改變，另外該指標會在用戶第一次交互後中止記錄。指標變化以下圖：

LCP 其實能比前兩個指標更能體現一個頁面的性能好壞程度，由於這個指標會持續更新。舉個例子：當頁面出現骨架屏或者 Loading 動畫時 FCP 其實已經被記錄下來了，可是此時用戶但願看到的內容其實並未呈現，咱們更想知道的是頁面主要的內容是什麼時候呈現出來的。

此時 LCP 指標是可以幫助咱們實現想要的需求的。

上圖是官方推薦的時間區間，在 2.5 秒內表示體驗優秀。

TTI

首次可交互時間，TTI（Time to Interactive）。這個指標計算過程略微複雜，它須要知足如下幾個條件

1. 從 FCP 指標後開始計算
2. 持續 5 秒內無長任務（執行時間超過 50 ms）且無兩個以上正在進行中的 GET 請求
3. 往前回溯至 5 秒前的最後一個長任務結束的時間

這裏你可能會疑問爲何長任務須要定義爲 50ms 之外？

Google 提出了一個 RAIL 模型：

對於用戶交互（好比點擊事件），推薦的響應時間是 100ms 之內。那麼爲了達成這個目標，推薦在空閒時間裏執行任務不超過 50ms（W3C 也有這樣的標準規定），這樣能在用戶無感知的狀況下響應用戶的交互，不然就會形成延遲感。

長任務也會在 FID 及 TBT 指標中使用到。

所以這是一個很重要的用戶體驗指標，表明着頁面什麼時候真正進入可用的狀態。畢竟光內容渲染的快也不夠，還要能迅速響應用戶的交互。想必你們應該體驗過某些網站，雖然內容渲染出來了，可是響應交互很卡頓，只能過一會才能流暢交互的狀況。

FID

首次輸入延遲，FID（First Input Delay），記錄在 FCP 和 TTI 之間用戶首次與頁面交互時響應的延遲。

這個指標其實挺好理解，就是看用戶交互事件觸發到頁面響應中間耗時多少，若是其中有長任務發生的話那麼勢必會形成響應時間變長。

其實在上文咱們就講過 Google 推薦響應用戶交互在 100ms 之內：

TBT

阻塞總時間，TBT（Total Blocking Time），記錄在 FCP 到 TTI 之間全部長任務的阻塞時間總和。

假如說在 FCP 到 TTI 之間頁面總共執行了如下長任務（執行時間大於 50ms）及短任務（執行時間低於 50ms）

那麼每一個長任務的阻塞時間就等於它所執行的總時間減去 50ms

因此對於上圖的狀況來講，TBT 總共等於 345ms。

這個指標的高低其實也影響了 TTI 的高低，或者說和長任務相關的幾個指標都有關聯性。

CLS

累計位移偏移，CLS（Cumulative Layout Shift），記錄了頁面上非預期的位移波動。

你們想必遇到過這類狀況：頁面渲染過程當中忽然插入一張巨大的圖片或者說點擊了某個按鈕忽然動態插入了一塊內容等等至關影響用戶體驗的網站。這個指標就是爲這種狀況而生的，計算方式爲：位移影響的面積 * 位移距離。

以上圖爲例，文本移動了 25% 的屏幕高度距離（位移距離），位移先後影響了 75% 的屏幕高度面積（位移影響的面積），那麼 CLS 爲 0.25 * 0.75 = 0.1875。

CLS 推薦值爲低於 0.1，越低說明頁面跳來跳去的狀況就越少，用戶體驗越好。畢竟不多有人喜歡閱讀或者交互過程當中網頁忽然動態插入 DOM 的狀況，好比說插入廣告~

介紹完了全部的指標，接下來咱們來了解哪些是用戶體驗三大核心指標、如何獲取相應的指標數據及如何優化。

三大核心指標

Google 在今年五月提出了網站用戶體驗的三大核心指標，分別爲：

• LCP
• FID
• CLS

LCP 表明了頁面的速度指標，雖然還存在其餘的一些體現速度的指標，可是上文也說過 LCP 能體現的東西更多一些。一是指標實時更新，數據更精確，二是表明着頁面最大元素的渲染時間，一般來講頁面中最大元素的快速載入能讓用戶感受性能還挺好。

FID 表明了頁面的交互體驗指標，畢竟沒有一個用戶但願觸發交互之後頁面的反饋很遲緩，交互響應的快會讓用戶以爲網頁挺流暢。

CLS 表明了頁面的穩定指標，尤爲在手機上這個指標更爲重要。由於手機屏幕挺小，CLS 值一大的話會讓用戶以爲頁面體驗作的不好。

如何獲取指標

Lighthouse

你能夠經過安裝 Lighthouse 插件來獲取以下指標

web-vitals-extension

官方出品，你能夠經過安裝 web-vitals-extension 插件來獲取三大核心指標

web-vitals 庫

官方出品，你能夠經過安裝 web-vitals 包來獲取以下指標

代碼使用方式也挺簡單：

import {getCLS, getFID, getLCP} from 'web-vitals';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

Chrome DevTools

這個工具就很少作介紹了，打開 Performance 便可快速獲取以下指標

如何優化指標

資源優化

該項措施能夠幫助咱們優化 FP、FCP、LCP 指標。

• 壓縮文件、使用 Tree-shaking 刪除無用代碼
• 服務端配置 Gzip 進一步再壓縮文件體積
• 資源按需加載
• 經過 Chrome DevTools 分析首屏不須要使用的 CSS 文件，以此來精簡 CSS
• 內聯關鍵的 CSS 代碼
• 使用 CDN 加載資源及 dns-prefetch 預解析 DNS 的 IP 地址
• 對資源使用 preconnect，以便預先進行 IP 解析、TCP 握手、TLS 握手
• 緩存文件，對首屏數據作離線緩存
• 圖片優化，包括：用 CSS 代替蹄片、裁剪適配屏幕的圖片大小、小圖使用 base64 或者 PNG 格式、支持 WebP 就儘可能使用 WebP、漸進式加載圖片

網絡優化

該項措施能夠幫助咱們優化 FP、FCP、LCP 指標。

這塊內容大多可讓後端或者運維幫你去配置，升級至最新的網絡協議一般能讓你網站加載的更快。

好比說使用 HTTP2.0 協議、TLS 1.3 協議或者直接擁抱 QUIC 協議~

優化耗時任務

該項措施能夠幫助咱們優化 TTI、FID、TBT 指標。

• 使用 Web Worker 將耗時任務丟到子線程中，這樣能讓主線程在不卡頓的狀況下處理 JS 任務
• 調度任務 + 時間切片，這塊技術在 React 16 中有使用到。簡單來講就是給不一樣的任務分配優先級，而後將一段長任務切片，這樣能儘可能保證任務只在瀏覽器的空閒時間中執行而不卡頓主線程

不要動態插入內容

該項措施能夠幫助咱們優化 CLS 指標。

• 使用骨架屏給用戶一個預期的內容框架，突兀的顯示內容體驗不會很好
• 圖片切勿不設置長寬，而是使用佔位圖給用戶一個圖片位置的預期
• 不要在現有的內容中間插入內容，起碼給出一個預留位置

最後

以上是筆者對於用戶體驗指標的一些內容整理，若是有不懂的或者錯誤的地方歡迎指正及交流。

推薦關注個人微信公衆號【前端真好玩】，工做日推送高質量文章。

筆者就任於酷家樂，家裝設計行業獨角獸。一流的可視化、前端技術團隊，有興趣的能夠簡歷投遞至 zx597813039@gmail.com