2018 前端性能優化清單 —— 第一部分

• 原文地址：Front-End Performance Checklist 2018 - Part 1
• 原文作者：Vitaly Friedman
• 譯文出自：掘金翻譯計劃
• 本文永久鏈接：https://github.com/xitu/gold-miner/blob/master/TODO/front-end-performance-checklist-2018-1.md
• 譯者：tvChan
• 校對者：mysterytony ryouaki

下面你將會看到你可能需要考慮到的前端性能優化問題，以保證你的應用具有快速和流暢的響應時間。

• 2018 前端性能優化清單 —— 第一部分
• 2018 前端性能優化清單 —— 第二部分
• 2018 前端性能優化清單 —— 第三部分
• 2018 前端性能優化清單 —— 第四部分

做好準備：計劃和指標

微小的優化對於保持性能來說都是很重要的，但是在頭腦中明確的定義 —— 可衡量的目標才是至關重要的。這將會影響你整個過程中做出的任何決定。有幾種不同的模型，下面討論的模型都很有自己的主見 —— 只要確保在一開始能設定自己的優先順序就行。

1. 建立性能指標。

在許多組織里，前端開發人員確切的知道常見的潛在問題是什麼，並且知道使用什麼載入模塊來修復它們。然而，只要開發/設計和營銷團隊之間沒有一致性，性能就不能長期維持。研究客戶服務中的常見投訴，了解如何提高性能，可以幫助解決這些常見問題。

在移動和桌面設備上運行性能實驗和測量結果。它將幫助你的公司量身定做一個根據真實數據而得到的研究案例。此外，利用 WPO 統計 數據對案例進行研究和實驗，可以幫助提高業務對性能問題的敏感度，以及它對用戶體驗和業務指標的影響。僅僅說明性能問題是遠遠不夠的 —— 你也需要建立一些可衡量和可跟蹤的目標並對它們進行觀察。

1. 目標：至少要比你最快的競爭對手還快 20%。

根據心理學的研究，如果你想讓用戶感覺你的網站比競爭對手的快，你至少需要比它們快 20%。 研究你的主要競爭對手，收集它們是怎麼在手機和桌面設備上展示的數據，並且設置閥值來幫助你超過它們。要獲取準確的結果和目標，首先要研究你的分析結果，看看你的用戶都在做什麼。然後，你可以模擬第百分之九十位的實驗進行測試。收集數據，創建一個 電子數據表，從中剔除 20%, 並制定你的目標（即 性能預算）。現在你就有一些可以測試的東西了。

如果你希望保持現在的成本不變，並儘可能的少寫一些腳本，就能有一個快速的可交互時間。那麼你已經走在正確的道路上了。勞拉.霍根的指導你如何用性能預算接近設計 里提供了有用的方向，設計人員，性能預算計算者和 Browser Calories 可以幫助我們創建預算（感謝 Karolina Szczur的牽頭）。

除了性能預算之外，還要考慮對你的業務最有利的關鍵客戶任務。設置和討論可接受的關鍵行為的時間閾值，並建立整個項目組都已經同意的 ＂UX 就緒＂的用戶計時標記。在許多情況下，用戶的需求將會影響到許多不同部門的工作。因此, 在可接受的時間內進行調整，將有助於支持或避免了在優化路上的性能討論。確保增加資源和功能的額外成本是可預見和可理解的。

此外, 正如 Patrick Meenan 建議的，在設計過程中制定一個載入順序及其權衡是非常值得。如果你在早期優先考慮哪些部分更重要，並且定義了它們應該出現的順序，那麼你也將知道哪些部分可以延遲。在理想情況下，該順序還將反映 CSS 和 JavaScript 的導入順序。因此，在構建過程中處理它們會更容易。此外，在載入頁面時，請考慮在"中間"狀態下的視覺體驗 (例如，web 字體尚未載入時)。

計劃，計劃，計劃。在早期的優化里，它可能像是誘人的＂熟水果＂ —— 最終它可能是一個很好的能快速取勝的策略 —— 但是，如果沒有計劃和切合實際的、為公司量身定製的性能目標，就很難將性能放在首位。

1. 選擇正確的指標。

並不是所有的指標都同樣重要。研究哪些標準對你的應用程序最重要：通常它與你開始渲染那些最重要的像素點（以及它們是什麼）有多快和如何快速地為這些渲染的像素點提供輸入響應有關。這可以幫助你為後續的工作提供最佳的優化結果。不管怎樣，不要專註於整個頁面的載入時間（例如，通過 onLoad 和 DOMContentLoaded 計時），而是優先載入用戶認為重要的頁面。這意味著要專註於一組稍有不同的指標。事實上，選擇正確的指標是一個沒有對手的過程。

首次有內容渲染，首次有效渲染，視覺完整和可交互時間之間的區別。大圖。來自於：@denar90

下面是一些值得考慮的指標：

