經濟時間修正 INP

Ecomonic Times 將 TBT 的成長幅度減少 30 倍,改用 Next.js 後,INP 就減少了近四倍,跳出率降低 50%,網頁瀏覽量也提升了 43%。

達拉拉姆亞達夫
Daya Ram Yadav
薩拉巴.拉吉帕爾 (Saurabh Rajpal)
Saurabh Rajpal

與下一個顯示的內容互動 (INP) 指標可評估網站對使用者輸入內容的回應速度。良好的回應速度是指網頁能快速回應使用者互動。網頁的 INP 越低,回應使用者互動的能力越佳。

良好的 INP 值介於 200 毫秒或更短的時間內,不佳的值必須超過 500 毫秒,而且需要改善。

模糊開始

當 Google 剛推出 INP 實驗指標,且可望發展到其中一項 Core Web Vitals 指標後,經濟時代團隊便接受挑戰,在才成為網站體驗核心指標的期間著手修正,因為提供世界級的使用者體驗對我們的核心業務價值至關重要。

INP 是目前最難解決的指標之一。一開始,我們不清楚如何有效評估 INP。其中最困難的是缺乏社群支援,包括多數真實使用者監控 (RUM) 供應商尚未支援這項技術。不過,我們有 Chrome 使用者體驗報告 (CrUX)web-vitals JavaScript 程式庫等 Google RUM 工具,因此在評估未來路徑時,已充分瞭解該工具的定位。開始之前,我們的 INP 在原始層級發生了將近 1,000 毫秒的距離。

修正領域的 INP 時,發現的其中一項研究室指標會是「Total Blocking Time (TBT)」。未定然而,儘管已達到網站體驗核心指標的門檻,但我們表現不如預期,因為我們開始時已有超過 3 秒。

什麼是 TBT?我們採取了哪些步驟來改善這個情況?

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

待定,計算方法是將網頁載入期間,所有長時間工作的封鎖時間加總。舉例來說,如果載入期間有兩個長時間的工作,封鎖時間將以下列方式決定:

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

網頁的 TBT 為 80 毫秒 (30 + 50)。TBT 值越低越好,且 TBT 也與 INP 密切相關

以下是我們完成的 TBT 先前與前後之改進的研究室比較:

啟動期間長時間工作的綜合圖片 (如 Chrome 開發人員工具的效能面板所示),以及網頁指標報告。載入網頁期間,主要執行緒會遭到封鎖 3,260 毫秒。
執行最佳化前的主要執行緒。待定為 3,260 毫秒。
啟動期間長時間工作的綜合圖片 (如 Chrome 開發人員工具的效能面板所示),以及網頁指標報告。主要執行緒在載入網頁期間遭到封鎖 120 毫秒。
最佳化 TBT 後啟動期間的主要執行緒。待定為 120 毫秒。

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

瀏覽器的主要執行緒可以處理各種作業,包括剖析 HTML、建立 DOM、剖析 CSS 及套用樣式,以及評估和執行 JavaScript。主要執行緒也會處理使用者互動,即點選、輕觸和按鍵互動。如果主要執行緒同時進行其他工作,可能無法有效回應使用者輸入內容,或可能導致使用者體驗異常。

這對我們來說是最艱難的任務,因為我們擁有自己的演算法,可根據訂閱狀態偵測使用者身分,並根據訂閱狀態和第三方指令碼 (用於 A/B 測試和分析等) 偵測使用者身分,然後據此放送廣告。

一開始,我們一開始只採取了小步驟,像是調降載入較不重要業務資產的優先順序。第二,我們針對非重要工作使用 requestIdleCallback,有助於減少待定。

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 個節點。
  • 第二,我們延遲載入較不重要的小工具。

拜上述種種努力之賜,我們大幅減少了待定時間,INP 也因此降低了將近 50%:

CrUX 中 INP 稽核的螢幕截圖。網頁的 INP 為 539 毫秒,超過「不良」門檻。

現階段,我們幾乎沒有什麼好辦法獲得成功,以進一步降低待命 (然後由 Proxy 降低 INP),但我們知道還有許多改進空間。這時,Google 決定將自訂建構的 UI 樣板升級為最新版的 React 同時使用 Next.js,以便妥善運用掛鉤,避免不必要的重新轉譯元件。

由於與網站的其他部分相比,更新頻率更高,流量也較少,因此我們開始將主題頁面遷移至 Next.js。我們也使用 PartyTown 將額外的大型主執行緒工作卸載給網路工作站,並使用 requestIdleCallBack 等技術延後非重要工作。

改善 INP 對經濟時間有何助益?

目前的 (TBT) 和 INP (來源)

在本文發布時,我們來源的待定時間未定為 120 毫秒,是我們開始最佳化作業的 3,260 毫秒。同樣地,我們經過最佳化調整後,來源的 INP 為 257 毫秒,倒數為 1,000 毫秒以上。

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

INP CrUX 趨勢

從主題網頁獲得的流量佔整體流量的比例明顯偏低。因此很適合用來進行實驗。CrUX 成果和業務成果都非常令人振奮,因此我們決定擴大整個網站的措施,取得更多好處。

於 2022 年 7 月至 2022 年 10 月,在 CrUX 中以視覺化方式呈現的 INP 發布情形螢幕截圖。「不佳」和「需要改善」閾值的值稍微下降,「良好」門檻的值則增加了。

Akamai mPulse TBT 分析

我們使用 Akamai mPulse 做為 RUM 解決方案,在實地測量數據未定。我們觀察到 TBT 的數量持續下降,明顯反映出我們為了減少 INP 所做的努力。如以下螢幕截圖所示,TBT 值最終在欄位中從約 5 秒降至約 200 毫秒。

Akamai mPulse 圖表的螢幕截圖,顯示一個月大約一個月內減少。

業務成果

整體而言,我們努力讓 INP 減少了近 30 倍,再加上遷移至 Next.js,成功讓 INP 減少了近 4 倍,主題頁面的跳出率也下降了 50%,網頁瀏覽量也因而成長了 43%

螢幕截圖:Google Analytics (分析) 比較網頁瀏覽量與跳出率。由於《The Economic Times》網站最佳化 INP,跳出率降低 50%,網頁瀏覽次數也提升了 43%。

結語

總而言之,INP 可在眾多經濟時間網站上判斷某些執行階段效能問題。事實證明,這是對業務成果有正面影響的最有效指標之一。由於共同觀察到的數據非常可說,我們鼓勵我們將最佳化工作拓展到網站的其他部分,享受更多好處。