改進產品詳細資料頁面的互動性，將 Lighthouse 最大潛在 FID 降低 90%，以及 Chrome 使用者體驗報告的 FID 提高 9%。
Mercado Libre 是拉丁美洲最大的電子商務和付款生態系統。該公司目前已在 18 個國家/地區提供服務，也是巴西、墨西哥和阿根廷的市場領導者 (根據不重複訪客和瀏覽量來計算)。
網站效能長期以來一直是該公司的關注重點，但最近他們成立了一個團隊，負責監控效能並將網站各部分最佳化。
本文總結了 Mercado Libre 前端架構團隊的 Guille Paz、Pablo Carminatti 和 Oleh Burkhay 完成的工作，那就是首次輸入延遲時間 (FID) 及其研究室 Proxy 的總封鎖時間 (TBT)。
90%
Lighthouse 最大 FID 降幅
9%
更多使用者在 CrUX 認為 FID 是「快速」的原因
長時間工作、首次輸入延遲時間，以及總封鎖時間
執行昂貴的 JavaScript 程式碼可能會導致「長時間」工作，也就是在瀏覽器主執行緒中執行時間超過 50 毫秒的工作。
FID (首次輸入延遲時間) 會評估從使用者首次與網頁互動 (例如點選連結) 到瀏覽器實際開始處理事件處理常式以回應該互動所需的時間。執行昂貴 JavaScript 程式碼的網站，可能會有一些長時間的工作，進而對 FID 造成負面影響。
為提供良好的使用者體驗，網站應力求在 100 毫秒以下的首次輸入延遲時間內：
雖然 Mercado Libre 網站的大多數部分效能都很好，但根據 Chrome 使用者體驗報告，我們發現產品詳細資料頁面的 FID 不佳。根據這項資訊，他們決定將重心放在改善網站上產品頁面的互動性。
這些頁面可讓使用者執行複雜的互動，因此目標是在不干擾實用功能的情況下，進行互動性最佳化。
評估產品詳細資料頁面的互動性
FID 需要真實使用者，因此無法在研究室中測量。不過，「總封鎖時間 (TBT)」指標是可評估、與實際領域 FID 的關聯性，並擷取影響互動性的問題。
舉例來說，在下列追蹤記錄中，雖然主要執行緒上執行工作的「總時間」是 560 毫秒，但這段期間內只有 345 毫秒會視為「總封鎖時間」 (每個工作中超過 50 毫秒的部分總和)：
Mercado Libre 在研究室中採用 TBT 指標，藉此評估及改善實際產品詳細資料頁面的互動情形。
以下是他們採取的一般做法：
- 使用 WebPageTest 可判斷哪些指令碼能讓主要執行緒在實際裝置上保持忙碌狀態。
- 使用 Lighthouse 來判斷「Max Potential First Input Delay (Max Potential First Input Delay, Max Potential FID)」(最大潛在首次輸入延遲 (Max Potential FID))) 的變更所帶來的影響。
使用 WebPageTest 以視覺化方式呈現長時間的工作
WebPageTest (WPT) 是一種網路效能工具，可讓您在世界各地不同位置的實際裝置上執行測試。
Mercado Libre 利用 WPT 選擇與實際使用者相似的裝置類型和位置，重現使用者體驗。具體而言，他們選擇了一部 Moto 4G 裝置和維吉尼亞州迪爾斯，他們是為了要模擬墨西哥 Mercado Libre 的使用體驗。Mercado Libre 觀察 WPT 的主要執行緒檢視畫面後，發現有好幾個連續的長時間工作封鎖主執行緒 2 秒：
分析對應的瀑布後，發現這兩秒的大部分來自數據分析模組。應用程式的主要套件大小很大 (950 KB)，因此需要很長的時間才能剖析、編譯及執行。
使用 Lighthouse 判定 FID 最大潛力
Lighthouse 不允許使用者選擇不同裝置和位置，但很適合用來診斷網站及取得效能建議。
在產品詳細資料頁面中執行 Lighthouse 時，Mercado Libre 發現 Max Potential FID 是唯一標示為紅色的指標，且值為 1710ms。
因此，Mercado Libre 的目標是在 Lighthouse 和 WebPageTest 等實驗室工具中，提高其 Max FID 分數，其中假設這些改善項目會影響實際使用者，因此會顯示在 Chrome 使用者體驗報告等實際使用者監控工具中。
將長時間工作最佳化
首次疊代
Mercado Libre 根據主要執行緒追蹤記錄，設定為將兩個執行昂貴程式碼的模組最佳化。
他們開始最佳化內部追蹤模組的成效。這個模組包含會耗用大量 CPU 資源的工作，這對模組執行來說並不重要，因此可以安全移除。這也使得整個網站的 JavaScript 減少了 2%。
然後開始改善一般套件大小後：
Mercado Libre 使用 webpack-bundle-analyzer 來偵測最佳化的機會：
- 最初需要完整的 Lodash 模組。經由每種方法需要載入部分 Lodash 的子集 (而非整個程式庫)，並與 lodash-webpack-plugin 搭配使用，進一步縮減 Lodash。
此外，他們也套用了下列 Babel 最佳化功能：
- 使用 @babel/plugin-transform-runtime，在程式碼中重複使用 Babel 的輔助程式，並大幅縮減套件的大小。
- 在建構期間使用 babel-plugin-search-and-replace 取代憑證，以移除主要套件中的大型設定檔。
- 新增 babel-plugin-transform-react-remove-prop-types，藉由移除屬性類型來節省額外的位元組。
完成這些最佳化措施後，套件的大小已減少約 16%。
評估影響
Mercado Libre 連續長時間的工作將從 2 秒降至 1 秒：
Lighthouse 顯示，最大潛在首次輸入延遲時間減少了 57%：
第二次疊代
該團隊持續深入研究長時間的工作，以找出後續改善措施。
據此決定對這些異動進行下列調整：
- 繼續縮減主要套件大小，以便最佳化編譯和剖析時間 (例如移除不同模組中重複的依附元件)。
- 在元件層級套用程式碼分割功能，將 JavaScript 分成較小的區塊，以更聰明的方式載入不同元件。
- 延後元件飲水，以便更聰明地使用主執行緒。這項技巧通常稱為「部分水份」。
評估影響
產生的 WebPageTest 追蹤記錄會顯示更小的 JS 執行區塊：
此外，他們在 Lighthouse 的最長 FID 時間減少了 60%：
以視覺化方式呈現實際使用者的進度
雖然 WebPageTest 和 Lighthouse 等實驗室測試工具有助於在開發期間疊代解決方案，但真正的目標在於改善實際使用者體驗。
Chrome 使用者體驗報告可提供使用者體驗指標，讓 Chrome 使用者實際瞭解造訪熱門網路網頁的情形。如要取得報表資料，請在 BigQuery 中執行查詢、PageSpeedInsights 或 CrUX API。
CrUX 資訊主頁能以視覺化方式呈現核心指標的進度：
後續步驟
網站效能並非一蹴可幾，Mercado Libre 也瞭解這些最佳化措施為使用者帶來的價值。他們會繼續在網站上全面套用多項最佳化措施，包括在產品資訊頁面、圖片最佳化等項目中預先擷取，但在產品資訊頁面方面持續改善，以減少總封鎖時間 (TBT) 及 Proxy FID 等。這些措施包括：
- 疊代程式碼分割解決方案。
- 改善第三方指令碼的執行方式。
- 持續改善組合器層級的資產組合 (webpack)。
Mercado Libre 全面提升了效能，因此除了持續提升網站上的互動性，他們也開始評估另外兩個網站體驗核心指標 (LCP (最大內容繪製) 和 CLS (累計版面配置位移)) 的改進空間。