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