2021 年前端性能：規劃和指標

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

目錄

1. 準備：計劃和指標
   績效文化、Core Web Vitals、績效概況、CrUX、Lighthouse、FID、TTI、CLS、設備。
2. 設定切合實際的目標
   性能預算、性能目標、RAIL 框架、170KB/30KB 預算。
3. 定義環境
   選擇框架、基線性能成本、Webpack、依賴項、CDN、前端架構、CSR、SSR、CSR + SSR、靜態渲染、預渲染、PRPL 模式。
4. 資產優化
   Brotli、AVIF、WebP、響應式圖像、AV1、自適應媒體加載、視頻壓縮、網絡字體、谷歌字體。
5. 構建優化
   JavaScript 模塊、模塊/無模塊模式、tree-shaking、代碼拆分、範圍提升、Webpack、差異服務、Web Worker、WebAssembly、JavaScript 包、React、SPA、部分水合、交互導入、第 3 方、緩存。
6. 交付優化
   延遲加載、交叉點觀察器、延遲渲染和解碼、關鍵 CSS、流式傳輸、資源提示、佈局轉換、服務工作者。
7. 網絡、HTTP/2、HTTP/3
   OCSP 裝訂、EV/DV 證書、打包、IPv6、QUIC、HTTP/3。
8. 測試和監控
   審核工作流程、代理瀏覽器、404 頁面、GDPR cookie 同意提示、性能診斷 CSS、可訪問性。
9. 快速獲勝
10. 一切都在一頁上
11. 下載清單（PDF、Apple Pages、MS Word）
12. 訂閱我們的電子郵件通訊不要錯過下一個指南。

準備：計劃和指標

微優化對於保持性能正常運行非常有用，但牢記明確定義的目標至關重要——可衡量的目標會影響整個過程中做出的任何決策。 有幾種不同的模型，下面討論的模型非常固執——只要確保儘早設定自己的優先級即可。

1. 建立績效文化。
   在許多組織中，前端開發人員確切地知道常見的潛在問題是什麼以及應該使用什麼策略來解決這些問題。 然而，只要沒有對績效文化的既定認可，每個決策都會變成部門的戰場，將組織打碎成孤島。 您需要業務利益相關者的支持，並且要獲得它，您需要建立案例研究或概念證明，以證明速度（尤其是我們稍後將詳細介紹的核心 Web Vitals ）收益指標和關鍵績效指標（ KPI ）他們關心。

   例如，為了使性能更加有形，您可以通過顯示轉換率和應用程序加載時間以及渲染性能之間的相關性來揭示收入性能的影響。 或者搜索機器人的爬取率（PDF，第 27-50 頁）。

   如果開發/設計和業務/營銷團隊之間沒有強有力的一致性，績效將無法長期維持。 研究客戶服務和銷售團隊的常見投訴，研究高跳出率和轉化率下降的分析。 探索提高性能如何幫助緩解其中一些常見問題。 根據您正在與之交談的利益相關者群體調整論點。

   在移動設備和桌面設備上運行性能實驗並衡量結果（例如，使用 Google Analytics）。 它將幫助您使用真實數據建立公司量身定制的案例研究。 此外，使用 WPO Stats 上發布的案例研究和實驗數據將有助於提高企業對性能為何重要以及它對用戶體驗和業務指標的影響的敏感性。 但是，僅說明性能很重要是不夠的——您還需要建立一些可衡量和可跟踪的目標，並隨著時間的推移觀察它們。

   如何到那？ 在她關於建立長期績效的演講中，艾莉森麥克奈特分享了一個關於她如何幫助在 Etsy 建立績效文化的綜合案例研究（幻燈片）。 最近，Tammy Everts 談到了小型和大型組織中高效績效團隊的習慣。

   在組織中進行這些對話時，重要的是要記住，就像 UX 是一系列體驗一樣，Web 性能也是一種分佈。 正如 Karolina Szczur 指出的那樣，“期望一個數字能夠提供令人渴望的評級是一個有缺陷的假設。” 因此，績效目標需要細化、可跟踪和有形。

