RedBus 如何改善網站's Interaction to Next Paint (INP) 和銷售量提升 7%

INP 最佳化成功讓 redBus 的銷售量提升了約 7%

Amit Kumar
Amit Kumar
Saurabh Rajpal
Saurabh Rajpal

網頁及其功能正快速演進,您現在可以在網路上建立功能豐富且功能完整的網路體驗,以在功能方面實現許多原生應用程式。

JavaScript 是促進網路互動的主要動力,但如果不適合使用,互動可能會讓人覺得不太適應,並讓使用者認為網站沒有回應或完全毀損。幸好,我們建立「與下一個顯示的內容互動 (INP)」指標來解決這項特定使用者體驗問題。

INP 會評估在網頁生命週期中,與網頁互動的所有互動,並記錄一個代表網站回應使用者輸入內容速度的單一值。簡單來說,如果網頁的 INP 低於良好門檻,與同一個網頁的互動速度都能相當快速。

redBus 是印度的巴士訂票和售票網站,他們投入了大量心力改善自家網站的 INP,即使當時仍是實驗性指標也一樣。成果使他們提升了 7% 的銷售額,再次證明網站效能和業務健全度之間的關係。瞭解 redBus 採取哪些行動來改善自家網站的 INP。

首要目標

RedBus 決定將網站的 INP 最佳化時,心中只有一個目標:

  1. 無論網路速度和裝置功能為何,都應將重點放在互動延遲時間,讓使用者享有更優質的使用者體驗。
  2. 將網站最佳化,以盡快維持互動。
  3. 請確保 API 發出的回應盡可能精簡,進而確保資料快速傳輸至前端。

旅程

RedBus 將互動延遲時間分類的方式有兩種:

  1. 在用戶端封鎖 JavaScript 造成的互動延遲。如果互動使用過多的 JavaScript 會封鎖主執行緒,則轉譯作業會延遲,且會影響網頁的 INP。
  2. API 呼叫造成的網路延遲。雖然 INP 評估的網路活動不是 INP 所衡量的,但如果對遠端 API 呼叫所需的互動依賴於較慢的網路,或者如果要求會產生大量回應,便可能會覺得遲緩。

redBus 起初確信其網站的 INP 良好,但這項指標的真實使用者監控 (RUM) 資料在第 95 個百分位數顯示了不同的故事。

redBus 如何測量 INP

RedBus 依靠 Google 建立的 web-vitals JavaScript 程式庫,不只追蹤 INP,還能夠追蹤自家網站上所有網頁的所有重要使用者體驗指標。除了 web-vitals JavaScript 程式庫之外,redBus 也使用 ELK 分析前端收集的 INP 資料。

不過,您在該欄位追蹤網站 INP 的方式可能與 redBus 解決問題的方式大不相同。我們極力建議您先參閱「如何找出實際互動速度緩慢的情況」一文,瞭解在網站上追蹤 INP 的最佳做法,以及後續如何在研究室中重現這些程式碼,再開始最佳化互動

在 redBus 設立追蹤 INP 的系統後,他們就能分析資料,以便更好地瞭解互動現象發生在何處。

ELK 記錄系統回報 INP 值進行分析的螢幕截圖。
redBus 使用記錄系統的螢幕截圖,用於分析從欄位中收集的 INP 值,(按一下即可查看這張圖片的解析度較高的版本)。

用途

使用者在 redBus 網站上搜尋票價時,可以在搜尋頁面上變更日期,篩選已預定目的地的票價。變更這個頁面上日期的互動速度緩慢,而且是 INP 品質不佳的原因。

此外,當使用者捲動瀏覽票價時,系統會從 API 延遲載入其他票價。雖然捲動本身不會考量 INP 的測量方式,但 scroll 事件監聽器本身會安排許多必須在主執行緒上執行的工作。這項工作導致主要執行緒發生爭用情形,導致互動延遲增加,導致搜尋網頁上的 INP 不佳。

捲動時用來從 API 載入額外票價的延遲載入行為。(按一下即可查看這部影片的解析度較高的版本)。

redBus 如何最佳化搜尋頁面的 INP

為改善搜尋網頁的 INP,redBus 進行了多項最佳化:

  • 為減少事件回呼在特定時間內觸發的次數,scroll 事件處理常式已遭去彈跳。降低執行 scroll 事件回呼的頻率後,主執行緒就能更迅速地回應搜尋網頁上的使用者互動。
  • 產生的轉譯工作會使用 requestAnimationFrame 回呼優先處理。requestAnimationFrame 會告知瀏覽器必須在下一個影格之前完成回呼中的工作。
Chrome 開發人員工具的效能面板螢幕截圖,顯示 redBus 網站觸發捲動事件回呼 (未進行反彈跳)。導致主執行緒遭到封鎖。
注意事項:向事件回呼套用不展開彈跳的捲動處理常式。主執行緒存在大量封鎖工作,因而延遲互動。
Chrome 開發人員工具的效能面板螢幕截圖,顯示 redBus 網站觸發捲動事件回呼 (經過解碼)。結果導致主要執行緒的封鎖頻率較低,因為捲動事件處理常式觸發的頻率大幅降低。
套用後:套用瞭解除跳出的捲動處理常式觸發。捲動事件回呼會減少觸發頻率,讓主要執行緒有更多回應使用者互動的機會。

此外,我們也對搜尋結果網頁做了下列進一步的最佳化:

  • 系統在搜尋結果網頁的第二張到最後一張資訊卡中,系統擷取新的一批結果,以便提早觸發延遲載入作業,改善使用者體驗和視覺成效。
  • 延遲載入期間,每次網路呼叫擷取的結果較少。將擷取數量從 30 個減少為 10 個結果後,觀察到 INP 範圍從 870 減少到 900,減少至 350 至 370。
捲動時用來從 API 載入額外票價的延遲載入行為。(按一下即可查看這部影片的解析度較高的版本)。

雖然這些變更可大幅改善搜尋網頁的 INP,但搜尋網頁輸入欄位的 change 事件仍呼叫成本昂貴的縮減函式來更新使用者介面。這導致不必要的使用者介面重新轉譯,進而影響網頁的 INP。

使用者在輸入欄位輸入內容時,控制台中回報的 INP 值。在研究室設定中,觀察到的 INP 值 344 屬於「需要改善」門檻。(按一下即可查看這部影片的解析度較高的版本)。

為了最佳化這項互動,redBus 會在本機管理輸入元件的狀態,只有在輸入內容的 blur 事件觸發時,才會將其與 Redux 儲存庫同步處理。這項變更降低了重新算繪的數量,同時降低呼叫縮減器的頻率,避免不必要重新轉譯使用者介面。

改善 INP,因為減少在輸入欄位變更時呼叫縮減器的頻率。(按一下即可查看這部影片的解析度較高的版本)。

經過這項變更,該網頁的 INP 改善了 72%,讓使用者享有更快速、更流暢的體驗,因此更有可能與使用者互動。

業務影響

眾所周知,商家健康狀態和網頁成效之間的關係。雖然 INP 是與其他網站體驗核心指標相比的新指標,但 redBus 發現這項以使用者為中心的重要成效指標,因此獲得更出色的業務成果。結果整體的銷售額提升了 7%。

簡單來說,INP 協助了 redBus 網站上的執行階段效能問題。憑藉著實際的改善經驗,redBus 能夠觀察並重現問題,並利用這些重要資訊做出改進,造福 redBus 及其業務。