瞭解新的 INP 指標對使用 JavaScript 架構和程式庫建立的網站使用體驗有何影響。
Chrome 最近在 Chrome 使用者體驗報告中推出了全新的實驗回應指標。這項指標現稱為「與下一個顯示內容的互動 (INP)」指標，可評估網頁上使用者互動的整體回應程度。今天要與您分享一項見解，說明使用現代化 JavaScript 架構建構的網站在哪些方面與這項指標的關係。我們想探討為何 INP 與架構相關，以及 Aurora 和架構如何努力提升回應速度。
背景
Chrome 會將首次輸入延遲時間 (FID) 納入 Core Web Vitals (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 分數，開發人員必須專注於檢查每次網頁互動後執行的程式碼，並改進第一方和第三方指令碼的區塊、再補、載入策略和每個 Rend() 更新的大小。
Aurora 和架構如何解決 INP 問題？
Aurora 會運用最佳做法與各種架構搭配運作，針對常見問題提供烘焙解決方案。我們與 Next.js、Nuxt.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，讓您可更快回應按鍵動作、轉場時的懸停效果和點擊動作。這個 API 也有助於確保 React 應用程式能在進行大型轉換 (例如自動完成) 時保持回應速度。
Next.js 已實作新版轉送架構，預設使用 startTransition 進行路徑轉換。這可讓 Next.js 網站擁有者採用 React 時間限定功能，並改善路徑轉換的回應速度。
Angular
Angular 團隊正在探索下列幾項對於 INP 的助益：
- 無可用區：縮減初始套件大小，以及應用程式算繪任何內容之前必須載入的必要程式碼。
- 飲水量：以島型方式飲水，用來限制使用者需要喚醒多少應用程式才能互動。
- 減少持續推送軟體更新的負擔：例如，降低變更偵測成本、尋找如何減少應用程式的使用次數，以及利用變更項目的相關反應信號。
- 更精細的程式碼分割功能：縮小初始套件。
- 進一步支援載入指標：例如，在 SSR 重新轉譯期間、導航期間和延遲載入作業期間。
- 剖析工具：改善開發人員工具，以瞭解互動費用，特別是特定互動的變化偵測費用。
透過這些強化項目，我們得以解決導致回應速度和使用者體驗不佳的各種問題，並針對架構型網站提高 CWV 指標和新 INP 指標。
結論
我們期望 INP 分數能為網站提供更好的指南針，以提升日後的回應速度和成效。我們將以現有的 INP 指南為基礎，為 2023 年架構開發人員提供更多實用訣竅。我們希望透過以下方式來達成這個目標：
- 建立管道以便輕鬆存取 INP 中的實際資料，適用於架構和網頁開發人員。
- 運用架構建構各項功能，建構預設能改善 INP 的功能。
我們歡迎架構使用者在開始進行 INP 最佳化流程時提供意見回饋。