INP 即將代替 FID 成為新的核心 Web 指標(biāo)
- 什么是核心 Web 指標(biāo)，它包含哪些指標(biāo)？
- 什么是 FID，它是做什么的？
- 什么是 INP，它又是做什么的，它為什么會替代 FID？
- 如何優(yōu)化 INP 指標(biāo)？
- INP 有什么局限？
在進(jìn)入正文前，先來看看什么是核心 Web 指標(biāo)。
核心 Web 指標(biāo)
核心 Web 指標(biāo)（Core Web Vitals，CWV）是一組 Web 性能指標(biāo)。Google 推出它的目的是幫助開發(fā)人員關(guān)注對優(yōu)秀的用戶體驗(yàn)至關(guān)重要的指標(biāo)。
目前包含 3 組指標(biāo)：
- LCP，Largest Contentful Paint，最大內(nèi)容繪制：是加載性能指標(biāo)。
- FID，F(xiàn)irst Input Delay，首次輸入延時，是交互體驗(yàn)指標(biāo)。
- CLS，Cumulative Layout Shift，累計布局偏移，是視覺穩(wěn)定性指標(biāo)。
關(guān)注的交互體驗(yàn)的一個重要方面是響應(yīng)性，也就是網(wǎng)頁對用戶交互作出快速反應(yīng)的能力。
FID 是目前度量網(wǎng)頁響應(yīng)性的一個核心指標(biāo)。
FID 的誕生以及局限
FID，F(xiàn)irst Input Delay，即首次輸入延時。
輸入延時是指從用戶第一次與頁面交互（例如點(diǎn)擊屏幕、用鼠標(biāo)點(diǎn)擊或按鍵）到交互的事件回調(diào)開始運(yùn)行的時間段。
新的方式衡量用戶體驗(yàn)
2020 年當(dāng) FID 作為核心 Web 指標(biāo)被引入時，為開發(fā)者提供了一種新的方式來衡量真實(shí)用戶體驗(yàn)的響應(yīng)性。
與 FID 類似的指標(biāo)有 TBT 和 TTI。不同的是，TBT 和 TTI 屬于加載性能指標(biāo)，只是近似地衡量頁面的互動性。
- TBT，Total Blocking Time，總阻塞時間。它的值等于 TTI（可交互時間）減去 FCP（首次繪制）。
- TTI，Time To Interactive，首次可交互時間。
而 FID 直接衡量的是用戶體驗(yàn)，屬于交互體驗(yàn)指標(biāo)。
一個頁面它的 TBT 或 TTI 可能高，加載慢。但根據(jù)真實(shí)用戶與頁面交互的方式。FID 指標(biāo)仍然可能低，頁面會被認(rèn)為是具有響應(yīng)性的。
FID 的局限性
雖然 FID 確實(shí)改善了衡量頁面響應(yīng)性的方法，但 FID 也有一些局限性。它的名稱本質(zhì)上暴露了兩個局限：
- 首次：FID 只上報用戶第一次與頁面交互的響應(yīng)性。雖然“第一印象”很重要，但第一次并不一定代表整個頁面生命周期。
- 輸入延時：FID 只測量首次交互的輸入延時，即交互開始到事件開始處理這段時間，而事件處理和渲染的耗時，這部分時間是沒有被度量的。
使用 PerformanceObserver 計算 FID
我們可以使用 PerformanceObserver API 計算 FID。
下面是一段簡化代碼，能幫助我們理解如何計算 FID，完整代碼可參考：onFID[1]
const observer = new PerformanceObserver((entryList) => {
const firstInput = entryList.getEntries()[0];
const firstInputDelay = firstInput.processingStart - firstInput.startTime;
// 上報 FID
});
// 只監(jiān)聽首次輸入
// buffered 設(shè)置為 true，可以獲取到在 PerformanceObserver 創(chuàng)建之前發(fā)生的所有 "first-input" 事件。
observer.observe({ type: 'first-input', buffered: true });INP，更好的響應(yīng)性度量指標(biāo)
FID 的這些局限，使得 Google 致力于探索一個更好的響應(yīng)性度量指標(biāo)。
2022 年 5 月，INP 誕生了。
INP，Interaction to Next Paint，從交互到下一次繪制的延時。它與 FID 一樣，屬于交互體驗(yàn)指標(biāo)。
能更全面地度量網(wǎng)站響應(yīng)性體驗(yàn)
Chrome 的使用數(shù)據(jù)顯示，用戶在頁面上花費(fèi)的時間有 90% 是在頁面加載之后，因此，在測量整個頁面生命周期的響應(yīng)度是非常重要的，這就是 INP 誕生的原因。
它不僅僅測量首次交互，而是所有交互延時。除了輸入延時，還包括事件處理時長，渲染延時。它的目標(biāo)是確保從用戶開始交互到下一幀繪制的時間盡可能短，以滿足用戶進(jìn)行的所有或大多數(shù)交互。
它的上報值是整個頁面生命周期中最慢的交互延時（取 98%，忽略異常值）。通常來說，一個擁有良好用戶體驗(yàn)的網(wǎng)站，它的 INP 應(yīng)該不超過 200 ms，如果在 200ms - 500ms 之間，則需要改進(jìn)，大于 500ms，代表頁面響應(yīng)性很差。為了確保大多數(shù)用戶都能達(dá)到這個目標(biāo)，我們可以觀測 75 分位的 INP。
同時，從 chrome-ux-report[2]，我們可以看到，93% 的網(wǎng)站在移動設(shè)備上具有不錯的 FID，
但只有 65% 的網(wǎng)站在移動設(shè)備上具有不錯的 INP。
INP 代表的是更準(zhǔn)確的網(wǎng)站響應(yīng)性體驗(yàn)。
即將取代 FID
到 23 年 5 月前，INP 還只是一個實(shí)驗(yàn)性（Experimantal）的指標(biāo)。
經(jīng)過了社區(qū)的不斷驗(yàn)證和反饋，現(xiàn)在，INP 變成了一個待定（Pending）的核心 Web 指標(biāo)。
為什么是 Pending 呢？
其目的是為了讓相關(guān)生態(tài)有時間進(jìn)行調(diào)整，比如一些測量工具的 API 字段，需要從 experimental_interaction_to_next_paint 更新為 interaction_to_next_paint。
INP 即將在 2024 年 3 月正式成為一個穩(wěn)定（Stable）的核心 Web 指標(biāo)，徹底取代 FID。
到那時，INP 將同 LCP 和 CLS 一起，成為的核心 Web 指標(biāo)。
使用 PerformanceObserver 計算 INP
我們也可以使用 PerformanceObserver API 計算 INP。
下面是一段簡化代碼，能幫助我們理解如何計算 INP，完整代碼可參考：onINP[3]
let maxDuration = 0;
const observer = new PerformanceObserver(entryList => {
const entries = entryList.getEntries();
entries.forEach(entry => {
// 一些不支持的瀏覽器沒有 interactionId，比如 firefox
if (!entry.interactionId) return;
if (entry.duration > maxDuration) {
// 找到了更長的 INP 值
maxDuration = entry.duration;
}
});
const inp = maxDuration;
// 上報 INP
});
observer.observe({
type: 'event',
durationThreshold: 16,
buffered: true
});我們可以使用 Lighthouse，WebPagetest 等工具來度量網(wǎng)頁的 INP。
優(yōu)化 INP
從上面的代碼中我們可以看到收集到的 INP 的值是 entry.duration。那么這個值是怎么計算出來的呢？
先來看看一次交互是怎么組成的，一次交互可分為 3 個階段：
- 輸入延時（Input Delay）= 交互事件回調(diào)開始運(yùn)行時 - 用戶發(fā)起與頁面的交互時，F(xiàn)ID 度量的就是這段時間。
- 事件處理（Processing Time）= 事件回調(diào)運(yùn)行完成時 - 事件回調(diào)運(yùn)行開始時
- 渲染延時（Presentation Delay）= 瀏覽器顯示包含交互的可視結(jié)果的下一幀渲染時 - 事件回調(diào)運(yùn)行完成時
所以這三個階段的總和就是總的交互延時。
duration = Input Delay + Processing Time + Presentation Delay每一個階段都會在總的交互延時中占有一定的時間，因此優(yōu)化交互延時，需要讓每一部分的時間盡可能的短。
減少輸入延時
每個交互都以一定量的輸入延時開始。
一些輸入延時是不可避免的，比如操作系統(tǒng)識別輸入事件并將其傳遞給瀏覽器總是需要一些時間。但一些輸入延時是可以避免的。
- 避免反復(fù)執(zhí)行的定時器占用主線程工作
JavaScript 中有兩個常用的定時器可能導(dǎo)致輸入延時：setTimeout 和 setInterval。
- setTimeout 本身并沒有問題，甚至有助于避免 long task。但是，如果在 timeout 后的回調(diào)運(yùn)行時，用戶剛好在嘗試與頁面交互，就可能導(dǎo)致輸入延時。應(yīng)該避免 setTimeout 循環(huán)或遞歸地執(zhí)行，讓其行為變得像 setInterval，同時應(yīng)該注意確保在它的回調(diào)里不會執(zhí)行過多的工作。
- 而 setInterval 在一個 interval 時間間隔上運(yùn)行回調(diào)，因此更有可能阻礙交互。
- 避免 longt task
在交互過程中，如果執(zhí)行的 task 過長，阻塞了主線程時，就會增加輸入延時。
所以，應(yīng)該盡量減少一項 task 中的工作量，在主線程上做盡可能少的工作，還可以通過分解 long task 來提高對用戶輸入的響應(yīng)能力。
- 注意交互重疊（interaction overlap）
這是優(yōu)化 INP 的一個特別具有挑戰(zhàn)性的部分。交互重疊指的是，當(dāng)在用戶首次完成交互后，有機(jī)會渲染包含該交互可視結(jié)果時，又產(chǎn)生了新的交互。
交互重疊的來源很簡單，可能是用戶在短時間內(nèi)進(jìn)行了多次交互，比如用戶輸入表單字段時。如果在輸入完成后要進(jìn)行的交互開銷很大，一個常見的場景是會發(fā)送網(wǎng)絡(luò)請求到后端。
面對這種場景我們可以使用 debounce 限制在事件回調(diào)在時間段內(nèi)執(zhí)行的次數(shù)，也可以取消掉上次發(fā)出的請求，這樣主線程就不用處理那么多的事件回調(diào)。
另一個交互重疊增加輸入延時的場景是昂貴的動畫。因?yàn)檫@會觸發(fā)很多的 requestAnimationFrame 阻塞交互。我們應(yīng)該盡可能地使用 CSS 動畫，并且使用合成層動畫，讓動畫運(yùn)行在GPU和合成器線程上，而不是主線程。
優(yōu)化事件回調(diào)
輸入延時只是 INP 測量的第一部分。還需要確保響應(yīng)用戶交互而運(yùn)行的事件回調(diào)可以盡快完成。
- 優(yōu)化 long task
提高事件處理速度，盡快讓出主線程。
- 建立正確的輸入優(yōu)先級
通對不同類型的輸入進(jìn)行分類，建立優(yōu)先級順序，例如首選輸入、次要輸入和可等待輸入。
首選輸入應(yīng)該盡可能快地得到響應(yīng)，而次要輸入和可等待輸入可以稍后處理。
比如 React 18 新引入的 API useDeferredValue 和 useTransition 就是用來做這個的，讓 value 的更新和回調(diào)的執(zhí)行不阻塞 UI。
- 避免布局抖動
布局抖動，又叫強(qiáng)制同步布局，是一種渲染問題，會造成性能瓶頸。
問題產(chǎn)生的原因就是在同一個任務(wù)中，更新了樣式，然后立即使用 JavaScript 讀取這些新樣式，讓瀏覽器被迫做同步的布局工作。
減少渲染延時
交互的渲染延時表示從交互的事件回調(diào)運(yùn)行完成到瀏覽器能夠繪制下一幀顯示結(jié)果的時間段。
- 減小 DOM 當(dāng) DOM 很小時，渲染工作完成的會比較快?？梢圆扇∫恍┺k法減小 DOM 的大小，比如使用虛擬列表來避免 DOM 過大，但這樣的方法可能效果有限。
- 使用 content-visibility 屬性延時渲染視口外的元素
https://mp.weixin.qq.com/s/o9lpl7CTwcbjM0q3QMRLTg
這個 CSS 屬性可以控制元素在接近視口時才會被渲染，目前還屬于實(shí)驗(yàn)性屬性，在一些瀏覽器上還不兼容。但確實(shí)能有效減少渲染延時，改善 INP。
INP 的局限
INP 度量的是用戶在頁面上操作全程的響應(yīng)性能，更貼近用戶實(shí)際執(zhí)行時的體驗(yàn)，但同時也有一些局限。
SPA 的路由跳轉(zhuǎn)，也算作「交互」
在單頁應(yīng)用（SPA）中，路由的跳轉(zhuǎn)，也會被算作「交互」，而不是「導(dǎo)航」。
而用戶對于兩種不同的行為有著不同的預(yù)期，對于「導(dǎo)航」而言一般用戶可以忍受超過比普通點(diǎn)擊更長的延遲。
SPA 跨頁面上報
這其實(shí)是目前 Web 指標(biāo)的通病。同一個應(yīng)用不同頁面的 INP 會混在一起上報，但可能在使用過程中某個頁面其實(shí) INP 是比較小的，或者上報時的 INP 是之前使用的頁面而不是上報的頁面導(dǎo)致的。
總結(jié)
INP 是一個新的核心 Web 指標(biāo)，將在 2024 年 3 月變成 Stable 狀態(tài)，替代 FID。
它度量頁面生命周期的所有交互延時，評估的分?jǐn)?shù)能更貼近用戶實(shí)際使用時的體驗(yàn)，但同時也有一些局限。
一個新的響應(yīng)性標(biāo)準(zhǔn)已經(jīng)建立，對許多人來說，這可能是一條漫長而陌生的道路。
盡早地了解即將到來的變化可以讓我們有更多的時間準(zhǔn)備來迎接它。
不要等到 INP 成為了 Stable 指標(biāo)，再去優(yōu)化它，從現(xiàn)在起，Just Do It。
參考
- https://docs.google.com/presentation/d/1thCizKqUxpP7hxmy1m_lrTX7bHz71-zrOipgSUn5wN8/edit#slide=id.g12a9ead5670_2_86
- https://web.dev/inp-cwv/
- https://web.dev/inp/
- https://web.dev/optimize-inp/
- https://web.dev/optimize-input-delay/
- https://web.dev/optimize-long-tasks/
- https://web.dev/dom-size-and-interactivity/
參考資料
[1]onFID: https://github.com/GoogleChrome/web-vitals/blob/main/src/onFID.ts
[2]chrome-ux-report: https://httparchive.org/reports/chrome-ux-report
[3]onINP: https://github.com/GoogleChrome/web-vitals/blob/main/src/onINP.ts