1. 目標：比你最快的競爭對手至少快 20%。
   根據心理學研究，如果你想讓用戶覺得你的網站比競爭對手的網站快，你需要至少快 20%。 研究您的主要競爭對手，收集有關他們在移動和桌面上的表現的指標，並設置有助於您超越他們的閾值。 不過，要獲得準確的結果和目標，請確保首先通過研究分析來全面了解用戶體驗。 然後，您可以模仿第 90 個百分位數的體驗進行測試。

   為了對競爭對手的表現有一個良好的第一印象，您可以使用 Chrome UX Report（ CrUX ，一個現成的 RUM 數據集，Ilya Grigorik 的視頻介紹和 Rick Viscomi 的詳細指南），或 Treo，一個 RUM 監控工具由 Chrome 用戶體驗報告提供支持。 這些數據是從 Chrome 瀏覽器用戶那裡收集的，因此報告將是特定於 Chrome 的，但它們會為您提供相當全面的性能分佈，最重要的是 Core Web Vitals 分數，分佈在您的各種訪問者中。 請注意，新的 CrUX 數據集在每個月的第二個星期二發布。

   或者，您也可以使用：

   • Addy Osmani 的 Chrome 用戶體驗報告比較工具，
   • 速度記分卡（還提供收入影響估算器），
   • 真實用戶體驗測試比較或
   • SiteSpeed CI（基於綜合測試）。

   注意：如果您使用 Page Speed Insights 或 Page Speed Insights API（不，它沒有被棄用！），您可以獲得特定頁面的 CrUX 性能數據，而不僅僅是聚合。 此數據對於為“著陸頁”或“產品列表”等資產設置性能目標可能更有用。 如果您使用 CI 測試預算，如果您使用 CrUX 設置目標，則需要確保您的測試環境與 CrUX 匹配（感謝 Patrick Meenan！ ）。

   如果您需要一些幫助來展示速度優先級背後的原因，或者您希望在性能較慢的情況下可視化轉換率衰減或跳出率增加，或者您可能需要在您的組織中倡導 RUM 解決方案，Sergey Chernyshev 構建了一個 UX 速度計算器，這是一個開源工具，可幫助您模擬數據並將其可視化以推動您的觀點。

   

   

   有時您可能想更深入一點，將來自 CrUX 的數據與您已經必須快速找出減速、盲點和低效率所在的任何其他數據相結合——為您的競爭對手或您的項目。 在他的工作中，Harry Roberts 一直在使用 Site-Speed Topography 電子表格，他用它來按關鍵頁麵類型分解性能，並跟踪它們之間的不同關鍵指標。 您可以將電子表格下載為 Google 表格、Excel、OpenOffice 文檔或 CSV。

   

   如果您想一路走下去，您可以在站點的每個頁面上運行 Lighthouse 性能審計（通過 Lightouse Parade），並將輸出保存為 CSV。 這將幫助您確定競爭對手的哪些特定頁面（或頁麵類型）表現更差或更好，以及您可能希望將精力集中在哪些方面。 （對於您自己的站點，最好將數據發送到分析端點！）。

   

   以這種方式收集數據、設置電子表格、削減 20% 並設置您的目標（績效預算）。 現在你有一些可測量的東西來測試。 如果您牢記預算並嘗試僅發送最少的有效負載以快速進行交互，那麼您就走在了合理的道路上。

   需要資源才能開始？

   • Addy Osmani 寫了一篇非常詳細的文章，內容涉及如何開始性能預算、如何量化新功能的影響以及超出預算時從哪裡開始。
   • Lara Hogan 關於如何使用性能預算進行設計的指南可以為設計師提供有用的指導。
   • Harry Roberts 發布了關於設置 Google Sheet 的指南，以顯示第三方腳本對性能的影響，使用 Request Map，
   • Jonathan Fielding 的績效預算計算器、Katie Hempenius 的 perf-budget-calculator 和 Browser Calories 可以幫助創建預算（感謝 Karolina Szczur 的提醒）。
   • 在許多公司中，績效預算不應該是雄心勃勃的，而是務實的，作為避免滑過某個點的標誌。 在這種情況下，您可以選擇過去兩週內最差的數據點作為閾值，然後從那裡獲取。 績效預算，務實地向您展示了實現這一目標的策略。
   • 此外，通過設置帶有圖表報告構建大小的儀表板，使性能預算和當前性能都可見。 有許多工具可以讓您實現這一目標：SiteSpeed.io 儀表板（開源）、SpeedCurve 和 Calibre 只是其中的一小部分，您可以在 perf.rocks 上找到更多工具。

   

   一旦你有了預算，就可以將它們整合到你的構建過程中，使用 Webpack Performance Hints 和 Bundlesize、Lighthouse CI、PWMetrics 或 Sitespeed CI，以強制執行拉取請求的預算，並在 PR 評論中提供分數歷史記錄。

   要將性能預算公開給整個團隊，請通過 Lightwallet 在 Lighthouse 中集成性能預算，或使用 LHCI Action 進行快速 Github Actions 集成。 如果你需要一些自定義的東西，你可以使用webpagetest-charts-api，一個端點API，從WebPagetest結果構建圖表。

   不過，性能意識不應僅來自性能預算。 就像 Pinterest 一樣，您可以創建一個自定義eslint規則，該規則禁止從已知依賴重的文件和目錄導入，並且會使包膨脹。 設置可以在整個團隊中共享的“安全”包列表。

   此外，考慮對您的業務最有利的關鍵客戶任務。 研究、討論和定義關鍵操作的可接受時間閾值，並建立整個組織已批准的“UX 就緒”用戶時間標記。 在許多情況下，用戶旅程將涉及許多不同部門的工作，因此在可接受的時間安排方面保持一致將有助於支持或阻止未來的性能討論。 確保增加的資源和功能的額外成本是可見和理解的。

   將績效工作與其他技術計劃相結合，從正在構建的產品的新功能到重構，再到接觸新的全球受眾。 因此，每次關於進一步發展的對話發生時，性能也是對話的一部分。 當代碼庫是新鮮的或剛剛被重構時，實現性能目標要容易得多。

   此外，正如 Patrick Meenan 所建議的，在設計過程中計劃加載順序和權衡是值得的。 如果您儘早確定哪些部分更關鍵，並定義它們應該出現的順序，您還將知道什麼可以延遲。 理想情況下，該順序也將反映 CSS 和 JavaScript 導入的順序，因此在構建過程中處理它們會更容易。 此外，請考慮在加載頁面時（例如，尚未加載 Web 字體時）處於“中間”狀態的視覺體驗應該是什麼。

   一旦你在你的組織中建立了強大的績效文化，目標是比你以前的自己快 20% ，以便隨著時間的推移保持優先事項的機智（謝謝，Guy Podjarny！ ）。 但是要考慮客戶的不同類型和使用行為（Tobias Baldauf 稱之為節奏和群組），以及機器人流量和季節性影響。

   計劃，計劃，計劃。 儘早進行一些快速的“唾手可得”優化可能很誘人——這可能是一個快速獲勝的好策略——但如果沒有計劃和設置現實，公司將很難將性能放在首位- 量身定制的績效目標。