• 首次有效渲染（FMP，是指主要內容出現在頁面上所需的時間），
• 英雄渲染時間（頁面最重要部分渲染完成所需的時間），
• 可交互時間（TTI，是指頁面布局已經穩定，關鍵的頁面字體已經可見，主進程可以足夠的處理用戶的輸入 —— 基本的時間標記是，用戶可以在 UI 上進行點擊和交互），
• 輸入響應，介面響應用戶操作所需的時間，
• 速度指標，測量填充頁面內容的速度。 分數越低越好，
• 你的自定義指標，由你的業務需求和客戶體驗來決定。

Steve Souders 對每個指標都進行了詳細的解釋。在許多情況下，根據你的應用程序的上下文，可交互時間和輸入響應會是最關鍵的。但這些指標可能會不同：例如，對於 Netflix 電視的用戶界面來說，關鍵輸入響應、內存使用和可交互時間更為重要。

1. 從具有代表性的觀眾的設備上收集數據。

為了收集準確的數據，我們需要徹底的選擇要測試的設備。也許在一個開放式的實驗室里，Moto G4 是一個很好的選擇，它是一款中檔的三星設備又或者是一個普通的設備，如 Nexus 5X。如果你手邊沒有設備，可以在節流網路（例如，150 ms 的往返時延，1.5 Mbps 以下，0.7 Mbps 以上）上使用節流 CPU（5× 減速）實現在桌面設備上模擬移動設備的體驗。最終，切換到常規的 3G，4G 和 wi-fi。為了使性能體驗的影響更明顯，你甚至可以在你的辦公室里引入 2G Tuesdays 計劃或者設置一個節流的 3G 網路，以便進行更快的測試。

引入一周中最慢的一天。Facebook推出了周二 2G 計劃，以提高對低速連接的能見度和靈敏度。（圖片來源）

幸運地是，有許多很好的選項可以幫助你自動的收集數據，並根據這些指標來衡量在一段時間內你的網站的運行情況。請記住，良好的性能指標是被動和主動監測工具的組合：

• 被動監測工具，是那些模擬用戶交互請求（綜合測試，如Lighthouse，WebPageTest）和
• 那些不斷記錄和評價用戶交互行為的主動監測工具（真正的用戶監控，如 SpeedCurve，New Relic —— 這兩種工具也提供綜合測試）

前者是在開發過程中特別有用，因為它能幫助你在產品開發過程中持續跟蹤。後者對於長期維護很有用，因為它能幫助你了解用戶在實際訪問站點時的性能瓶頸。利用內置的 RUM API，如導航計時，資源計時，渲染計時，長任務等，被動和主動的性能監測工具可以一起為你的應用程序提供完整的性能視圖。例如，你可以使用PWMetrics，Calibre，SpeedCurve，mPulse，Boomerang 和 Sitespeed.io，這些都是性能監測工具的絕佳選擇。

注意：選擇網路級別的節流器（在瀏覽器外部）總是比較安全的，例如，DevTools 與 HTTP/2 推送的交互問題，是因為它的實現方式。（感謝 Yoav!）

Lighthouse一個集成在 DevTools 的性能檢測工具。

1. 與你的同事分享性能清單。

為了避免誤解，要確保你團隊里的每個同事都對清單很熟悉。每個決策都對性能有影響。項目將極大地受益於前端開發人員正確地將性能價值傳達給整個團隊。這樣每個人都會對它負責，而不僅僅是前端開發人員。根據性能預算和核對表中定義的優先順序映射設計決策。

RAIL，以用戶為中心的性能模型。

制定現實的目標

1. 60 fps，100 毫秒的響應時間。

為了讓交互感覺起來很順暢，介面有 100ms 來響應用戶的輸入。任何比它長的時間，用戶都會認為該應用程序很慢。RAIL，一個以用戶為中心的性能模型會為你提供健壯的目標。為了讓頁面達到小於 100ms 的響應，頁面必須要在在每小於 50ms 前將控制返回到主線程。預計輸入延遲時間會告訴我們，如果我們能達到這個門檻，在理想情況下，它應該低於 50ms。對於像動畫這樣的高壓點，最好不要在你能做到的地方做任何事，也不要做你不能做到的事。

同時，每一幀動畫應該要在 16 毫秒內完成，從而達到 60 幀每秒（1秒 ÷ 60 = 16.6 毫秒） —— 最好在 10 毫秒。因為瀏覽器需要時間將新框架繪製到屏幕上，你的代碼應該在觸發 16.6 毫秒的標誌前完成。保持樂觀和明智地利用空閑時間。顯然，這些目標適用於運行時的性能，而不是載入性能。

1. 速度指標小於 1250，在 3G 網路環境下可交互時間小於 5s，重要文件的大小預算小於 170kb。

雖然這可能很難實現，但首次有效渲染要低於 1 秒和速度指標的值低於 1250 將會是一個很好的最終目標。考慮到是一個以 200 美金為基準的 Android 手機（如 Moto G4）在一個緩慢的 3G 網路上，模擬 400ms 的往返延時和 400kb 的傳輸速度。它的目標是可交互時間低於 5s，並且重複訪問的速度低於 2s。

