2021 年前端性能：測試和監控

已發表: 2022-03-10

快速總結↬讓2021年……快點！一份年度前端性能清單，包含您在當今 Web 上創建快速體驗所需了解的所有內容，從指標到工具和前端技術。自 2016 年以來更新。

測試和監控

您是否優化了審計工作流程？
這聽起來可能沒什麼大不了的，但是觸手可及的正確設置可能會為您節省大量測試時間。考慮使用 Tim Kadlec 的 Alfred Workflow for WebPageTest 向 WebPageTest 的公共實例提交測試。事實上，WebPageTest 有許多晦澀難懂的功能，因此請花時間學習如何閱讀 WebPageTest 瀑布視圖圖表以及如何閱讀 WebPageTest 連接視圖圖表以更快地診斷和解決性能問題。
您還可以從 Google 電子表格驅動 WebPageTest，並使用 Lighthouse CI 將可訪問性、性能和 SEO 分數整合到您的 Travis 設置中，或者直接整合到 Webpack 中。

看看最近發布的 AutoWebPerf，這是一個模塊化工具，可以自動收集來自多個來源的性能數據。例如，我們可以在您的關鍵頁面上設置每日測試，以捕獲來自 CrUX API 的現場數據和來自 PageSpeed Insights 的 Lighthouse 報告的實驗室數據。
如果你需要快速調試一些東西，但你的構建過程似乎非常慢，請記住“空白刪除和符號修改佔大多數 JavaScript 縮小代碼大小減少的 95%——而不是複雜的代碼轉換。你可以只需禁用壓縮即可將 Uglify 構建速度提高 3 到 4 倍。”

GitHub 的 Pull Request 通知的屏幕截圖，說明需要審核並且在成功解決檢查之前阻止合併 — 使用 Lighthouse CI 將可訪問性、性能和 SEO 分數集成到 Travis 設置中，將突出新功能對所有貢獻的開發人員的性能影響。（圖片來源）（大預覽）

您是否在代理瀏覽器和舊版瀏覽器中進行了測試？
在 Chrome 和 Firefox 中進行測試是不夠的。查看您的網站在代理瀏覽器和舊版瀏覽器中的工作方式。例如，UC 瀏覽器和 Opera Mini 在亞洲擁有重要的市場份額（在亞洲高達 35%）。測量您感興趣的國家/地區的平均互聯網速度，以避免未來出現重大意外。使用網絡限制進行測試，並模擬高 DPI 設備。 BrowserStack 非常適合在遠程真實設備上進行測試，並且還可以在您的辦公室中至少使用一些真實設備來補充它——這是值得的。

您是否測試過 404 頁面的性能？
通常，當涉及到 404 頁時，我們不會三思而後行。畢竟，當客戶端請求服務器上不存在的頁面時，服務器將響應 404 狀態代碼和相關的 404 頁面。它沒有那麼多，不是嗎？
404 響應的一個重要方面是發送到瀏覽器的實際響應正文大小。根據 Matt Hobbs 對 404 頁面的研究，絕大多數 404 響應來自丟失的網站圖標、WordPress 上傳請求、損壞的 JavaScript 請求、清單文件以及 CSS 和字體文件。每次客戶請求不存在的資產時，他們都會收到 404 響應——而且該響應通常是巨大的。

