2021 年前端性能：設定切合實際的目標

本指南得到了我們在 LogRocket 的朋友的大力支持，LogRocket 是一項結合前端性能監控、會話重放和產品分析的服務，可幫助您建立更好的客戶體驗。 LogRocket跟踪關鍵指標，包括。 DOM 完成、第一個字節的時間、第一個輸入延遲、客戶端 CPU 和內存使用情況。 立即免費試用 LogRocket。

目錄

1. 準備：計劃和指標
2. 設定切合實際的目標
3. 定義環境
4. 資產優化
5. 構建優化
6. 交付優化
7. 網絡、HTTP/2、HTTP/3
8. 測試和監控
9. 快速獲勝
10. 一切都在一頁上
11. 下載清單（PDF、Apple Pages、MS Word）
12. 訂閱我們的電子郵件通訊不要錯過下一個指南。

設定切合實際的目標

1. 100 毫秒響應時間，60 fps。
   為了讓交互感覺流暢，界面有 100 毫秒來響應用戶的輸入。 再長一點，用戶就會認為應用程序滯後。 以用戶為中心的性能模型 RAIL 為您提供了健康的目標：為了允許 <100 毫秒的響應，頁面必須最遲在每 <50 毫秒後將控制權交還給主線程。 估計輸入延遲告訴我們是否達到了該閾值，理想情況下，它應該低於 50 毫秒。 對於動畫這樣的高壓點，能做的最好什麼都不做，不能做的絕對最少。

   

   此外，每一幀動畫應該在 16 毫秒內完成，從而達到每秒 60 幀（1 秒 ÷ 60 = 16.6 毫秒）——最好在 10 毫秒以下。 因為瀏覽器需要時間將新幀繪製到屏幕上，所以您的代碼應該在達到 16.6 毫秒標記之前完成執行。 我們開始討論 120fps（例如 iPad Pro 的屏幕以 120Hz 運行），Surma 已經介紹了一些 120fps 的渲染性能解決方案，但這可能不是我們目前正在關注的目標。

   對性能預期持悲觀態度，但對界面設計持樂觀態度並明智地使用空閒時間（檢查 idlize、idle-until-urgent 和 react-idle）。 顯然，這些目標適用於運行時性能，而不是加載性能。

2. FID < 100ms, LCP < 2.5s, TTI < 5s on 3G, 關鍵文件大小預算 < 170KB (gzipped)。
   雖然這可能很難實現，但一個好的最終目標是 Time to Interactive 低於 5 秒，而對於重複訪問，目標是低於 2 秒（只有通過服務人員才能實現）。 以 2.5 秒以下的最大內容繪製為目標，並最大限度地減少總阻塞時間和累積佈局偏移。 可接受的首次輸入延遲低於 100 毫秒至 70 毫秒。 如上所述，我們考慮的基準是 200 美元的 Android 手機（例如 Moto G4），在慢速 3G 網絡上，模擬 400ms RTT 和 400kbps 傳輸速度。

   我們有兩個主要的限制因素，它們有效地形成了在網絡上快速交付內容的合理目標。 一方面，由於 TCP 慢啟動，我們有網絡傳輸限制。 HTML 的前 14KB——10 個 TCP 數據包，每個 1460 字節，大約 14.25 KB，儘管不是字面意思——是最關鍵的有效負載塊，也是預算中唯一可以在第一次往返中交付的部分（由於移動喚醒時間，這是您在 400 毫秒 RTT 時 1 秒內獲得的所有數據）。

   

   （注意：由於 TCP 通常在很大程度上未充分利用網絡連接，因此 Google 開發了 TCP 瓶頸帶寬和 RRT（ BBR ），這是一種 TCP 延遲控制的 TCP 流量控制算法。專為現代網絡設計，它可以響應實際的擁塞，而不是像 TCP 那樣丟包，它明顯更快，具有更高的吞吐量和更低的延遲——並且算法的工作方式不同。（謝謝，維克多，巴里！ ）

   另一方面，由於 JavaScript 解析和執行時間，我們對內存和 CPU 有硬件限制（我們稍後會詳細討論）。 為了實現第一段中所述的目標，我們必須考慮 JavaScript 的關鍵文件大小預算。 對於預算應該是多少（這在很大程度上取決於您的項目的性質），意見各不相同，但 170KB JavaScript gzip 的預算已經在中端手機上解析和編譯需要 1 秒。 假設 170KB 在解壓後擴展為該大小的 3 倍（0.7MB），這可能是 Moto G4/G5 Plus 上“體面”用戶體驗的喪鐘。

   

   以 Wikipedia 網站為例，2020 年，在全球範圍內，Wikipedia 用戶的代碼執行速度提高了 19%。 因此，如果您的年度網絡性能指標保持穩定，這通常是一個警告信號，因為隨著環境的不斷改善，您實際上正在倒退（Gilles Dubuc 的博客文章中有詳細信息）。

   如果您想瞄準東南亞、非洲或印度等成長型市場，您將不得不考慮一組截然不同的限制條件。 Addy Osmani 涵蓋了主要的功能手機限制，例如低成本、高質量的設備、高質量網絡的不可用和昂貴的移動數據——以及這些環境的PRPL-30 預算和開髮指南。

   

   

   事實上，Google 的 Alex Russell 建議將 gzip 壓縮後的 130-170KB 作為合理的上限。 在現實世界的場景中，大多數產品甚至都沒有接近：今天的中位數捆綁大小約為 452KB，與 2015 年初相比增長了 53.6%。在中產階級移動設備上，這佔 12-20 秒的時間-To-Interactive 。

   

   不過，我們也可以超出捆綁包大小的預算。 例如，我們可以根據瀏覽器主線程的活動設置性能預算，即開始渲染之前的繪製時間，或跟踪前端 CPU 佔用情況。 Calibre、SpeedCurve 和 Bundlesize 等工具可以幫助您控制預算，並且可以集成到您的構建過程中。

   最後，性能預算可能不應該是一個固定值。 根據網絡連接，性能預算應該適應，但較慢連接的有效負載更加“昂貴”，無論它們如何使用。

   注意：在廣泛傳播的 HTTP/2、即將到來的 5G 和 HTTP/3、快速發展的手機和蓬勃發展的 SPA 時代，設置如此嚴格的預算可能聽起來很奇怪。 然而，當我們處理網絡和硬件的不可預測性時，它們聽起來確實是合理的，包括從擁擠的網絡到緩慢發展的基礎設施，再到數據上限、代理瀏覽器、保存數據模式和偷偷摸摸的漫遊費用。

目錄

1. 準備：計劃和指標
2. 設定切合實際的目標
3. 定義環境
4. 資產優化
5. 構建優化
6. 交付優化
7. 網絡、HTTP/2、HTTP/3
8. 測試和監控
9. 快速獲勝
10. 一切都在一頁上
11. 下載清單（PDF、Apple Pages、MS Word）
12. 訂閱我們的電子郵件通訊不要錯過下一個指南。