Ecomonic Times 將 TBT 的成長幅度減少 30 倍，改用 Next.js 後，INP 就減少了近四倍，跳出率降低 50%，網頁瀏覽量也提升了 43%。
與下一個顯示的內容互動 (INP) 指標可評估網站對使用者輸入內容的回應速度。良好的回應速度是指網頁能快速回應使用者互動。網頁的 INP 越低，回應使用者互動的能力越佳。
模糊開始
當 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 先前與前後之改進的研究室比較：
將主要執行緒的工作降到最低
瀏覽器的主要執行緒可以處理各種作業，包括剖析 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。透過它，我們得以找出在網頁載入期間，需要減少運送程式碼的區塊，進而縮減應用程式的初始組合大小。
縮減 DOM 大小
每個 Lighthouse 大型 DOM 大小會增加記憶體用量，進而延長樣式重新計算的時間，並產生昂貴的版面配置重排。
我們透過兩種方式減少了 DOM 節點數量：
- 首先，我們會在使用者的要求 (點擊時) 顯示選單項目。將 DOM 大小縮減約 1,200 個節點。
- 第二，我們延遲載入較不重要的小工具。
拜上述種種努力之賜，我們大幅減少了待定時間，INP 也因此降低了將近 50%：
現階段，我們幾乎沒有什麼好辦法獲得成功，以進一步降低待命 (然後由 Proxy 降低 INP)，但我們知道還有許多改進空間。這時，Google 決定將自訂建構的 UI 樣板升級為最新版的 React 同時使用 Next.js，以便妥善運用掛鉤，避免不必要的重新轉譯元件。
由於與網站的其他部分相比，更新頻率更高，流量也較少，因此我們開始將主題頁面遷移至 Next.js。我們也使用 PartyTown 將額外的大型主執行緒工作卸載給網路工作站，並使用 requestIdleCallBack 等技術延後非重要工作。
改善 INP 對經濟時間有何助益？
目前的 (TBT) 和 INP (來源)
在本文發布時，我們來源的待定時間未定為 120 毫秒，是我們開始最佳化作業的 3,260 毫秒。同樣地，我們經過最佳化調整後，來源的 INP 為 257 毫秒，倒數為 1,000 毫秒以上。
INP CrUX 趨勢
從主題網頁獲得的流量佔整體流量的比例明顯偏低。因此很適合用來進行實驗。CrUX 成果和業務成果都非常令人振奮，因此我們決定擴大整個網站的措施，取得更多好處。
Akamai mPulse TBT 分析
我們使用 Akamai mPulse 做為 RUM 解決方案，在實地測量數據未定。我們觀察到 TBT 的數量持續下降，明顯反映出我們為了減少 INP 所做的努力。如以下螢幕截圖所示，TBT 值最終在欄位中從約 5 秒降至約 200 毫秒。
業務成果
整體而言，我們努力讓 INP 減少了近 30 倍，再加上遷移至 Next.js，成功讓 INP 減少了近 4 倍，主題頁面的跳出率也下降了 50%，網頁瀏覽量也因而成長了 43%。
結論
總而言之，INP 可在眾多經濟時間網站上判斷某些執行階段效能問題。事實證明，這是對業務成果有正面影響的最有效指標之一。由於共同觀察到的數據非常可說，我們鼓勵我們將最佳化工作拓展到網站的其他部分，享受更多好處。