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

• 原文地址：Front-End Performance Checklist 2018 - Part 1
• 原文做者：Vitaly Friedman
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：tvChan
• 校對者：mysterytony ryouaki

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

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

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

---

作好準備：計劃和指標

微小的優化對於保持性能來講都是很重要的，可是在頭腦中明確的定義 —— 可衡量的目標纔是相當重要的。這將會影響你整個過程當中作出的任何決定。有幾種不一樣的模型，下面討論的模型都頗有本身的主見 —— 只要確保在一開始能設定本身的優先級就行。

1. 創建性能指標。

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

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

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

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

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

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

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

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

3. 選擇正確的指標。

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

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

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

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

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

4. 從具備表明性的觀衆的設備上收集數據。

爲了收集準確的數據，咱們須要完全的選擇要測試的設備。也許在一個開放式的實驗室裏，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 的性能檢測工具。

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

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

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

制定現實的目標

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

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

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

7. 速度指標小於 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）

環境搭建

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

不要太在乎那些很酷的東西。堅持使用你的構建工具，不管是Grunt，Gulp，Webpack，Parcel，仍是工具間的組合。只須要你能快速的獲得結果，而且維護你的構建過程保證沒問題。那麼，你就作的很好了。

9. 漸進式加強。

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

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

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

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

原本就很快的：現代化加載的最佳實踐來自 Addy Osmani(幻燈片1八、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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。