在智慧型電視和機上盒裝置上改善 Interaction to Next Paint (INP) 的效能，比在電腦瀏覽器上更具挑戰性，因為 API 支援有限，且系統規格不佳。本案例研究將說明 Disney+ Hotstar 如何成功克服這些障礙，進而獲得顯著的業務成效。
隨著客廳裝置的採用率增加，Disney+ Hotstar 意識到，在智慧型電視和機上盒的應用程式中提供流暢的瀏覽體驗，是重要的業務需求。不過，由於任何電視型號都可能使用非常舊的瀏覽器版本，因此要為這類裝置修正 INP 就更為困難。舉例來說，2020 年 LG TV 使用的是 2018 年發布的 Chrome 68 版。其中部分裝置也可能歸類為低階裝置，也就是說，它們無法像旗艦平板電腦和筆記型電腦一樣，快速回應互動。
下圖比較了在 Chrome 開發人員工具中，筆電 CPU 減速 6 倍與智慧型電視之間，載入網頁所需的時間。如您所見，筆記型電腦的速度仍遠高於近期製造的智慧型電視。
這些測試產生的實驗室資料，Disney+ Hotstar 開始使用 Web-Vitals 程式庫，從應用程式的實際使用者收集實地資料，針對互動到下一個繪圖 (INP) 收集資料，並發現 75% 的應用程式使用者在實地體驗中，遇到的 INP 為 675 毫秒，根據INP 門檻，這被視為「不佳」的使用者體驗。
本個案研究將說明 Disney+ Hotstar 如何改善串流應用程式的回應速度，特別是在低階裝置上。他們將 INP 值降至 272 毫秒，改善幅度達 61% ，雖然仍高於建議的「良好」門檻 200 毫秒，但已大幅改善。
發現項目
Disney+ Hotstar 使用 web-vitals 程式庫歸因版本中的 onINP 方法，對應用程式進行檢測。在初期階段，我們遇到了各種挑戰，尤其是在識別精確的目標元素時。這個問題的發生原因是，由於 Disney+ Hotstar 應用程式中使用了第三方空間導覽程式庫，因此所有參照都會指向主體，而這個程式庫只會監聽文件主體上的事件，接著判斷實際的聚焦元素，並根據按下遠端按鍵預測下一個聚焦位置。
Disney+ Hotstar 首先解決歸因問題，以便正確識別導致 INP 值偏高的互動。為此，Disney+ Hotstar 記錄了 focusKey 屬性，該屬性已存在於空間導覽程式庫中，用於目前聚焦的元素，以及網頁上所有可聚焦元素的對應項目，這類似於 web-vitals 歸因版本中的互動目標。
focusKey，以及觸發該元素的路徑。在適當的評估和歸因機制上路後，實地資料發現，以下互動對 INP 造成的影響最大：
- 橫向輪轉介面導覽。
- 垂直輪轉介面導覽。
- 初始網頁載入期間的互動。
在 Chrome 開發人員工具中使用效能面板分析這些互動後，我們發現空間導覽程式庫會讀取所有可聚焦元素的位置，並建立新的樹狀結構。這是一項耗費資源的作業，會在每次互動 (例如從一個元素移動到另一個元素) 時觸發版面配置衝突。
就首頁而言，空間導覽程式庫會產生樹狀結構，如下所示：
也就是說，如果應用程式顯示 10 個儲存格，且每個儲存格有 7 張資訊卡，則儲存格容器就會有 70 個可聚焦的元素，包括導覽項目。這是互動元素的數量過多。我們也使用了第三方輪轉介面程式庫，在水平瀏覽期間讀取每張資訊卡片的尺寸，以便轉譯容器，進而增加互動延遲時間。
修正問題
我們發現了幾個不同的問題，必須個別解決，才能解決整體應用程式的回應問題。
改善橫向匣導覽功能
Disney+ Hotstar 自行建構了輪轉介面程式庫，使用合成動畫，並在每個輪轉介面讀取一次尺寸，而非每張資訊卡讀取一次，因此不會觸發版面配置衝突。
空間導覽功能只會著重於輪轉介面的根目錄，如果要進一步進行水平導覽，自訂輪轉介面就會加入畫面。透過這種做法，Disney+ Hotstar 移除了空間導覽的依附元件，以及在每次導覽時讀取尺寸的舊型輪轉介面程式庫。
經過這些最佳化後，空間導覽樹狀圖如下所示。
以下圖片為 Chrome 開發人員工具的效能面板中，在導入輪轉介面前後測量到的效能比較。
這項工作成果讓 Disney+ Hotstar 的應用程式在該地區的 INP 大幅減少。他們也移除了第三方程式庫，節省了約 35 KB (經壓縮)。另外，這些改善措施也讓 Disney+ Hotstar 縮短了自訂指標的時間，因為他們用自訂指標來評估首頁的總算繪時間，而由於空間導覽節點減少，因此觸發版面配置的頻率也降低了。
改善垂直工具列導覽功能
Disney+ Hotstar 也改善了垂直格柵導覽功能的效能，改為延後載入格柵，而非預先載入所有格柵。因此，在網頁載入時，應用程式只會載入在檢視區可見的兩個容器，以及上方和下方的額外容器，而不會載入 10 個容器 (每個容器在內部都有一個輪轉介面元件和一堆圖片)。轉譯作業也會使用 setTimeout() 產生策略分割成多個工作，讓主執行緒有更多機會處理使用者互動。
初始網頁載入期間的互動
如果應用程式在啟動期間處理大量指令碼，INP 就會偏高。這是因為瀏覽器必須下載、剖析及評估這些指令碼。在這些情況下，主執行緒可能會長時間處於忙碌狀態，無法快速回應使用者互動。
Disney+ Hotstar 發現，在應用程式啟動期間 (啟動畫面時間)，系統處理的指令碼比實際需要的還多，因此後續網頁載入速度變慢。這會產生額外的腳本評估工作，也可能會對 INP 造成負面影響。
為解決這個問題，Disney+ Hotstar 考慮動態載入大部分的素材資源，以便在應用程式啟動期間節省時間。不過，由於 JavaScript 不會再提前載入，因此這項變更會增加往後網頁的導覽載入時間。為解決這個問題，Disney+ Hotstar 開發了內部資產預先載入器程式庫，可判斷使用者歷程中可能會出現哪個網頁，並預先載入該網頁的資產。例如：
- 使用者在登入頁面時，素材資源預先載入程式庫會為設定檔選取頁面預先載入素材資源。
- 在商家檔案選取頁面上，系統會載入首頁素材資源。
- 在首頁上，系統會載入詳細資料頁面的資產。
- 最後，觀賞頁面的資產會載入至詳細資料頁面。
最佳化素材資源載入作業可為 Disney+ Hotstar 帶來兩項好處：減少應用程式的 INP (因為主執行緒現在可以相對自由地執行使用者互動)，並減少低階裝置的記憶體用量。
這些變更導致從實地回報的 INP 數量減少 32%，如下方螢幕截圖所示。
其他改良功能
Disney+ Hotstar 也發現，在某些使用者事件中，有長時間的任務可以透過經常產生至主執行緒進行分割，並進一步建立任務產生器公用程式，讓使用者在執行任務期間取消任務。
舉例來說，當使用者瀏覽資訊列中的多個資訊卡時，會發生以下情況：
- 系統會將焦點放在下一個資訊卡。
- 系統會視需要翻譯資訊卡。
- 已更新聚光燈。
- 擷取預告片 (如有)，並開始播放。
- 系統會為該動作觸發 Analytics 事件。
如果使用者在這個過程中將焦點放在下一個資訊卡，則系統就不需要執行其餘步驟。舉例來說，如果使用者已移至下一個資訊卡，就不需要再擷取特定電影的預告片，也不需要初始化播放器。因此，這些工作可以中止，以便釋放主執行緒。
Disney+ Hotstar 的任務產生器公用程式會接受任務函式，當另一個任務在執行期間出現時，系統會中止先前的任務，避免執行不必要的任務，並迅速執行必要任務。
結果
整體而言，Disney+ Hotstar 的應用程式 INP 從 675 毫秒降至 272 毫秒，改善幅度近 60%！此外，工具列互動延遲時間也從約 400 毫秒降至約 100 毫秒。
對業務的影響：每位使用者的每週資訊卡瀏覽次數從 111 次增加到 226 次！這代表使用者停留時間增加了 100%，顯示更快速、更即時的介面更能吸引使用者長時間停留。
這只是開始，Disney+ Hotstar 才剛開始以 INP 指標為指南，改善算繪和互動成效。他們的團隊很高興在不久的將來，能為客戶提供流暢的 Disney+ Hotstar 體驗。
感謝 Disney+ Hotstar 的 Ayush、Ajay、Kiran、Milan 和 Richa 盡力扭轉局面。
特別感謝 Disney+ Hotstar 工程總監 Ankeet Maini 和 Disney+ Hotstar 客戶體驗總監 Rahul Krishnan P 支持這項創新工作，以及 Google 的 Jeremy Wagner、Gilberto、Barry Pollard 和 Brendan Kenny 審查並協助發布本案例研究。