瞭解新的 INP 指標對使用 JavaScript 架構和程式庫建構的網站的使用體驗有何影響。
Chrome 最近在 Chrome 使用者體驗報告報告中推出了新的實驗回應速度指標。這項指標現已改稱「與下一個顯示的內容互動 (INP)」，可評估網頁上使用者互動的整體回應。今天我們想分享一些深入分析資訊，說明使用新型 JavaScript 架構建構網站所處的面向，以及這項指標的表現。我們想探討為什麼 INP 與架構相關，以及 Aurora 和架構目前如何設法改善回應速度。
背景
Chrome 使用 First Input Delay (FID) 做為網站體驗核心指標 (CWV) 的一環，藉此評估網站的載入回應速度。FID 用於測量從最初使用者互動到瀏覽器處理所連線事件處理常式的等待時間。不包括在事件回呼執行後處理事件處理常式、在相同頁面中處理後續互動或繪製下一個影格所需的時間。不過，對使用者體驗來說，反應在網頁生命週期中非常重要，因為使用者在網頁載入後，大約會有 90% 的時間停留在網頁中。
INP 會評估從使用者開始互動到顯示下一個頁框的那一刻，網頁回應使用者互動所需的時間。我們希望藉由 INP 能夠對網頁生命週期內所有互動的感知延遲時間，提供匯總測量指標。我們相信 INP 將能更準確地預估網頁的載入速度和執行階段回應。
由於 FID 只會測量最初互動的輸入延遲，因此網頁程式開發人員可能未在 CWV 改善過程中主動改善後續的互動。因此，網站 (尤其是互動性高的網站) 必須開始努力實現這項指標。
架構的作用
由於許多網站仰賴 JavaScript 提供互動功能，因此 INP 分數主要會受到主執行緒上處理的 JavaScript 數量影響。JavaScript 架構是現代前端網頁開發中不可或缺的一環，可為開發人員提供重要的抽象層，以便轉送、處理事件及劃分 JavaScript 程式碼。因此對採用這類網站的網站回應速度和使用者體驗都極為重要。
架構可能提早採取措施來改善網站的 FID，藉此改善回應速度。然而，他們現在必須分析可用的回應速度指標資料，並設法解決找到的所有缺口。一般來說，INP 的通過率通常較低，而評估程序的差異在於需要進行額外的程式碼最佳化作業。下表摘要說明原因。
Chrome 的 Aurora 團隊與開放原始碼網路架構合作，協助開發人員改善各種使用者體驗，包括效能和 CWV 指標。隨著 INP 問世，我們希望為架構式網站的 CWV 指標進行調整。我們已根據 CrUX 報表的實驗性回應程度指標收集資料。我們會分享洞察資料和操作項目，協助您順利改用架構型網站 INP 指標。
實驗回應情形指標資料
如果 INP 低於或等於 200 毫秒，表示回應速度良好。歡迎查看 2023 年 6 月的 CrUX 報表資料和 CWV 技術報告，瞭解熱門 JavaScript 架構回應速度的相關資訊。
這份表格會顯示每個架構中回應性分數良好的來源百分比。這項數據雖令人振奮，但也證明仍有改善空間。
JavaScript 對 INP 有何影響？
領域中的 INP 值與研究室觀察到的總封鎖時間 (TBT) 密切相關。這可能意味著，任何長時間封鎖主執行緒的指令碼對於 INP 都是不當的。在任何互動後大量執行 JavaScript 可能會長時間封鎖主執行緒，並延遲對該互動的回應。造成封鎖指令碼的一些常見原因包括：
未最佳化的 JavaScript：如果程式碼分割和載入策略過舊，可能會導致 JavaScript 過大並長時間封鎖主執行緒。程式碼分割、漸進式載入和中斷長時間工作，都能大幅縮短回應時間。
第三方指令碼： 第三方指令碼有時不需要處理互動 (例如廣告指令碼)，可能會封鎖主執行緒，並造成不必要的延遲。優先使用重要指令碼有助於減少第三方指令碼的負面影響。
多個事件處理常式：與每項互動相關的多個事件處理常式，而且每個事件執行不同的指令碼都可能會幹擾彼此，造成長時間延遲。其中有些工作可能不是必要的工作，可以安排在網路工作站或瀏覽器閒置時進行。
事件處理的架構負擔：架構可能有額外的功能/語法來處理事件。舉例來說，Vue 會使用 v-on 將事件監聽器附加至元素，Angular 則會納入使用者事件處理常式。實作這些功能需要在基本 JavaScript 上方的額外架構程式碼。
飲水：使用 JavaScript 架構時，伺服器通常不會為網頁產生初始 HTML，因此需要搭配事件處理常式和應用程式狀態，才能在網路瀏覽器中與內容互動。我們將這個過程稱為飲水量。視 JavaScript 載入和補充水完成而定，這可能需要耗費大量時間。以及看起來不互動的網頁。一般情況下，系統會在網頁載入期間或延遲 (例如與使用者互動時) 自動飲水，這可能會因為工作排程而影響 INP 或處理時間。在 React 等程式庫中，您可以使用
useTransition，讓元件轉譯的部分顯示在下一個影格中，而後續的影格中仍會產生昂貴的副作用。因此，如果能產生更緊急的更新 (例如點擊) 的更新內容，就是一種適用於 INP 的模式。預先擷取：主動預先擷取後續導覽所需的資源，或許能當一切正常。不過，如果以同步方式預先擷取及算繪 SPA 路徑，可能會對 INP 造成負面影響，因為所有這類耗用資源的轉譯作業都會在單一影格中完成。相反地，這是不會預先擷取路線，而是啟動必要工作 (例如
fetch()) 並解除封鎖繪製作業。建議您重新思考一下，貴機構架構的預先擷取做法是否能提供最佳使用者體驗，以及這對於 INP 可能造成的影響 (如果有的話)。
從現在起，如要獲得良好的 INP 分數，開發人員必須專注於檢查每次網頁互動後執行的程式碼，並針對第一方和第三方指令碼的區塊、補充和載入策略，以及每次的 Render() 更新最佳化調整區塊的大小。
Aurora 和架構如何解決 INP 問題？
Aurora 與架構搭配運作，透過採用最佳做法為常見問題提供烘焙解決方案。我們與 Next.js、Nutx.js、Gatsby 和 Angular 合作，開發出解決方案，在架構中提供強大的預設架構，以便發揮最佳效能。以下重點說明我們在此情境下的工作重點：
React 和 Next.js：Next.js 指令碼元件可協助您解決因載入第三方指令碼效率不佳而造成的問題。Next.js 中推出了精細區塊，以便讓小塊區塊能夠共用程式碼。這有助於減少所有頁面中未使用的常用程式碼。我們也與 Next.js 合作，在 Analytics (分析) 服務中提供 INP 資料。
Angular：Aurora 與 Angular 團隊合作，探索伺服器端轉譯和水分補充方面的改善。我們也計劃深入研究事件處理和變更偵測的修正，以改善 INP。
Vue 和 Nuxt.js：我們正設法展開協作，主要著重在載入和轉譯指令碼。
關於改善 INP 的框架如何思考？
React 和 Next.js
透過 startTransition 和 Suspense 實作的 React.js 時間切片可讓您選擇採用選擇性或漸進式水源。這表示飲水並非同步的封鎖機制。這些設定在小型切片中完成，而且在任何時間點都不會受到干擾。
這應該有助於改善 INP，讓您更快速地回應按鍵動作、在轉場期間懸停特效和點擊動作。此外，對於需要大型轉場 (例如自動完成) 的情況，這也能確保 React 應用程式能夠持續回應。
Next.js 已導入新的轉送架構，根據預設，路徑轉換作業使用 startTransition。如此一來，Next.js 網站擁有者就能採用 React 時間切片功能，並提高路徑轉換的回應速度。
Angular
Angular 團隊正在探索幾個也有助於解決 INP 的問題：
- 無可用區：減少初始套件大小，以及應用程式必須先載入所需的程式碼，才能轉譯任何內容。
- 飲水：島嶼類型的飲水，用於限制應用程式需要喚醒多少時間才能進行互動。
- 減少持續推送軟體更新的負擔：例如降低變更偵測的成本、尋找方法減少應用程式內容，以及運用回應信號來掌握變更項目。
- 更精細的程式碼分割：縮小初始組合。
- 對載入指標的支援：例如 SSR 重新轉譯期間、路線導航期間和延遲載入作業期間。
- 剖析工具：將更優異的開發工具來瞭解互動費用，特別是特定互動的變更偵測費用。
透過這些強化措施，我們得以解決各種會導致回應不良和使用者體驗的問題，並提升 CWV 指標和架構式網站的新 INP 指標。
結語
我們預期 INP 分數能為網站提供更優質的指南度，進而改善回應速度和效能。我們將以現有的 INP 指南為基礎，在 2023 年為架構開發人員提供更多可採取行動的訣竅。我們希望透過以下做法達成這個目標：
- 建立管道，方便架構和網頁程式開發人員存取 INP 上的現場資料。
- 運用架構建構預設改善 INP 的功能。
我們歡迎架構使用者展開 INP 最佳化旅程時提出意見回饋。