此個案研究說明偵錯及改善 INP 的逐步工作流程
發揮 Trendyol 所使用的 React，透過使用 PageSpeed 等 Google 工具
Insights (PSI)、Chrome 開發人員工具和 scheduler.yield API。
產品資訊頁面是電子商務網站的兩大關鍵要素 (PLP) 和產品詳細資料頁面 (PDP)。電子商務流量通常來自 產品資訊頁面 (無論是透過電子郵件廣告活動、社群媒體或 廣告。因此，您有必要確保 PLP 的使用體驗 縮短購買時間優先排序 使用者體驗品質是邁向成功的關鍵。研究出版品 例如《Milliseconds Make Millions》 網站效能對消費者的影響願意花錢和互動 與品牌合作
Trendyol 是一個電子商務平台，擁有約 3,000 萬名客戶， 240,000 名賣家幫助我們成為土耳其首家企業 定價超過 100 億美元，並成為 也讓整個世界變得更加美好
盡可能大規模提供最佳使用者體驗。 同時保有內容的彈性 《Reaction to Next Paint (INP)》是 Reaction 的重點指標，為達成以下目標的重點指標： 改善成效本個案研究說明 Trendyol 透過 PLP 顯示，INP 降低了 50%，搜尋次數也增加 1% 結果業務指標。
Trendyol 的 INP 調查程序
INP 會評估網站回應使用者輸入內容的回應速度。好的 INP 表示 瀏覽器可以快速可靠地回應所有使用者輸入內容 重新繪製網頁，這是使用者體驗良好的關鍵要素。
TrendP 改善 INP 的 PLP 歷程，首先針對以下項目進行全面分析： 使用者體驗。根據 PSI 報告 公司實際使用者體驗的 PLP 格式是 963 毫秒 行動版，如下圖所示。
為確保回應速度良好，網站擁有者應將 INP 設計為低於或等於 200 毫秒，也就是說，當時 Trendyol 的 INP 是 「不佳」範圍。
幸好，PSI 提供了「Chrome 使用者」頁面內網頁的欄位資料。
體驗報告 (CrUX) 和詳細的研究室診斷資料。看研究室
資料，Lighthouse 的 JavaScript 執行時間稽核指出
search-result-v2 指令碼佔用主執行緒的時間比其他執行緒更長
網頁指令碼
為了找出實際瓶頸，我們使用 Chrome 的效能面板 開發人員工具，以便排解 PLP 體驗問題，並找出 問題。在 Chrome 開發人員工具中以 4 倍 CPU 速度變慢，模擬行動裝置效能 在主執行緒上公開了 700 到 900 毫秒的長時間工作。如果 執行緒佔用其他工作的時間超過 50 毫秒， 無法及時回應使用者輸入的內容 使用者體驗
時間最長的工作是 Intersection Observer API 回呼 React 元件內的搜尋結果指令碼。我們現在也開始 可以將很長的任務拆成小塊給瀏覽器 有機會回應優先順序較高的工作，包括使用者互動。
結果證明，使用會觸發 React 的 setState 作業
在 Intersection Observer 回呼內重新轉譯的費用很高。
那麼在低階裝置上可能會佔用主執行緒
名稱過長。
開發人員曾經使用一種方法，將工作拆分為數個較小的工作
涉及setTimeout。我們已運用這項技巧，將
setState 呼叫至獨立工作。雖然 setTimeout 允許延後
JavaScript 執行作業，但沒有提供任何優先權。這個方向
加入 scheduler.yield 來源試用，為確保
產生主執行緒後，就繼續執行指令碼：
/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
if('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
entries.forEach(handleIntersection);
const maxNumberOfEntries = Math.max(...this.intersectingEntries);
if (Number.isFinite(maxNumberOfEntries)) {
await this.yieldToMain();
this.setState({ count: maxNumberOfEntries });
}
}, { threshold: 0.5 });
在 PLP 程式碼中加入這個產生的產生方法，表示 INP 已改善，因為 主要的長時間工作已分割為一系列較小的工作 例如使用者互動和後續轉譯工作 很快就會發生
請注意，Trendyol 使用 PuzzleJs 架構來實作微型前端 採用 React v16.9.0 的架構使用 React 18，仍可獲得相同的效能 但基於某些原因，Trendyol 無法升級 讓應用程式從可以最快做出回應的位置 回應使用者要求
出色業務成果
為評估導入後的 INP 改善成果，我們執行了 A/B 版本測試， 瞭解業務指標受到哪些影響整體而言，我們的 PLP 變更造成 包括 INP 減少 50% 及 1% 從產品資訊頁面前往產品詳細資料頁面的點閱率升幅 以及每個使用者工作階段在下圖中，可以看到 PLP 趨勢變化：
結論
最佳化 INP 是一個複雜的疊代過程，但方法可以較簡單 以便提供明確的工作流程輕鬆偵錯及改善 取決於您是否收集自有現場資料如果發生以下情況： 都建議從 PSI 和 Lighthouse 著手。找出問題後 您可以使用開發人員工具深入瞭解如何重現問題 以負載平衡機制分配流量 即可降低應用程式發生效能問題的風險
不時連結至主執行緒，為瀏覽器提供更多
讓網站快速回應，
都能改善使用者體驗較新的排程 API
例如 scheduler.yield() 可簡化這項工作
特別感謝 Jeremy Wagner、Barry Pollard 和 Houssein Djirdeh (來自 Google 和 Trendyol 工程團隊對這項工作的貢獻。