由于 FID 需要一個真實用戶的交互，所以無法用實驗數據測試。

為了在實驗數據下預測 FID，通常會用 TBT(Total Blocking Time)，具體這個指標后面文章會介紹。他們測量的內容不同，但改善 TBT 通常也能改善 FID。

一個糟糕的 FID 主要原因是JS執(zhí)行過長，優(yōu)化JS的解析、編譯、執(zhí)行可以直接降低 FID。

過長的JS執(zhí)行

當JS執(zhí)行過程中，瀏覽器無法響應用戶交互，因為主線程被占用，為了改善這點，可以:

• 分解長任務
• 優(yōu)化頁面，為交互準備
• 使用 Web Worker
• 減少JS執(zhí)行時間

分解長任務

如果你準備嘗試減少單個頁面的js的體積，可以先考慮把較長執(zhí)行的js代碼分解成小的異步任務。

長任務指的是用戶可能會發(fā)現頁面無響應的時期執(zhí)行的js代碼。任何阻塞主線程大于等于50ms的代碼都是長任務。長任務一般是js體積過大的潛在因素（瀏覽器加載并執(zhí)行了比頁面初始化所需要的更多的js）。

分解長任務可以降低用戶輸入延遲。

當你采用最佳實踐（例如拆分代碼、分解長任務），FID 會有顯著改善。雖然 TBT 并非現場數據指標，但這對于改善 FID 和 TTI(Time To Interactive) 都很有幫助。

優(yōu)化頁面，為交互準備

造成 FID 和 TBT 分數低有很多原因，大多都是js引起的。

自己站點的腳本執(zhí)行可能會延后交互

• JS體積過大，執(zhí)行時間過長，無效的分包會導致頁面響應用戶交互變慢，影響 FID、TBT、TTI。逐步加載代碼和功能塊可以拆分這些任務，提升響應速度。
• 服務端渲染看上去頁面是出來了，但用戶的交互還是受限于js的執(zhí)行時間，可以考慮把更多邏輯代碼放在服務端實現，或者在構建的時候創(chuàng)建更多靜態(tài)內容。

下圖是 TBT 得分的優(yōu)化前后對比。通過將非必須的昂貴的腳本的加載和執(zhí)行移出關鍵路徑，用戶就可以更快的去與頁面交互。

數據獲取會影響交互準備的很多方面

• 級聯的獲取數據的水流圖（包含js，數據的網絡請求等），會導致交互延遲。目的是要減少對級聯數據獲取的依賴。（減少請求數）
• 較大的內聯數據可以節(jié)省HTML的解析時間，同時影響繪制圖像和交互兩種指標。目的是要減少客戶端后續(xù)處理對數據的依賴。（數據在內聯已經準備好了，不需要額外請求）

第三方腳本的執(zhí)行可能會延后交互

• 很多網站都包含第三方庫的標簽和統(tǒng)計代碼，這些會導致網絡阻塞，使得主線程長時間無法響應，延后了交互。查找出必須加載的第三方代碼。（例如：不滾動到指定位置不展示廣告）
• 有時候，第三方的腳本會搶先于本站腳本加載，例如加載優(yōu)先級和帶寬限制。嘗試著優(yōu)先加載你覺得可以給用戶提供最有價值的東西。

使用 web worker

主線程阻塞是導致輸入延遲的主要因素之一。web worker可以讓你的代碼在后臺進程中執(zhí)行，把一些非UI的操作放在web worker中執(zhí)行可以減少主線程壓力，改善 FID 指標。

可以使用以下的庫，讓你的站點更方便的集成web worker:

• Comlink
• Workway
• Workerize

減少JS執(zhí)行時間

• 延后加載未使用的js
• 最小化無用的polyfill

延后加載未使用的js

通過開發(fā)者工具中的coverage的tab頁可以查看各資源的有效使用率。

為了減少無用JS，可以:

• 把你的代碼拆分成多個chunk，按需加載
• 使用 async 或者 defer 延后加載非關鍵腳本，包含第三方腳本

代碼拆分指的是將一個大的單個JS拆分成多個小的，根據條件去加載對應的JS。現代瀏覽器已經支持按需加載:

import('module.js') .then((module) => { // Do something with the module. });

除了常用瀏覽器支持以外，一些構建系統(tǒng)也支持:

• webpack，rollup，parcel等構建工具
• angular，react，vue等客戶端框架

除了可以使用代碼拆分，也可以使用 async 或者 defer 來延后加載非關鍵腳本。

<script defer src="…"></script> <script async src="…"></script>

除非有特殊原因，一般第三方腳本都可以默認采用這種方式加載。

最小化無用的polyfill

如果你用了一些js高級語法，你可能需要將這些代碼轉換成舊版瀏覽器支持的語法，或者引入polyfill來支持。

最好的做法是，如果瀏覽器支持這些語法，不引入polyfill。最小化無用的polyfill，并且將它們的使用限制在需要它們的環(huán)境中，可以降低js的體積。

優(yōu)化polyfill的使用，可以:

• 如果你是用babel轉義，使用 @babel/preset-env 可以只包含你需要支持的瀏覽器的polyfill。對于babel 7.9，可以開啟 bugfixes 配置，進一步減少無用的polyfill。
• 使用 module/nomodule 的模式傳輸兩份不同的bundle。（@babel/preset-env 也支持，可以通過 target.esmodules）

<script type="module" src="modern.js"></script> <script nomodule src="legacy.js" defer></script>

這樣可以保證支持js模塊的瀏覽器，可以加載模塊化的打包文件，不支持的瀏覽器可以加載轉義后的打包文件。

開發(fā)者工具

Lighthouse 6.0 不能測試 FID，因為它是一個現場數據指標，但是 TBT 可以作為替代品測試。針對 TBT 的優(yōu)化項對 FID 也同樣有效。

總結

實際項目的優(yōu)化需要頻繁的使用開發(fā)者工具 performance 和 lighthouse。針對長任務進行拆解，針對未使用的js進行移除，針對復雜的js使用web worker。最后再針對舊版瀏覽器和新版瀏覽器加載不同資源，以保證新版瀏覽器的對polyfill更少的依賴。如果使用webpack打包的項目，可以查看打包的分布圖，針對性的去優(yōu)化每一個bundle。

參考

https://web.dev/optimize-fid/

總結

以上是生活随笔為你收集整理的浏览器接收响应数据过大_交互响应性能之优化FID的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。