1. 選擇正確的指標。
   並非所有指標都同樣重要。 研究哪些指標對您的應用程序最重要：通常，它將由您可以多快開始渲染界面中最重要的像素以及您可以多快為這些渲染像素提供輸入響應來定義。 這些知識將為您提供持續努力的最佳優化目標。 最後，定義體驗的不是加載事件或服務器響應時間，而是對界面感覺有多快的感知。

   這是什麼意思？ 與其關注整個頁面加載時間（例如，通過onLoad和DOMContentLoaded時間），不如優先考慮客戶認為的頁面加載。 這意味著專注於一組略有不同的指標。 事實上，選擇正確的指標是一個沒有明顯贏家的過程。

   根據 Tim Kadlec 的研究和 Marcos Iglesias 在他的演講中的筆記，傳統指標可以分為幾組。 通常，我們需要所有這些來全面了解性能，在您的特定情況下，其中一些會比其他更重要。

   • 基於數量的指標衡量請求的數量、權重和性能得分。 有利於發出警報和監控隨時間的變化，但不利於理解用戶體驗。
   • 里程碑指標使用加載過程生命週期中的狀態，例如Time To First Byte和Time To Interactive 。 適合描述用戶體驗和監控，不太適合了解里程碑之間發生的情況。
   • 渲染指標提供對內容渲染速度的估計（例如，開始渲染時間、速度指數）。 適合測量和調整渲染性能，但不適合測量重要內容何時出現並可以與之交互。
   • 自定義指標為用戶測量特定的自定義事件，例如 Twitter 的 Time To First Tweet 和 Pinterest 的 PinnerWaitTime。 適合準確描述用戶體驗，但不適合擴展指標和與競爭對手進行比較。

   為了完成這幅圖，我們通常會在所有這些組中尋找有用的指標。 通常，最具體和最相關的是：

   • 互動時間(TTI)
     佈局穩定的點，關鍵的網絡字體可見，主線程足以處理用戶輸入——基本上是用戶可以與 UI 交互的時間標記。 了解用戶必須等待多長時間才能無延遲地使用該網站的關鍵指標。 Boris Schapira 寫了一篇關於如何可靠地測量 TTI 的詳細文章。
   • 第一輸入延遲(FID)或輸入響應
     從用戶第一次與您的網站交互到瀏覽器實際能夠響應該交互的時間。 很好地補充了 TTI，因為它描述了圖片的缺失部分：當用戶實際與網站交互時會發生什麼。 僅用作 RUM 指標。 在瀏覽器中有一個用於測量 FID 的 JavaScript 庫。
   • 最大含量塗料(LCP)
     當頁面的重要內容可能已加載時，標記頁面加載時間線中的點。 假設頁面中最重要的元素是用戶視口中可見的最大元素。 如果元素在折疊的上方和下方都呈現，則只有可見部分被認為是相關的。
   • 總阻塞時間 ( TBT )
     有助於量化頁面在變得可靠交互之前的非交互性嚴重程度的指標（即，主線程在至少 5 秒內沒有運行超過 50 毫秒（長任務）的任何任務）。 該指標測量第一次繪製和交互時間 (TTI) 之間的總時間量，其中主線程被阻塞足夠長的時間以防止輸入響應。 因此，難怪低 TBT 是良好性能的良好指標。 （謝謝​​，阿爾喬姆，菲爾）
   • 累積佈局移位 ( CLS )
     該指標突出顯示了用戶在訪問網站時遇到意外佈局變化（重排）的頻率。 它檢查了不穩定的元素及其對整體體驗的影響。 分數越低越好。
   • 速度指數
     衡量頁面內容在視覺上填充的速度； 分數越低越好。 速度指數分數是根據視覺進度的速度計算的，但它只是一個計算值。 它對視口大小也很敏感，因此您需要定義一系列與您的目標受眾相匹配的測試配置。 請注意，隨著 LCP 成為更相關的指標，它變得不那麼重要了（感謝 Boris，Artem！ ）。
   • 花費的 CPU 時間
     一個指標，顯示主線程被阻塞的頻率和時間，用於繪畫、渲染、腳本和加載。 高 CPU 時間是janky體驗的明確指標，即當用戶在他們的操作和響應之間體驗到明顯的延遲時。 使用 WebPageTest，您可以在“Chrome”選項卡上選擇“捕獲開發工具時間線”，以在使用 WebPageTest 在任何設備上運行時公開主線程的故障。
   • 組件級 CPU 成本
     就像所花費的 CPU 時間一樣，這個由 Stoyan Stefanov 提出的指標探討了JavaScript 對 CPU 的影響。 這個想法是使用每個組件的 CPU 指令計數來單獨了解它對整體體驗的影響。 可以使用 Puppeteer 和 Chrome 來實現。
   • 挫折指數
     雖然上面提到的許多指標解釋了特定事件何時發生，但 Tim Vereecke 的 FrustrationIndex 關注的是指標之間的差距，而不是單獨查看它們。 它著眼於最終用戶感知到的關鍵里程碑，例如標題可見、第一個內容可見、視覺準備就緒和頁面準備就緒，併計算指示加載頁面時的挫敗程度的分數。 差距越大，用戶感到沮喪的機會就越大。 可能是用戶體驗的良好 KPI。 Tim 發表了一篇關於 FrustrationIndex 及其工作原理的詳細文章。
   • 廣告權重影響
     如果您的網站依賴於廣告產生的收入，那麼跟踪廣告相關代碼的權重很有用。 Paddy Ganti 的腳本構建了兩個 URL（一個正常，一個阻止廣告），通過 WebPageTest 提示生成視頻比較並報告一個增量。
   • 偏差指標
     正如 Wikipedia 工程師所指出的，您的結果中存在多少差異的數據可以告訴您您的儀器有多可靠，以及您應該對偏差和異常值給予多少關注。 較大的差異表明設置中需要進行調整。 它還有助於了解某些頁面是否更難以可靠地測量，例如由於第三方腳本導致顯著變化。 跟踪瀏覽器版本以了解推出新瀏覽器版本時的性能變化可能也是一個好主意。
   • 自定義指標
     自定義指標由您的業務需求和客戶體驗定義。 它要求您識別重要的像素、關鍵腳本、必要的 CSS 和相關資產，並衡量它們交付給用戶的速度。 為此，您可以監控英雄渲染時間，或使用性能 API，為對您的業務重要的事件標記特定時間戳。 此外，您可以通過在測試結束時執行任意 JavaScript 來使用 WebPagetest 收集自定義指標。

   請注意，第一次有意義的繪畫(FMP)沒有出現在上面的概述中。 它用於深入了解服務器輸出任何數據的速度。 Long FMP 通常表示 JavaScript 阻塞了主線程，但也可能與後端/服務器問題有關。 但是，該指標最近已被棄用，因為它在大約 20% 的情況下似乎不准確。 它被有效地替換為更可靠且更易於推理的 LCP。 Lighthouse 不再支持它。 仔細檢查以用戶為中心的最新性能指標和建議，以確保您在安全頁面上（感謝 Patrick Meenan ）。

   

   Steve Souders 詳細解釋了其中許多指標。 重要的是要注意，雖然 Time-To-Interactive 是通過在所謂的實驗室環境中運行自動審計來衡量的，但 First Input Delay 代表實際的用戶體驗，實際用戶會遇到明顯的滯後。 一般來說，始終測量和跟踪它們可能是一個好主意。

   根據您的應用程序的上下文，首選指標可能會有所不同：例如，對於 Netflix TV UI，按鍵輸入響應能力、內存使用率和 TTI 更為關鍵，而對於 Wikipedia，第一次/最後一次視覺變化和 CPU 時間花費指標更為重要。

   注意：FID 和 TTI 都不考慮滾動行為； 滾動可以獨立發生，因為它是脫離主線程的，所以對於許多內容消費網站來說，這些指標可能不那麼重要（謝謝，Patrick！ ）。

