INP 即將代替 FID 成為新的核心 Web 指標(biāo)

作者：Leecason 2023-05-30 08:01:47

INP 是一個(gè)新的核心 Web 指標(biāo)，將在 2024 年 3 月變成 Stable 狀態(tài)，替代 FID。它度量頁面生命周期的所有交互延時(shí)，評(píng)估的分?jǐn)?shù)能更貼近用戶實(shí)際使用時(shí)的體驗(yàn)，但同時(shí)也有一些局限。

什么是核心 Web 指標(biāo)，它包含哪些指標(biāo)？
什么是 FID，它是做什么的？
什么是 INP，它又是做什么的，它為什么會(huì)替代 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)注對(duì)優(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，首次輸入延時(shí)，是交互體驗(yàn)指標(biāo)。
CLS，Cumulative Layout Shift，累計(jì)布局偏移，是視覺穩(wěn)定性指標(biāo)。

關(guān)注的交互體驗(yàn)的一個(gè)重要方面是響應(yīng)性，也就是網(wǎng)頁對(duì)用戶交互作出快速反應(yīng)的能力。

FID 是目前度量網(wǎng)頁響應(yīng)性的一個(gè)核心指標(biāo)。

FID 的誕生以及局限

FID，F(xiàn)irst Input Delay，即首次輸入延時(shí)。

輸入延時(shí)是指從用戶第一次與頁面交互（例如點(diǎn)擊屏幕、用鼠標(biāo)點(diǎn)擊或按鍵）到交互的事件回調(diào)開始運(yùn)行的時(shí)間段。

新的方式衡量用戶體驗(yàn)

2020 年當(dāng) FID 作為核心 Web 指標(biāo)被引入時(shí)，為開發(fā)者提供了一種新的方式來衡量真實(shí)用戶體驗(yàn)的響應(yīng)性。

與 FID 類似的指標(biāo)有 TBT 和 TTI。不同的是，TBT 和 TTI 屬于加載性能指標(biāo)，只是近似地衡量頁面的互動(dòng)性。

TBT，Total Blocking Time，總阻塞時(shí)間。它的值等于 TTI（可交互時(shí)間）減去 FCP（首次繪制）。
TTI，Time To Interactive，首次可交互時(shí)間。

而 FID 直接衡量的是用戶體驗(yàn)，屬于交互體驗(yàn)指標(biāo)。

一個(gè)頁面它的 TBT 或 TTI 可能高，加載慢。但根據(jù)真實(shí)用戶與頁面交互的方式。FID 指標(biāo)仍然可能低，頁面會(huì)被認(rèn)為是具有響應(yīng)性的。

FID 的局限性

雖然 FID 確實(shí)改善了衡量頁面響應(yīng)性的方法，但 FID 也有一些局限性。它的名稱本質(zhì)上暴露了兩個(gè)局限：

首次：FID 只上報(bào)用戶第一次與頁面交互的響應(yīng)性。雖然“第一印象”很重要，但第一次并不一定代表整個(gè)頁面生命周期。
輸入延時(shí)：FID 只測量首次交互的輸入延時(shí)，即交互開始到事件開始處理這段時(shí)間，而事件處理和渲染的耗時(shí)，這部分時(shí)間是沒有被度量的。

使用 PerformanceObserver 計(jì)算 FID

我們可以使用 PerformanceObserver API 計(jì)算 FID。

下面是一段簡化代碼，能幫助我們理解如何計(jì)算 FID，完整代碼可參考：onFID[1]

const observer = new PerformanceObserver((entryList) => {
  const firstInput = entryList.getEntries()[0];
  
  const firstInputDelay = firstInput.processingStart - firstInput.startTime;
  
  // 上報(bào) 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 致力于探索一個(gè)更好的響應(yīng)性度量指標(biāo)。

2022 年 5 月，INP 誕生了。

INP，Interaction to Next Paint，從交互到下一次繪制的延時(shí)。它與 FID 一樣，屬于交互體驗(yàn)指標(biāo)。

能更全面地度量網(wǎng)站響應(yīng)性體驗(yàn)

Chrome 的使用數(shù)據(jù)顯示，用戶在頁面上花費(fèi)的時(shí)間有 90% 是在頁面加載之后，因此，在測量整個(gè)頁面生命周期的響應(yīng)度是非常重要的，這就是 INP 誕生的原因。

它不僅僅測量首次交互，而是所有交互延時(shí)。除了輸入延時(shí)，還包括事件處理時(shí)長，渲染延時(shí)。它的目標(biāo)是確保從用戶開始交互到下一幀繪制的時(shí)間盡可能短，以滿足用戶進(jìn)行的所有或大多數(shù)交互。

它的上報(bào)值是整個(gè)頁面生命周期中最慢的交互延時(shí)（取 98%，忽略異常值）。通常來說，一個(gè)擁有良好用戶體驗(yàn)的網(wǎng)站，它的 INP 應(yīng)該不超過 200 ms，如果在 200ms - 500ms 之間，則需要改進(jìn)，大于 500ms，代表頁面響應(yīng)性很差。為了確保大多數(shù)用戶都能達(dá)到這個(gè)目標(biāo)，我們可以觀測 75 分位的 INP。

同時(shí)，從 chrome-ux-report[2]，我們可以看到，93% 的網(wǎng)站在移動(dòng)設(shè)備上具有不錯(cuò)的 FID，

但只有 65% 的網(wǎng)站在移動(dòng)設(shè)備上具有不錯(cuò)的 INP。

INP 代表的是更準(zhǔn)確的網(wǎng)站響應(yīng)性體驗(yàn)。

即將取代 FID

到 23 年 5 月前，INP 還只是一個(gè)實(shí)驗(yàn)性（Experimantal）的指標(biāo)。

經(jīng)過了社區(qū)的不斷驗(yàn)證和反饋，現(xiàn)在，INP 變成了一個(gè)待定（Pending）的核心 Web 指標(biāo)。

為什么是 Pending 呢？

其目的是為了讓相關(guān)生態(tài)有時(shí)間進(jìn)行調(diào)整，比如一些測量工具的 API 字段，需要從 experimental_interaction_to_next_paint 更新為 interaction_to_next_paint。

INP 即將在 2024 年 3 月正式成為一個(gè)穩(wěn)定（Stable）的核心 Web 指標(biāo)，徹底取代 FID。

到那時(shí)，INP 將同 LCP 和 CLS 一起，成為的核心 Web 指標(biāo)。

使用 PerformanceObserver 計(jì)算 INP

我們也可以使用 PerformanceObserver API 計(jì)算 INP。

下面是一段簡化代碼，能幫助我們理解如何計(jì)算 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;
  
  // 上報(bào) INP
});


observer.observe({ 
  type: 'event',
  durationThreshold: 16,
  buffered: true 
});

我們可以使用 Lighthouse，WebPagetest 等工具來度量網(wǎng)頁的 INP。

優(yōu)化 INP

從上面的代碼中我們可以看到收集到的 INP 的值是 entry.duration。那么這個(gè)值是怎么計(jì)算出來的呢？

先來看看一次交互是怎么組成的，一次交互可分為 3 個(gè)階段：

輸入延時(shí)（Input Delay）= 交互事件回調(diào)開始運(yùn)行時(shí) - 用戶發(fā)起與頁面的交互時(shí)，F(xiàn)ID 度量的就是這段時(shí)間。
事件處理（Processing Time）= 事件回調(diào)運(yùn)行完成時(shí) - 事件回調(diào)運(yùn)行開始時(shí)
渲染延時(shí)（Presentation Delay）= 瀏覽器顯示包含交互的可視結(jié)果的下一幀渲染時(shí) - 事件回調(diào)運(yùn)行完成時(shí)

所以這三個(gè)階段的總和就是總的交互延時(shí)。

duration = Input Delay + Processing Time + Presentation Delay

每一個(gè)階段都會(huì)在總的交互延時(shí)中占有一定的時(shí)間，因此優(yōu)化交互延時(shí)，需要讓每一部分的時(shí)間盡可能的短。

減少輸入延時(shí)

每個(gè)交互都以一定量的輸入延時(shí)開始。

一些輸入延時(shí)是不可避免的，比如操作系統(tǒng)識(shí)別輸入事件并將其傳遞給瀏覽器總是需要一些時(shí)間。但一些輸入延時(shí)是可以避免的。

避免反復(fù)執(zhí)行的定時(shí)器占用主線程工作

JavaScript 中有兩個(gè)常用的定時(shí)器可能導(dǎo)致輸入延時(shí)：setTimeout 和 setInterval。

setTimeout 本身并沒有問題，甚至有助于避免 long task。但是，如果在 timeout 后的回調(diào)運(yùn)行時(shí)，用戶剛好在嘗試與頁面交互，就可能導(dǎo)致輸入延時(shí)。應(yīng)該避免 setTimeout 循環(huán)或遞歸地執(zhí)行，讓其行為變得像 setInterval，同時(shí)應(yīng)該注意確保在它的回調(diào)里不會(huì)執(zhí)行過多的工作。
而 setInterval 在一個(gè) interval 時(shí)間間隔上運(yùn)行回調(diào)，因此更有可能阻礙交互。

避免 longt task

在交互過程中，如果執(zhí)行的 task 過長，阻塞了主線程時(shí)，就會(huì)增加輸入延時(shí)。

所以，應(yīng)該盡量減少一項(xiàng) task 中的工作量，在主線程上做盡可能少的工作，還可以通過分解 long task 來提高對(duì)用戶輸入的響應(yīng)能力。

注意交互重疊（interaction overlap）

這是優(yōu)化 INP 的一個(gè)特別具有挑戰(zhàn)性的部分。交互重疊指的是，當(dāng)在用戶首次完成交互后，有機(jī)會(huì)渲染包含該交互可視結(jié)果時(shí)，又產(chǎn)生了新的交互。

交互重疊的來源很簡單，可能是用戶在短時(shí)間內(nèi)進(jìn)行了多次交互，比如用戶輸入表單字段時(shí)。如果在輸入完成后要進(jìn)行的交互開銷很大，一個(gè)常見的場景是會(huì)發(fā)送網(wǎng)絡(luò)請(qǐng)求到后端。

面對(duì)這種場景我們可以使用 debounce 限制在事件回調(diào)在時(shí)間段內(nèi)執(zhí)行的次數(shù)，也可以取消掉上次發(fā)出的請(qǐng)求，這樣主線程就不用處理那么多的事件回調(diào)。

另一個(gè)交互重疊增加輸入延時(shí)的場景是昂貴的動(dòng)畫。因?yàn)檫@會(huì)觸發(fā)很多的 requestAnimationFrame 阻塞交互。我們應(yīng)該盡可能地使用 CSS 動(dòng)畫，并且使用合成層動(dòng)畫，讓動(dòng)畫運(yùn)行在GPU和合成器線程上，而不是主線程。

