經濟時間修正 INP

將 TBT 縮短 30 倍並遷移至 Next.js,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 指標之一,因此經濟時間團隊在最終修正前就面臨了難題,因為提供世界級的使用者體驗,對我們的核心業務價值至關重要。

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

修正欄位 INP 時出現的情況,就是要指定的其中一個研究室指標可以是「Total Blocking Time (TBT)」。社群已詳加記錄並提供支援。雖然我們已經達到 Core Web Vitals 的門檻,但這個階段已超過 3 秒,因此在 TBT 初期的成效便不如預期。

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

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

待定值的計算方式是將網頁載入期間所有長時間工作的封鎖時間總和。例如,如果載入期間有兩個長時間的工作,則封鎖時間的判定方式如下:

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

網頁的 TBT 為 80 毫秒 (30 + 50)。TBT 值越低代表值越低越好,且與 INP 有良好的關聯

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

啟動期間長時間工作的複合圖片 (顯示在 Chrome 開發人員工具的效能面板中),以及網頁指標報表。主執行緒在網頁載入期間遭到封鎖 3,260 毫秒。
最佳化 (待定) 之前的主要執行緒。(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 樣板和 Next.js 升級至最新版 React,以便更有效地利用 掛鉤,避免不必要的重新算繪元件。

由於與網站其他網頁相比,更新頻率較高、流量相對較低,因此我們開始將主題頁面遷移至 Next.js。我們也使用 PartyTown 將額外的主要執行緒工作卸載給網路工作人員,並結合 requestIdleCallBack 等技術來延遲非關鍵工作。

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

目前的待定 (待定) 和 INP

發布這篇文章時,來源的預期作業時間從 3,260 毫秒縮短為 120 毫秒。同樣地,在我們完成最佳化作業後,我們來源的 INP 是從 1,000 毫秒來下降的 257 毫秒。

CrUX 中的 INP 稽核螢幕截圖。網頁的 INP 為 257 毫秒,與「需要改善」相符閾值

INP CrUX 趨勢

從主題網頁獲得的流量代表整體流量的一小部分。因此很適合用來進行實驗。由於 CrUX 的結果和業務成果都令人感到十分振奮,因此我們將投注心力在整個網站上,以便發揮更大的效益。

從 2022 年 7 月開始至 2022 年 10 月為止,為期四個月的 INP 分佈情形螢幕截圖,並以視覺化方式呈現在 CrUX 中。「不佳」的值和「需要改善」門檻值略低了,但「良好」的值起付額度提高。

Akamai mPulse TBT 分析

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

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

業務成果

整體而言,我們努力使 INP 低於 30 次,改用 Next.js 後,我們成功將 INP 降低近 4 倍,最終導致跳出率降低了 50%,網頁瀏覽量提升了 43%

Google Analytics 比較網頁瀏覽量與跳出率的螢幕擷取畫面。根據《經濟時報》網站進行的 INP 最佳化調整,跳出率降低了 50%,網頁瀏覽量也增加了 43%。

結論

總結來說,INP 廣泛協助判斷經濟時網站各部分的執行階段效能問題。事實證明,這是對業務成果帶來正面影響的最有效指標之一。由於這項努力帶來了非常令人振奮的成果,並積極將最佳化作業拓展到網站上的其他區域,以獲得額外的好處。