1. 測量和優化 Core Web Vitals 。
   長期以來，性能指標都是相當技術性的，專注於服務器響應速度和瀏覽器加載速度的工程視圖。 多年來，這些指標發生了變化——試圖找到一種方法來捕捉實際的用戶體驗，而不是服務器時間。 2020 年 5 月，Google 發布了 Core Web Vitals，這是一組以用戶為中心的新性能指標，每個指標都代表了用戶體驗的不同方面。

   對於其中的每一個，谷歌都推薦了一系列可接受的速度目標。 至少75% 的頁面瀏覽量應超過良好範圍才能通過此評估。 這些指標迅速獲得關注，隨著 Core Web Vitals 在 2021 年 5 月成為 Google 搜索的排名信號（頁面體驗排名算法更新），許多公司將注意力轉向了他們的績效得分。

   讓我們一一分解每個核心網絡生命力，以及有用的技術和工具，以優化您在考慮這些指標的情況下的體驗。 （值得注意的是，通過遵循本文中的一般建議，您最終會獲得更好的 Core Web Vitals 分數。）

   • 最大內容塗料( LCP ) < 2.5 秒。
     測量頁面的加載，並報告在視口中可見的最大圖像或文本塊的渲染時間。 因此，LCP 會受到所有延遲渲染重要信息的因素的影響——無論是服務器響應速度慢、CSS 阻塞、運行中的 JavaScript（第一方或第三方）、Web 字體加載、昂貴的渲染或繪畫操作、懶惰- 加載的圖像、骨架屏幕或客戶端渲染。
     
     為了獲得良好的體驗，LCP 應在頁面首次開始加載後的2.5 秒內發生。 這意味著我們需要儘早渲染頁面的第一個可見部分。 這將需要為每個模板定制關鍵 CSS，編排<head> -order 並預取關鍵資產（我們稍後會介紹）。

     LCP 分數低的主要原因通常是圖像。 要在 Fast 3G 上以 <2.5 秒的時間交付 LCP（託管在經過良好優化的服務器上，全是靜態的，沒有客戶端渲染並且圖像來自專用圖像 CDN）意味著最大理論圖像大小僅為 144KB 左右。 這就是為什麼響應式圖像很重要，以及提前預加載關鍵圖像（使用preload ）。

     快速提示：要發現頁面上的 LCP，在 DevTools 中，您可以將鼠標懸停在性能面板中“Timings”下的 LCP 徽章上（感謝 Tim Kadlec ！）。

   • 首次輸入延遲( FID ) < 100ms。
     衡量 UI 的響應能力，即瀏覽器在對離散的用戶輸入事件（如點擊或單擊）做出反應之前忙於其他任務的時間。 它旨在捕獲因主線程繁忙而導致的延遲，尤其是在頁面加載期間。
     
     目標是每次交互都保持在 50-100 毫秒內。 為此，我們需要識別長任務（阻塞主線程超過 50 毫秒）並將它們分解，將一個包代碼拆分為多個塊，減少 JavaScript 執行時間，優化數據獲取，延遲第三方的腳本執行，將 JavaScript 移動到 Web 工作者的後台線程，並使用漸進式水化來降低 SPA 中的再水化成本。

     快速提示：一般來說，獲得更好 FID 分數的可靠策略是通過將較大的捆綁包分解成較小的捆綁包並在用戶需要時提供所需的服務，從而最大限度地減少主線程上的工作，因此不會延遲用戶交互. 我們將在下面詳細介紹。

   • 累積佈局偏移( CLS ) < 0.1。
     測量 UI 的視覺穩定性以確保流暢和自然的交互，即頁面生命週期內發生的每次意外佈局轉換的所有單獨佈局轉換分數的總和。 每當已經可見的元素更改其在頁面上的位置時，就會發生單獨的佈局轉換。 它的評分基於內容的大小和移動的距離。
     
     因此，每次出現轉變時——例如，當備用字體和網絡字體具有不同的字體指標，或者廣告、嵌入或 iframe 遲到，或者圖像/視頻尺寸未保留，或者後期 CSS 強制重繪，或者更改由後期 JavaScript——它對 CLS 分數有影響。 良好體驗的推薦值是 CLS < 0.1。

   值得注意的是，Core Web Vitals 應該隨著時間的推移而發展，具有可預測的年度週期。 對於第一年的更新，我們可能期望將 First Contentful Paint 提升為 Core Web Vitals，降低 FID 閾值並更好地支持單頁應用程序。 我們可能還會看到負載增加後對用戶輸入的響應，以及安全、隱私和可訪問性 (!) 考慮。

   與 Core Web Vitals 相關，有很多有用的資源和文章值得研究：

   • Web Vitals 排行榜可讓您將自己的分數與移動設備、平板電腦、台式機以及 3G 和 4G 上的競爭對手進行比較。
   • Core SERP Vitals，一個 Chrome 擴展程序，可在 Google 搜索結果中顯示來自 CrUX 的 Core Web Vitals。
   • 佈局轉換 GIF 生成器，使用簡單的 GIF 可視化 CLS（也可從命令行獲得）。
   • web-vitals 庫可以收集核心 Web Vitals 並將其發送到 Google Analytics、Google Tag Manager 或任何其他分析端點。
   • 使用 WebPageTest 分析 Web Vitals，Patrick Meenan 在其中探討了 WebPageTest 如何公開有關 Core Web Vitals 的數據。
   • 使用 Core Web Vitals 進行優化，Addy Osmani 的 50 分鐘視頻，其中他重點介紹瞭如何在電子商務案例研究中改進 Core Web Vitals。
   • Cumulative Layout Shift in Practice 和 Cumulative Layout Shift in the Real World 是 Nic Jansma 撰寫的綜合性文章，幾乎涵蓋了有關 CLS 的所有內容，以及它與跳出率、會話時間或 Rage Clicks 等關鍵指標的關係。
   • What Forces Reflow，帶有屬性或方法的概述，當在 JavaScript 中請求/調用時，將觸發瀏覽器同步計算樣式和佈局。
   • CSS Triggers 顯示了哪些 CSS 屬性觸發了 Layout、Paint 和 Composite。
   • Fixing Layout Instability 是使用 WebPageTest 來識別和修復佈局不穩定問題的演練。
   • Cumulative Layout Shift, The Layout Instability Metric，Boris Schapira 關於 CLS 的另一個非常詳細的指南，它是如何計算的，如何測量以及如何優化它。
   • How To Improvement Core Web Vitals，Simon Hearne 關於每個指標（包括其他 Web Vitals，例如 FCP、TTI、TBT）的詳細指南，以及它們何時發生以及如何衡量。

   那麼，Core Web Vitals 是要遵循的最終指標嗎？ 不完全的。 它們確實已經暴露在大多數 RUM 解決方案和平台中，包括 Cloudflare、Treo、SpeedCurve、Calibre、WebPageTest（已經在幻燈片視圖中）、Newrelic、Shopify、Next.js、所有 Google 工具（PageSpeed Insights、Lighthouse + CI、Search控制台等）和許多其他。

   然而，正如 Katie Sylor-Miller 解釋的那樣，Core Web Vitals 的一些主要問題是缺乏跨瀏覽器支持，我們並沒有真正衡量用戶體驗的整個生命週期，而且很難關聯 FID 和具有業務成果的 CLS。

   由於我們應該期待 Core Web Vitals 不斷發展，因此始終將Web Vitals 與您定制的指標結合起來似乎是合理的，以更好地了解您在性能方面的立場。

