瞭解新的 INP 指標如何影響使用 JavaScript 架構和程式庫建構的網站體驗。
Chrome 最近在 Chrome 使用者體驗報告中推出了新的實驗性回應度指標。這項指標現在稱為「與下一個顯示的內容互動」，用於評估網頁回應使用者互動的整體效能。今天，我們想分享一些洞察資料，說明使用新式 JavaScript 架構建構的網站在這個指標方面表現如何。我們想討論為什麼 INP 與架構相關，以及 Aurora 和架構如何協助提升回應速度。
背景
Chrome 會使用 First Input Delay (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 有何影響？
實驗室觀察到的總封鎖時間 (TBT) 與實驗場地的 INP 值高度相關。這可能表示任何長時間阻斷主執行緒的指令碼，都會對 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、Nuxt.js、Gatsby 和 Angular 合作，提供解決方案，在架構中提供強大的預設值，以便提升效能。以下是我們在這個情況下的工作重點：
React 和 Next.js：Next.js 指令碼元件可協助解決因載入第三方指令碼效率不佳而導致的問題。Next.js 推出了精細區塊處理功能，可讓共用程式碼的區塊變得更小。這有助於減少所有網頁下載的未使用通用程式碼數量。我們也與 Next.js 合作，將 INP 資料納入其 Analytics 服務。
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：
- Zoneless：減少初始套件大小，以及應用程式在轉譯任何內容前必須載入的必要程式碼。
- Hydration：島嶼式補充，限制應用程式需要喚醒多少次才能進行互動。
- 減少 CD 的額外負擔：例如，降低變更偵測的成本、找出減少應用程式檢查次數的方法，以及利用有關變更的回應式信號。
- 更精細的程式碼分割：讓初始套件變得更小。
- 更完善的載入指標支援：例如在 SSR 重新算繪、路徑導覽和延遲載入作業期間。
- 剖析工具：更優質的開發工具，可瞭解互動成本，特別是特定互動行為的變更偵測成本。
透過這些強化功能，我們可以解決導致回應速度和使用者體驗不佳的各種問題，並提升 CWV 指標和以架構為基礎的網站的新 INP 指標。
結論
我們希望 INP 分數能成為網站的最佳指南，協助網站改善回應速度和效能。我們將在 2023 年，以現有的 INP 指南為基礎，為架構開發人員提供更多實用的提示。我們希望透過以下方式達成這項目標：
- 建立頻道，方便架構和網頁開發人員輕鬆存取 INP 的欄位資料。
- 使用架構建構功能，預設改善 INP。
歡迎架構使用者在開始進行 INP 最佳化時提供意見回饋。