經濟時間修正 INP

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

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

與下一個顯示的內容互動 (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?我們採取了哪些步驟來改善 TBT?

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

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

  • 任務 A 需要 80 毫秒 (比 50 毫秒多 30 毫秒)。
  • 工作 B 需要 100 毫秒 (比 50 毫秒多 50 毫秒)。

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

以下是實驗室比較結果,比較改善前後的 TBT:

這張合成圖片顯示 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 毫秒,超出「差」的門檻。

目前,我們已幾乎找不到可以進一步降低 TBT (以及透過 Proxy 的 INP) 的簡單方法,但我們知道仍有許多進步空間。因此,我們決定將自訂 UI 樣板升級至最新版本的 React 和 Next.js,以便更有效地使用鉤子,避免不必要地重新轉譯元件。

由於主題網頁更新頻率較高,且相較於網站其他部分,流量較少,因此我們開始將這些網頁遷移至 Next.js。我們也使用 PartyTown,將其他繁重的主執行緒工作卸載至網路 worker,並搭配 requestIdleCallBack 等技術,延遲非關鍵工作。

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

來源的目前 TBT 和 INP

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

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

INP CrUX 趨勢

主題網頁的流量只佔整體流量的極小部分。因此,這裡是進行實驗的理想場所。我們從 Chrome 使用者體驗報告和業務成果中獲得許多啟發,因此決定在整個網站中擴大相關努力,以便進一步發揮效益。

這張螢幕截圖顯示 CrUX 在 2022 年 7 月至 10 月四個月期間,IAB 分布的視覺化資料。「不佳」和「需要改善」閾值內的值略有下降,而「良好」閾值內的值則有所增加。

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 的螢幕截圖,比較網頁瀏覽量和跳出率。在 The Economic Times 網站上對 INP 進行最佳化後,跳出率降低 50%,網頁瀏覽量則增加 43%。

結論

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