確保檢查和優化 404 頁面的緩存策略。我們的目標是僅在瀏覽器需要 HTML 響應時才向瀏覽器提供 HTML，並為所有其他響應返回一個小的錯誤負載。根據 Matt 的說法，“如果我們在源之前放置一個 CDN，我們就有機會在 CDN 上緩存 404 頁面響應。這很有用，因為沒有它，點擊 404 頁面可能會被用作 DoS 攻擊向量，通過強制源服務器響應每個 404 請求，而不是讓 CDN 以緩存版本響應。”
404 錯誤不僅會損害您的性能，而且還會影響流量，因此最好在您的 Lighthouse 測試套件中包含 404 錯誤頁面，並隨著時間的推移跟踪其分數。
您是否測試過 GDPR 同意提示的性能？
在 GDPR 和 CCPA 時代，依靠第三方為歐盟客戶提供選擇加入或退出跟踪的選項已變得很普遍。但是，與任何其他第三方腳本一樣，它們的性能可能會對整個性能工作產生相當大的破壞性影響。
當然，實際同意可能會改變腳本對整體性能的影響，因此，正如 Boris Schapira 所指出的，我們可能想要研究一些不同的 Web 性能配置文件：
- 完全拒絕同意，
- 同意被部分拒絕，
- 完全同意。
- 用戶尚未對同意提示採取行動（或提示被內容阻止程序阻止），
通常 cookie 同意提示不應該對 CLS 產生影響，但有時會產生影響，因此請考慮使用免費和開源選項 Osano 或 cookie-consent-box。
一般來說，值得研究彈出窗口的性能，因為您需要確定鼠標事件的水平或垂直偏移量，並正確定位彈出窗口相對於錨點的位置。 Noam Rosenthal 在文章 Web 性能案例研究：維基百科頁面預覽（也可作為視頻和會議紀要）中分享了 Wikimedia 團隊的學習成果。
您是否保留了性能診斷 CSS？
雖然我們可以包括各種檢查以確保部署非性能代碼，但通常快速了解一些可以輕鬆解決的容易實現的成果是有用的。為此，我們可以使用 Tim Kadlec 出色的性能診斷 CSS（靈感來自 Harry Roberts 的片段，該片段突出顯示延遲加載的圖像、未調整大小的圖像、舊格式圖像和同步腳本。
例如，您可能希望確保首屏上方的圖像不會被延遲加載。您可以根據需要自定義片段，例如突出顯示未使用的網絡字體，或檢測圖標字體。一個很棒的小工具，可以確保在調試過程中可以看到錯誤，或者只是快速審核當前項目。
```
/* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }
```

您是否測試過對可訪問性的影響？
當瀏覽器開始加載頁面時，它會構建一個 DOM，如果有像屏幕閱讀器這樣的輔助技術在運行，它還會創建一個可訪問性樹。然後，屏幕閱讀器必須查詢可訪問性樹以檢索信息並將其提供給用戶——有時是默認的，有時是按需提供的。有時這需要時間。
在談論快速交互時間時，通常我們指的是用戶可以通過單擊或點擊鏈接和按鈕與頁面交互的速度指標。屏幕閱讀器的上下文略有不同。在這種情況下，快速交互時間意味著屏幕閱讀器可以在給定頁面上宣布導航並且屏幕閱讀器用戶可以實際敲擊鍵盤進行交互之前經過了多少時間。

Leonie Watson 就可訪問性性能發表了令人大開眼界的演講，特別是緩慢加載對屏幕閱讀器公告延遲的影響。屏幕閱讀器習慣於快節奏的公告和快速導航，因此可能比有視力的用戶更沒有耐心。
使用 JavaScript 進行的大頁面和 DOM 操作將導致屏幕閱讀器公告延遲。幾乎每個平台（Jaws、NVDA、Voiceover、Narrator、Orca）上都有一個相當未開發的領域，可以使用一些注意力和測試作為屏幕閱讀器。
是否設置了持續監控？
擁有 WebPagetest 的私有實例總是有利於快速和無限制的測試。但是，具有自動警報的持續監控工具（如 Sitespeed、Calibre 和 SpeedCurve）可以讓您更詳細地了解您的表現。設置您自己的用戶計時標記來衡量和監控特定於業務的指標。此外，考慮添加自動性能回歸警報以監控隨時間的變化。

研究使用 RUM 解決方案來監控性能隨時間的變化。對於自動化的類似單元測試的負載測試工具，您可以使用 k6 及其腳本 API。另外，請查看 SpeedTracker、Lighthouse 和 Calibre。

2021 年前端性能：測試和監控

目錄

測試和監控

目錄