經濟時間修正 INP

將 TBT 降低 30 倍，並遷移至 Next.js，有助於 The Ecomonic Times 將 INP 降低近四倍，跳出率降低 50%，網頁瀏覽量則提升 43%。

Barun Kumar
Daya Ram Yadav
Daya Ram Yadav
LinkedIn
Saurabh Rajpal
Saurabh Rajpal
X

與下一個顯示的內容互動 (INP) 是一種指標，用於評估網站回應使用者輸入內容的速度。良好的回應速度代表網頁能迅速回應使用者互動。網頁的 INP 越低，回應使用者互動的效能就越好。

良好的 INP 值不超過 200 毫秒、低於 500 毫秒，甚至需要改善。

模糊的開端

當 Google 最初推出 INP 做為實驗指標，並有可能演變成 Core Web Vitals 指標時，Economic Times 團隊便接受了挑戰，在 INP 升格為 Core Web Vitals 指標前先行修正，因為提供世界級的使用者體驗對我們的核心業務價值至關重要。

INP 一直是目前最難解決的指標之一。一開始，我們不清楚如何有效評估 INP。由於缺乏社群支援，包括大多數真正的使用者監控 (RUM) 供應商尚未支援，這使得問題變得更加困難。不過，我們有 Google RUM 工具，例如 Chrome 使用者體驗報告 (CrUX)、web-vitals JavaScript 程式庫和其他支援工具，因此在評估未來方向時，我們可以掌握自身的現況。從一開始，我們的 INP 接近 1,000 毫秒的時間。

在實地修正 INP 時，我們發現其中一個可指定的實驗室指標可能是「總封鎖時間 (TBT)」。社群已為 TBT 提供完善的說明文件和支援服務。不過，雖然我們已達到 Core Web Vitals 的門檻，但在 TBT 方面，我們一開始的時間就超過 3 秒，因此表現不佳。

什麼是待定？我們採取了哪些措施來改善這個情況？

TBT 是實驗室指標，用於評估網頁在載入期間回應使用者輸入內容的速度。任何執行時間超過 50 毫秒的工作都會視為長時間工作，在 50 毫秒門檻後即稱為「封鎖時間」。

計算 TBT 時，系統會將網頁載入期間內所有長時間任務的阻斷時間加總。舉例來說，如果在載入期間有兩個長時間工作，系統會依下列方式判斷阻斷時間：

  • 工作 A 需要 80 毫秒 (超過 50 毫秒 30 毫秒)。
  • 工作 B 需要 100 毫秒 (50 毫秒超過 50 毫秒)。

網頁的 TBT 為 80 毫秒 (30 加 50)。TBT 越低越好，且與 INP 高度相關。

以下簡要比較我們實際採取的應變措施，以及採取改善措施後的成果：

這張合成圖片顯示 Chrome 開發人員工具效能面板中顯示的啟動期間長時間工作，以及網頁指標的報表。主執行緒在網頁載入期間遭到封鎖 3,260 毫秒。
啟動期間的主要執行緒，再進行待定 (TBT)。TBT 為 3,260 毫秒。
啟動期間長時間工作的複合圖片 (顯示在 Chrome 開發人員工具的效能面板中)，以及網頁指標報表。主執行緒在網頁載入期間遭到封鎖 120 毫秒。
在最佳化 TBT 後，啟動期間的主執行緒。TBT 為 120 毫秒。

將主執行緒的工作降到最低

瀏覽器的主執行緒會處理所有事項，從剖析 HTML、建構 DOM、剖析 CSS 和套用樣式，到評估及執行 JavaScript。主要執行緒也會處理使用者互動，即點擊、輕觸和按鍵動作。如果主要執行緒忙於執行其他工作，可能無法有效回應使用者輸入內容，並導致使用者體驗不佳。

這對我們來說是最困難的任務，因為我們有自己的演算法，可根據訂閱狀態和 A/B 版本測試、數據分析等的第三方指令碼，偵測使用者身分，以便放送廣告。

我們一開始採取小規模的做法，例如將較不重要的業務素材資源降為次要載入項目。其次，我們使用 requestIdleCallback 處理非關鍵工作，這有助於縮短 TBT。

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

建議您在使用 requestIdleCallback 時指定逾時，因為它可確保已經過了指定時間，且尚未呼叫回呼，它會在逾時後立即執行回呼。