2. 在代表您的受眾的設備上收集數據。
   為了收集準確的數據，我們需要徹底選擇要測試的設備。 在大多數公司中，這意味著研究分析並根據最常見的設備類型創建用戶配置文件。 然而，通常僅靠分析並不能提供完整的畫面。 很大一部分目標受眾可能會因為體驗太慢而放棄該網站（並且不再返回），因此他們的設備不太可能成為分析中最受歡迎的設備。 因此，另外對目標群體中的常用設備進行研究可能是一個好主意。

   根據 IDC 的數據，在 2020 年全球範圍內，所有出貨的手機中有 84.8% 是 Android 設備。 普通消費者每 2 年升級一次手機，在美國，手機更換週期為 33 個月。 全球最暢銷的手機平均售價不到 200 美元。

   那麼，一個具有代表性的設備是至少 24 個月大的 Android 設備，成本為 200 美元或更少，運行速度較慢，3G，400ms RTT 和 400kbps 傳輸，只是稍微悲觀一些。 當然，這對於您的公司來說可能會非常不同，但這已經足夠接近大多數客戶了。 事實上，為您的目標市場調查當前的亞馬遜暢銷書可能是一個好主意。 （感謝 Tim Kadlec、Henri Helvetica 和 Alex Russell 的指點！ ）。

   

   那麼選擇什麼測試設備呢？ 與上面概述的配置文件非常吻合的那些。 選擇稍舊的 Moto G4/G5 Plus、中端三星設備（Galaxy A50、S8）、中端設備（如 Nexus 5X、小米 Mi A3 或小米紅米 Note）是一個不錯的選擇7 和慢速設備，如 Alcatel 1X 或 Cubot X19，可能在開放設備實驗室中。 要在速度較慢的熱節流設備上進行測試，您還可以購買 Nexus 4，價格僅為 100 美元左右。

   此外，請檢查每台設備中使用的芯片組，不要過度代表一個芯片組：幾代 Snapdragon 和 Apple 以及低端的瑞芯微、聯發科就足夠了（謝謝，帕特里克！） 。

   如果您手頭沒有設備，可以通過在受限制的 3G 網絡（例如 300 毫秒 RTT、1.6 Mbps 下行、0.8 Mbps 上行）和 CPU 限制（5 倍減速）上進行測試來模擬台式機上的移動體驗。 最終切換到常規 3G、慢速 4G（例如 170 毫秒 RTT、9 Mbps 下行、9Mbps 上行）和 Wi-Fi。 為了使性能影響更加明顯，您甚至可以引入 2G 星期二或在辦公室設置節流 3G/4G 網絡以加快測試速度。

   請記住，在移動設備上，與台式機相比，我們應該期待 4 倍至 5 倍的減速。 移動設備具有不同的 GPU、CPU、內存和不同的電池特性。 這就是為什麼擁有一個普通設備的良好配置文件並始終在這樣的設備上進行測試很重要的原因。