請注意，當談到可交互時間時，最好來區分一下首次交互和一致性交互以避免對它們之間的誤解。前者是在主要內容已經渲染出來後最早出現的點（窗口至少需要 5s，頁面才開始響應）。後者是期望頁面可以一直進行輸入響應的點。

HTML 的前 14~15kb 載入是是最關鍵的有效載荷塊 —— 也是第一次往返（這是在400 ms 往返延時下 1秒內所得到的）預算中唯一可以交付的部分。一般來說，為了實現上述目標，我們必須在關鍵的文件大小內進行操作。最高預算 170 Kb gzip (0.8-1MB decompressed)（0.8-1MB解壓縮），它已經佔用多達 1s （取決於資源類型）來解析和在普通電話上進行編譯。稍微高於這個值是可以的，但是要儘可能地降低這些值。

不過你也可以超出包大小的預算。例如，你可以在瀏覽器主線程的活動中設置性能預算，即：在開始渲染前的繪製時間或者跟蹤前端 CPU 。Calibre，SpeedCurve 和 Bundlesize 這些工具可以幫助你保持你的預算控制，並集成到你的構建過程。

本來就很快的：現代化載入的最佳實踐 來自 Addy Osmani（幻燈片 19）

環境搭建

1. 選擇和設置你的構建工具。

不要太在意那些很酷的東西。堅持使用你的構建工具，無論是Grunt，Gulp，Webpack，Parcel，還是工具間的組合。只需要你能快速的得到結果，並且維護你的構建過程保證沒問題。那麼，你就做的很好了。

1. 漸進式增強。

將漸進式增強作為前端結構體系和部署的指導原則是一個安全的選擇。首先設計和構建核心經驗，然後為有能力的瀏覽器使用高級特性增強體驗，創造彈性體驗。如果你的網站是在一個網路不佳的並且有個糟糕的顯示屏上糟糕的瀏覽器上運行，速度還很快的話，那麼，當它運行在一個快速網路下快速的瀏覽器的機器上，它只會運行得更快。

1. 選擇一個強大的性能基準。

有這麼多未知因素影響載入 —— 網路、熱保護、緩存回收、第三方腳本、解析器阻塞模式、磁碟的讀寫、IPC jank、插件安裝、CPU、硬體和內存限制、web 字體載入行為 —— JavaScript 的代價是最大的，web 字體阻塞渲染往往是默認和圖片消耗了大量的內存所導致的。由於性能瓶頸從伺服器端轉移到客戶端，作為開發人員，我們必須更詳細地考慮所有這些未知因素。

在 170kb 的預算中，已經包括了關鍵路徑的 HTML/CSS/JavaScript、路由器、狀態管理、實用程序、框架和應用程序邏輯，我們必須徹底檢查網路傳輸成本，分析/編譯時間和我們選擇的框架的運行時的成本。

本來就很快的：現代化載入的最佳實踐來自 Addy Osmani(幻燈片18、19)。

正如 Seb Markbage 所指出，測量框架的啟動成本的好方法是首先渲染視圖，再刪除它，然後再渲染，因為它可以告訴你框架是如何處理的。

第一種渲染傾向於預熱一堆編譯遲緩的代碼，當它擴展時，更大的樹可以從中受益。第二種渲染基本上是對頁面上的代碼重用如何影響性能特性的模擬，因為頁面越來越複雜。

並不是每個項目都需要框架。事實上，某些項目因移除已存在的框架而從中獲益。一旦選擇了一個框架，你將會至少與它相處幾年。所以，如果你需要使用它，確保你的選擇是經過深思熟慮的而且別人是知情的。在進行選擇前，至少要考慮總大小的成本 + 初始解析時間：輕量級的選項像 Preact，Inferno，Vue，Svelte 或者 Polymer 都可以把工作做得很好。大小的基準將決定應用程序代碼的約束。

JavaScript 解析成本可能有很大差異。本來就很快的: 現代化載入的最佳實踐來自Addy Osmani (幻燈片 10)。

請記住，在移動設備上，與台式計算機相比，你會預計有 4x-5x 的減速。因為移動設備具有不同的 GPU，CPU，內存及電池特性。在手機上的解析時間比桌面設備的要高 36%。所以總在一個普通的設備上測試 —— 一種最能代表你的觀眾的設備。

不同的框架將會對性能產生不同的影響，並且需要不同的優化策略。因此，你必須清楚地了解你所依賴的框架的所有細節。PRPL 模式和應用程序 shell 體系結構。這個想法很簡單: 將初始路由的交互所需的最小代碼快速呈現，然後使用 service worker 進行緩存和預緩存資源，然後非同步載入所需的路由。

PRPL 代表的是保持推送關鍵資源，渲染初始路由，預緩存剩餘路由和延遲載入必要的剩餘路由。

應用程序 shell 是最小的 HTML、CSS 和 JavaScript 驅動的用戶界面。

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

推薦閱讀：