優(yōu)化事件回調(diào)

輸入延時(shí)只是 INP 測量的第一部分。還需要確保響應(yīng)用戶交互而運(yùn)行的事件回調(diào)可以盡快完成。

優(yōu)化 long task

提高事件處理速度，盡快讓出主線程。

建立正確的輸入優(yōu)先級(jí)

通對(duì)不同類型的輸入進(jìn)行分類，建立優(yōu)先級(jí)順序，例如首選輸入、次要輸入和可等待輸入。

首選輸入應(yīng)該盡可能快地得到響應(yīng)，而次要輸入和可等待輸入可以稍后處理。

比如 React 18 新引入的 API useDeferredValue 和 useTransition 就是用來做這個(gè)的，讓 value 的更新和回調(diào)的執(zhí)行不阻塞 UI。

避免布局抖動(dòng)

布局抖動(dòng)，又叫強(qiáng)制同步布局，是一種渲染問題，會(huì)造成性能瓶頸。

問題產(chǎn)生的原因就是在同一個(gè)任務(wù)中，更新了樣式，然后立即使用 JavaScript 讀取這些新樣式，讓瀏覽器被迫做同步的布局工作。

減少渲染延時(shí)

交互的渲染延時(shí)表示從交互的事件回調(diào)運(yùn)行完成到瀏覽器能夠繪制下一幀顯示結(jié)果的時(shí)間段。