縮短指令碼評估時間

我們也使用可載入的元件延遲載入第三方程式庫。此外，我們也使用 Chrome 開發人員工具中的涵蓋率工具分析網頁，藉此移除了未使用的 JavaScript 和 CSS。這有助於我們找出需要進行樹狀圖搖動的部分，以便在網頁載入期間減少程式碼數量，進而縮減應用程式的初始套件大小。

Chrome 開發人員工具中的涵蓋率工具螢幕截圖。在這裡，工具會顯示網頁載入期間未使用的 JavaScript 和 CSS 檔案部分。

縮減 DOM 大小

根據 Lighthouse 的說法，大型 DOM 會增加記憶體用量、延長樣式重新計算的時間，並產生費工的版面配置重排。

Lighthouse 中的 DOM 大小稽核螢幕截圖。回報的 DOM 元素數量為 2,706 個元素。

我們透過以下兩種方式減少 DOM 節點數量：

  • 首先，我們會在使用者要求 (點選) 時算繪選單項目。這項調整可將 DOM 大小縮減約 1,200 個節點。
  • 第二，延遲載入較不重要的小工具。

經過這些努力，我們大幅縮短了 TBT，結果 INP 也減少了將近 50%：

CrUX 中的 INP 稽核螢幕截圖。該網頁的 INP 為 539 毫秒，超出「差」的門檻。

目前，我們幾乎已經跑不了幾個簡單的方法，能進一步減少待定行程 (透過 Proxy 處理 INP)，但我們知道還有很大的改善空間。因此，我們決定將自訂 UI 樣板升級至最新版本的 React 和 Next.js，以便更有效地使用鉤子，避免不必要地重新轉譯元件。

由於主題網頁更新頻率較高，且相較於網站其他部分，流量較少，因此我們開始將這些網頁遷移至 Next.js。我們也使用 PartyTown 將額外的主要執行緒工作卸載給網路工作人員，並運用 requestIdleCallBack 之類的技術來延遲非關鍵工作。

改善 INP 對《經濟時報》有何幫助？

來源的目前 TBT 和 INP

在發布這篇文章時，我們的來源網址 TBT 為 120 毫秒，低於我們開始進行最佳化時的 3,260 毫秒。同樣地，在進行最佳化後，來源的 INP 從超過 1,000 毫秒降至 257 毫秒。

CrUX 中的 INP 稽核螢幕截圖。網頁的 INP 為 257 毫秒，達到「需要改善」門檻。

INP CrUX 趨勢

主題網頁的流量只佔整體流量的極小部分。因此，這裡是進行實驗的理想場所。我們從 CrUX 結果和業務成果中獲得了相當鼓舞人心的成果，因此決定擴大整個網站的相關努力，以便進一步發揮效益。

從 2022 年 7 月開始至 2022 年 10 月為止，為期四個月的 INP 分佈情形螢幕截圖，並以視覺化方式呈現在 CrUX 中。「不佳」和「需要改善」門檻內的值有些許下降，「良好」門檻內的值也增加。

Akamai mPulse TBT 分析

我們使用 Akamai mPulse 做為 RUM 解決方案，用於測量現場的 TBT。我們觀察到持續在 TBT 持續下降，因此清楚地對應我們為減少 INP 所採取的行動。如以下螢幕截圖所示，TBT 值最終從欄位的大約 5 秒內降至約 200 毫秒。

Akamai mPulse 中的圖表螢幕截圖，顯示大約一個月內的 TBT 下降情形。

業務成果

整體來說，我們將 TBT 降低了 30 倍，並遷移至 Next.js，因此 INP 減少了近 4 倍，最終導致主題網頁的跳出率降低 50%，網頁瀏覽量提升 43%。

Google Analytics 的螢幕截圖，比較網頁瀏覽量和跳出率。由於《經濟時報》公司針對 INP 進行了最佳化調整，跳出率降低了 50%，網頁瀏覽量也增加了 43%。

結論

總而言之，INP 廣泛協助我們找出 Economic Times 網站部分內容的執行階段效能問題。這項指標已證實是影響業務成果最有效的指標之一。我們發現這項努力帶來非常令人振奮的成果，因此我們決定將最佳化工作擴大到網站的其他部分，並獲得更多效益。