幸運的是，有許多很棒的選項可以幫助您自動收集數據並根據這些指標衡量您的網站在一段時間內的表現。 請記住，良好的性能圖片涵蓋一組性能指標、實驗室數據和現場數據：

• 綜合測試工具通過預定義的設備和網絡設置（例如Lighthouse 、 Calibre 、 WebPageTest ）和
• 真實用戶監控( RUM ) 工具持續評估用戶交互並收集現場數據（例如SpeedCurve 、 New Relic——這些工具也提供綜合測試）。

前者在開發過程中特別有用，因為它可以幫助您在開發產品時識別、隔離和修復性能問題。 後者對於長期維護很有用，因為它將幫助您了解實時發生的性能瓶頸——當用戶實際訪問該站點時。

通過利用內置的 RUM API，例如導航計時、資源計時、繪製計時、長任務等，綜合測試工具和 RUM 一起提供了應用程序性能的完整圖景。 您可以使用 Calibre、Treo、SpeedCurve、mPulse 和 Boomerang、Sitespeed.io，它們都是性能監控的絕佳選擇。 此外，使用 Server Timing 標頭，您甚至可以在一個地方監控後端和前端性能。

注意：選擇瀏覽器外部的網絡級節流器總是更安全的選擇，例如，DevTools 與 HTTP/2 推送交互時存在問題，這是由於它的實現方式（感謝 Yoav，Patrick ！）。 對於 Mac OS，我們可以使用 Network Link Conditioner、Windows Windows Traffic Shaper、Linux netem 和 FreeBSD dummynet。