減小 DOM 當(dāng) DOM 很小時(shí)，渲染工作完成的會(huì)比較快。可以采取一些辦法減小 DOM 的大小，比如使用虛擬列表來避免 DOM 過大，但這樣的方法可能效果有限。
使用 content-visibility 屬性延時(shí)渲染視口外的元素

https://mp.weixin.qq.com/s/o9lpl7CTwcbjM0q3QMRLTg

這個(gè) CSS 屬性可以控制元素在接近視口時(shí)才會(huì)被渲染，目前還屬于實(shí)驗(yàn)性屬性，在一些瀏覽器上還不兼容。但確實(shí)能有效減少渲染延時(shí)，改善 INP。

INP 的局限

INP 度量的是用戶在頁面上操作全程的響應(yīng)性能，更貼近用戶實(shí)際執(zhí)行時(shí)的體驗(yàn)，但同時(shí)也有一些局限。

SPA 的路由跳轉(zhuǎn)，也算作「交互」

在單頁應(yīng)用（SPA）中，路由的跳轉(zhuǎn)，也會(huì)被算作「交互」，而不是「導(dǎo)航」。

而用戶對(duì)于兩種不同的行為有著不同的預(yù)期，對(duì)于「導(dǎo)航」而言一般用戶可以忍受超過比普通點(diǎn)擊更長的延遲。

SPA 跨頁面上報(bào)

這其實(shí)是目前 Web 指標(biāo)的通病。同一個(gè)應(yīng)用不同頁面的 INP 會(huì)混在一起上報(bào)，但可能在使用過程中某個(gè)頁面其實(shí) INP 是比較小的，或者上報(bào)時(shí)的 INP 是之前使用的頁面而不是上報(bào)的頁面導(dǎo)致的。

總結(jié)

INP 是一個(gè)新的核心 Web 指標(biāo)，將在 2024 年 3 月變成 Stable 狀態(tài)，替代 FID。

它度量頁面生命周期的所有交互延時(shí)，評(píng)估的分?jǐn)?shù)能更貼近用戶實(shí)際使用時(shí)的體驗(yàn)，但同時(shí)也有一些局限。

一個(gè)新的響應(yīng)性標(biāo)準(zhǔn)已經(jīng)建立，對(duì)許多人來說，這可能是一條漫長而陌生的道路。

盡早地了解即將到來的變化可以讓我們有更多的時(shí)間準(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/