- 原文地址：Front-End Performance Checklist 2018 - Part 1
- 原文作者：Vitaly Friedman
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：tvChan
- 校對者：mysterytony ryouaki
2018 前端效能優化清單 —— 第一部分
下面你將會看到你可能需要考慮到的前端效能優化問題，以保證你的應用具有快速和流暢的響應時間。
做好準備：計劃和指標
微小的優化對於保持效能來說都是很重要的，但是在頭腦中明確的定義 —— 可衡量的目標才是至關重要的。這將會影響你整個過程中做出的任何決定。有幾種不同的模型，下面討論的模型都很有自己的主見 —— 只要確保在一開始能設定自己的優先順序就行。
- 建立效能指標。
在許多組織裡，前端開發人員確切的知道常見的潛在問題是什麼，並且知道使用什麼載入模組來修復它們。然而，只要開發/設計和營銷團隊之間沒有一致性，效能就不能長期維持。研究客戶服務中的常見投訴，瞭解如何提高效能，可以幫助解決這些常見問題。
在移動和桌面裝置上執行效能實驗和測量結果。它將幫助你的公司量身定做一個根據真實資料而得到的研究案例。此外，利用 WPO 統計 資料對案例進行研究和實驗，可以幫助提高業務對效能問題的敏感度，以及它對使用者體驗和業務指標的影響。僅僅說明效能問題是遠遠不夠的 —— 你也需要建立一些可衡量和可跟蹤的目標並對它們進行觀察。
- 目標：至少要比你最快的競爭對手還快 20%。
根據心理學的研究，如果你想讓使用者感覺你的網站比競爭對手的快，你至少需要比它們快 20%。 研究你的主要競爭對手，收集它們是怎麼在手機和桌面裝置上展示的資料，並且設定閥值來幫助你超過它們。要獲取準確的結果和目標，首先要研究你的分析結果，看看你的使用者都在做什麼。然後，你可以模擬第百分之九十位的實驗進行測試。收集資料，建立一個 電子資料表，從中剔除 20%, 並制定你的目標（即 效能預算）。現在你就有一些可以測試的東西了。
如果你希望保持現在的成本不變，並儘可能的少寫一些指令碼，就能有一個快速的可互動時間。那麼你已經走在正確的道路上了。勞拉.霍根的指導你如何用效能預算接近設計 裡提供了有用的方向，設計人員，效能預算計算者和 Browser Calories 可以幫助我們建立預算（感謝 Karolina Szczur 的牽頭）。
除了效能預算之外，還要考慮對你的業務最有利的關鍵客戶任務。設定和討論可接受的關鍵行為的時間閾值，並建立整個專案組都已經同意的 ＂UX 就緒＂的使用者計時標記。在許多情況下，使用者的需求將會影響到許多不同部門的工作。因此, 在可接受的時間內進行調整，將有助於支援或避免了在優化路上的效能討論。確保增加資源和功能的額外成本是可預見和可理解的。
此外, 正如 Patrick Meenan 建議的，在設計過程中制定一個載入順序及其權衡是非常值得。如果你在早期優先考慮哪些部分更重要，並且定義了它們應該出現的順序，那麼你也將知道哪些部分可以延遲。在理想情況下，該順序還將反映 CSS 和 JavaScript 的匯入順序。因此，在構建過程中處理它們會更容易。此外，在載入頁面時，請考慮在"中間"狀態下的視覺體驗 (例如，web 字型尚未載入時)。
計劃，計劃，計劃。在早期的優化裡，它可能像是誘人的＂熟水果＂ —— 最終它可能是一個很好的能快速取勝的策略 —— 但是，如果沒有計劃和切合實際的、為公司量身定製的效能目標，就很難將效能放在首位。
- 選擇正確的指標。
並不是所有的指標都同樣重要。研究哪些標準對你的應用程式最重要：通常它與你開始渲染那些最重要的畫素點（以及它們是什麼）有多快和如何快速地為這些渲染的畫素點提供輸入響應有關。這可以幫助你為後續的工作提供最佳的優化結果。不管怎樣，不要專注於整個頁面的載入時間（例如，通過 onLoad 和 DOMContentLoaded 計時），而是優先載入使用者認為重要的頁面。這意味著要專注於一組稍有不同的指標。事實上，選擇正確的指標是一個沒有對手的過程。
首次有內容渲染，首次有效渲染，視覺完整和可互動時間之間的區別。大圖。來自於：@denar90
下面是一些值得考慮的指標：
- 首次有效渲染（FMP，是指主要內容出現在頁面上所需的時間），
- 英雄渲染時間（頁面最重要部分渲染完成所需的時間），
- 可互動時間（TTI，是指頁面佈局已經穩定，關鍵的頁面字型已經可見，主程式可以足夠的處理使用者的輸入 —— 基本的時間標記是，使用者可以在 UI 上進行點選和互動），
- 輸入響應，介面響應使用者操作所需的時間，
- 速度指標，測量填充頁面內容的速度。 分數越低越好，
- 你的自定義指標，由你的業務需求和客戶體驗來決定。
Steve Souders 對每個指標都進行了詳細的解釋。在許多情況下，根據你的應用程式的上下文，可互動時間和輸入響應會是最關鍵的。但這些指標可能會不同：例如，對於 Netflix 電視的使用者介面來說，關鍵輸入響應、記憶體使用和可互動時間更為重要。
- 從具有代表性的觀眾的裝置上收集資料。
為了收集準確的資料，我們需要徹底的選擇要測試的裝置。也許在一個開放式的實驗室裡，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 的效能檢測工具。
- 與你的同事分享效能清單。
為了避免誤解，要確保你團隊裡的每個同事都對清單很熟悉。每個決策都對效能有影響。專案將極大地受益於前端開發人員正確地將效能價值傳達給整個團隊。這樣每個人都會對它負責，而不僅僅是前端開發人員。根據效能預算和核對錶中定義的優先順序對映設計決策。
RAIL，以使用者為中心的效能模型。
制定現實的目標
- 60 fps，100 毫秒的響應時間。
為了讓互動感覺起來很順暢，介面有 100ms 來響應使用者的輸入。任何比它長的時間，使用者都會認為該應用程式很慢。RAIL，一個以使用者為中心的效能模型會為你提供健壯的目標。為了讓頁面達到小於 100ms 的響應，頁面必須要在在每小於 50ms 前將控制返回到主執行緒。預計輸入延遲時間會告訴我們，如果我們能達到這個門檻，在理想情況下，它應該低於 50ms。對於像動畫這樣的高壓點，最好不要在你能做到的地方做任何事，也不要做你不能做到的事。
同時，每一幀動畫應該要在 16 毫秒內完成，從而達到 60 幀每秒（1秒 ÷ 60 = 16.6 毫秒） —— 最好在 10 毫秒。因為瀏覽器需要時間將新框架繪製到螢幕上，你的程式碼應該在觸發 16.6 毫秒的標誌前完成。保持樂觀和明智地利用空閒時間。顯然，這些目標適用於執行時的效能，而不是載入效能。
- 速度指標小於 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）
環境搭建
- 選擇和設定你的構建工具。
不要太在意那些很酷的東西。堅持使用你的構建工具，無論是Grunt，Gulp，Webpack，Parcel，還是工具間的組合。只需要你能快速的得到結果，並且維護你的構建過程保證沒問題。那麼，你就做的很好了。
- 漸進式增強。
將漸進式增強作為前端結構體系和部署的指導原則是一個安全的選擇。首先設計和構建核心經驗，然後為有能力的瀏覽器使用高階特性增強體驗，創造彈性體驗。如果你的網站是在一個網路不佳的並且有個糟糕的螢幕上糟糕的瀏覽器上執行，速度還很快的話，那麼，當它執行在一個快速網路下快速的瀏覽器的機器上，它只會執行得更快。
- 選擇一個強大的效能基準。
有這麼多未知因素影響載入 —— 網路、熱保護、快取回收、第三方指令碼、解析器阻塞模式、磁碟的讀寫、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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。