由於您可能會在 Lighthouse 中進行測試，請記住您可以：

• 使用 Lighthouse CI 隨時間跟踪 Lighthouse 分數（這非常令人印象深刻），
• 在 GitHub Actions 中運行 Lighthouse 以在每個 PR 旁邊獲得一份 Lighthouse 報告，
• 在站點的每個頁面上運行 Lighthouse 性能審計（通過 Lightouse Parade），輸出保存為 CSV，
• 如果您需要深入了解更多細節，請使用 Lighthouse 分數計算器和 Lighthouse 指標權重。
• Lighthouse 也可用於 Firefox，但在底層它使用 PageSpeed Insights API 並基於無頭 Chrome 79 用戶代理生成報告。

1. 設置“乾淨”和“客戶”配置文件進行測試。
   在被動監控工具中運行測試時，關閉防病毒和後台 CPU 任務、刪除後台帶寬傳輸並使用沒有瀏覽器擴展的干淨用戶配置文件進行測試以避免結果偏差（在 Firefox 和 Chrome 中）是一種常見策略。

   

   但是，研究您的客戶經常使用哪些瀏覽器擴展，並使用專門的“客戶”配置文件進行測試也是一個好主意。 事實上，某些擴展程序可能會對您的應用程序產生深遠的性能影響（2020 Chrome 擴展程序性能報告），如果您的用戶經常使用它們，您可能需要預先考慮。 因此，僅“乾淨”的配置文件結果就過於樂觀，在現實生活中可能會被粉碎。

2. 與您的同事分享績效目標。
   確保團隊中的每個成員都熟悉績效目標，以避免產生誤解。 每一個決定——無論是設計、營銷還是介於兩者之間的任何決定——都會對績效產生影響，在整個團隊中分配責任和所有權將簡化以後以績效為中心的決策。 根據性能預算和早期定義的優先級映射設計決策。

目錄

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