寫在譯前：首先介紹一下我自己，一個跨行業的、完全非科班生的文科單身狗。因為生計，走上了自學前端的荊棘之路，然後經過一路的摸爬打滾終於算是入了前端的這個門，自己也知道在前端這條道路上還有很長的路要走。平常生活中喜歡跑步，歡迎有同樣愛好的大佬一起交流切磋。
這篇譯文是在掘金Limin組織的2019年度開發者寫作計劃下開始的，旨在通過平時的學習，將自己所學的知識通過一個歸納總結，得以提高自己的前端技能水平。很感謝Limin推薦的這篇文章。
由於全文篇幅太長，無法將所有內容一次性發布完，所以計劃分成上、中、下三個篇章。上篇包括（ 計劃和度量、制定現實的目標 和 定義環境 ），中篇包括（ 資源優化、構建優化 和 交付優化 ），下篇包括（ HTTP / 2、測試和監測 和 速效方案 ）。
原文連結地址：Front-End Performance Checklist 2019
原文作者：Vitaly Friedman
譯者：單車 runner
這是一篇有關年度前端效能優化的文章，包含了建立快速體驗所需的所有知識，自2016年以來每年更新一次。
Web 效能在前端領域是一個棘手的問題，所以，知道我們在效能方面處於什麼位置，以及我們的效能瓶頸究竟是什麼就顯得更為重要了。它是昂貴的 JavaScript 呢、 還是緩慢的 web 字型傳遞、 或是較大的圖片在使得頁面載入速度變緩？ web 效能優化包括：無用程式碼移除 （Tree-shaking）、作用域提升（Scope hoisting）、程式碼分割（Code-spliting），交叉觀察器（Intersection observer）、伺服器推送（server push）、客戶端提示（clients hints）、HTTP/2、service workers 等等這些手段。然而，最重要的是，我們該 從哪裡開始提高前端效能 以及 如何建立長久的前端效能優化機制？
之前，我們習慣性在完成專案之後，再去考慮前端方面的效能優化。這樣就會導致留給我們優化的時間極度有限，讓我們不得不縮小優化考慮的範圍。通常我們優化的內容也侷限於資源優化（一些靜態檔案的縮小）和伺服器配置檔案上的一些細微調整。現在回過來看，前端發展越來越快，涉及面越來越廣，效能優化光做到這些還是遠遠不夠的。
效能不僅僅是一個技術問題：它很重要，所以當將其放入工作流中時，我們必須根據效能的影響來做設計決策。效能必須被測量、監測和不斷的完善。網路日益增長的複雜性也使得前端效能指標的跟蹤變得越來越難，因為效能指標會根據裝置、瀏覽器、協議、網路型別和延遲而發生改變（CDN、ISP、快取、代理、防火牆、負載均衡器和伺服器都在效能方面發揮作用）。
因此，我們建立了一個在提高效能時必須記住的所有事情的概述：即從網站的最開始準備階段到網站的最終釋出需要注意的效能問題列表。以下是2019年的前端效能優化清單（希望沒有偏見和客觀）—— 更新了您可能需要考慮的問題，以確保您的網站響應時間更快，使用者互動更加流暢，不會佔用使用者的頻寬。
（您也可以僅下載 前端效能優化清單的 PDF 版本（166 kb）或者 下載 Apple Pages 版本（275 kb）或者是 .docx 檔案 (151 kb)。祝願大家，在前端效能優化這條路上走的越來越順暢！！！）
目錄
準備：計劃和度量
微優化對於保持效能的正常執行非常重要，所以在我們必須把明確的目標時刻印記在腦海中。明確的目標應該是可以度量，因為他可以影響整個過程中所做的任何決策。這裡有幾種不同的模式，我們需要從自身的角度出發，儘早確認自己專案中效能優化的優先順序別。
1. 建立效能優化意識
在很多技術團隊中，前端開發人員確切地知道什麼是常見的底層問題，以及應該使用什麼載入模式來修復這些問題。然而，只要沒有對效能優化的意見達成一致，每個部門就會按照自己的理解來定位產品，這樣一個公司就會變成一盤散沙。這時候，需要讓相關人員都參與進來， 然後建立一個調查問卷，調查大家所關心的速度效益指標和關鍵效能指標( kpi )。
如果開發/設計部與業務部之間的意見還沒有達成一致，那麼效能優化將無法開展。研究使用者在體驗產品之後的反饋，看看如何提高效能以助於解決這些常見問題。
在移動裝置和桌面裝置上執行效能實驗並測量結果，得到的真實的資料將幫助你建立一個為公司量身定製的案例研究。此外，使用 WPO Stats 上釋出的案例研究和實驗資料，可以幫助提高你對效能和業務之間的潛在關係的認識，以及效能對使用者體驗和業務度量的影響。僅僅說明效能很重要是不夠的，您還需要建立一些可度量的、可跟蹤的目標來觀測效能。
Allison McKnight 在她關於 構建長期效能優化 的演講中分享了她如何幫助 Etsy 建立效能優化的全面案例研究。
2. 目標：要比你最快的競爭對手快至少 20%
根據心理學研究，如果你想讓使用者覺得你的網站比競爭對手的網站快，你需要至少快20%。研究你的主要競爭者，收集他們在移動端和桌面上的效能，並且設定一個你能超過他們的臨界值。要獲取準確的結果和目標，首先要研究你的分析結果，看看你的使用者都在做什麼。然後，您可以模擬第90個百分位的測試經驗。
為了更好地瞭解競爭對手的表現，您可以使用 Chrome UX報告（ CrUX，現成的 RUM 資料集，Ilya Grigorik 的 視訊介紹），Speed Scorecard（也提供收入影響估算器）， 真實使用者體驗測試比較 或 SiteSpeed CI（基於綜合測試）。
注意：如果使用 Page Speed Insights（不推薦使用），則可以獲取特定頁面的 CrUX 效能資料，而不僅僅是聚合。此資料對於設定 目標網頁 或 產品詳情 等資產的效果目標非常有用。如果您使用 CI 來測試預算 以及 CrUX 設定目標，則需要確保您的測試環境與 CrUX 匹配（感謝 Patrick Meenan！）。
收集資料之後，建立一個電子表格，將資料結果減去 20% 就是你的目標（即 效能預算）。現在，你在測試之前就有了一些可度量的資料。在這個資料（效能預算）的前提下，嘗試使用最少的指令碼來實現最快的互動，這樣子我們就算是達成了自己的目標。
啟動所需要的資源：
- Addy Osmani 寫了一篇關於如何開始效能預算、如何量化新特性的影響以及在超出預算時從何處開始的非常詳細的文章。
- Lara Hogan 關於如何使用效能預算進行設計 的指南可以為設計師提供有用的指導。
- Jonathan Fielding 的 效能預算計算器、Brad Frost 的 效能預算構建器 和瀏覽器卡路里 可以幫助建立預算(感謝 Karolina Szczur 的領導)。
- 此外，通過使用報告構建大小的圖表設定儀表板，可以使效能預算和當前效能可見。有許多工具可以幫助您實現這一目標：SiteSpeed.io 儀表板（開源），SpeedCurve 和 Calibre 只是其中的一部分，您可以在 perf.rocks 上找到更多工具。
準備好預算後，使用 Webpack Performance Hints 和 Bundlesize，Lightouse CI，PWMetrics 或 Sitespeed CI 將它們合併到構建過程中，以強制執行拉取請求的預算並在PR註釋中提供分數歷史記錄。如果你需要自定義的東西，你可以使用 webpagetest-charts-api，一個端點 API 來自 WebPagetest 結果構建圖表。
例如，就像 Pinterest 一樣，您可以建立一個自定義的 eslint 規則，該規則禁止從已知屬於依賴性的檔案和目錄中匯入並使該捆綁包膨脹。設定可在整個團隊中共享的 安全 軟體包列表。
除了效能預算之外，還要考慮對您的業務最有利的關鍵客戶任務。設定並討論 關鍵操作的 可接受 時間閾值，並建立整個組織已達成一致的 UX就緒 使用者時間標記。在許多情況下，使用者旅程將涉及許多不同部門的工作，因此在可接受的時間安排方面的協調將有助於支援或阻止績效討論。確保可以看到和理解新增的資源和功能的額外成本。
此外，正如 Patrick Meenan 所建議的那樣，最好在設計的過程中設定一個載入佇列並且要知道這些順序會存在哪些利弊。您需要優先處理更重要的優先順序，並定義它們應該出現的順序，那麼您就可以確定哪一部分可以延遲。通常理想情況下，該佇列也反映 CSS 和 JavaScript 匯入的順序，因此在構建過程中處理它們會更容易。此外，在載入頁面時（例如，當尚未載入 Web 字型時），考慮視覺體驗應該在 中間 狀態中。
規劃、計劃、規劃,重要的事情說三遍。如果早期進行優化那麼會很容易實現目標，但是沒有計劃或者沒有制定切合實際的、為公司量身定製的業績目標，那麼就很難保持效能。
3. 選擇正確的指標
不是所有的度量都很重要。研究哪些度量對於你的應用程式最重要：通常，這與你能夠以多快的速度開始渲染最重要的畫素（以及它們的效果）以及如何為這些渲染畫素提供輸入最快的響應速度有關。 這可以幫助你為後續的工作提供最佳的優化結果。
不管怎樣，不要專注於整個頁面的載入時間（例如 onLoad 和 DOMContentLoaded 時間），而是要優先按照使用者可以感知到的頁面載入。 也就是說要關注一組稍微不同的度量。
根據 Tim Kadlec 的研究和 Marcos Iglesias 在他的 演講 中所做的筆記，傳統的度量指標可以分為幾種。通常情況下，我們在全面瞭解效能的時候可能需要用到所有的這些方法，但是，也有可能在自己實際的專案當中，其中的某一種方法比其他方法更為重要。
這裡挑出一些相對更為重要的方法：
- 基數度量標準（ Quantity-based metrics ）主要是用來衡量請求數量，權重和效能的得分。適用於一些提高警報或者監控隨著時間的變化而改變的專案，但是對於使用者體驗不是很友好。
- 里程碑度量標準（M ilestone metrics ）指的是專案在載入過程中，專案在某個生命週期中一個使用狀態，例如：到某個生命節點所需要的時間，或者是完成某個互動所需要的時間。雖然這個度量標準不會記錄兩個不同生命週期之間發生的事情，但是卻適合用來監控和描述使用者的體驗。
- 渲染度量標準（ Rendering metrics ）是用來預估頁面內容呈現的速度。適合用於測量和調整渲染效能，但不適合用來測量重要內容在什麼時間節點出現並可與之進行互動。
- 自定義度量標準（ Custom metrics ） 是用來衡量專案的特定自定義事件。例如 Twitter 的 Time To First Tweet 和 Pinterest 的 PinnerWaitTime。適合用於精確的描述使用者的體驗，不太適合根據這個標準來和對手進行比較。
下面羅列一些最具體和相關的的度量標準：
- 首次有效渲染時間 -- First Meaningful Paint （ FMP ）指的是主要內容出現在頁面上的時間，讓您深入瞭解伺服器輸出任何資料的速度。Long FMP 大部分表示 JavaScript 阻塞了主執行緒，當然也可能是後端或者伺服器的問題導致的。
- 互動時間 （ TTI ）是指頁面佈局已經穩定，關鍵的頁面字型已經可見，主程式足以去處理使用者的輸入 —— 使用者可以在 UI 上進行點選和互動的基本時間標記。用來了解使用者在沒有延遲的情況下開啟網站需要多長的時間。
- 輸入響應 （ FID ）即介面響應使用者在實現互動操作所需的時間。
- 速度指數 -- Speed Index 測量頁面內容在視覺上的填充速度，得分越低越好。速度指數得分是根據視覺進度的速度計算的，它只是一個計算值，對於視覺視窗大小很敏感，所以您需要定義一個與大眾相匹配的測試標準（感謝，Boris！）。
- CPU時間花費 指的是 CPU 時間一個度量，指示主執行緒處理有效負載的繁忙程度。它顯示了主執行緒被阻止的頻率和持續時間，用於繪製，渲染，編寫指令碼和載入。根據 janky 的經驗，高 CPU 時間即表示使用者遇到他們的行動和反應之間存在明顯的滯後。使用 WebPageTest，您可以 在 Chrome 選項卡上選擇 Capture Dev Tools Timeline，以顯示主執行緒使用 WebPageTest 在任何裝置上執行時的詳細分數。
- 廣告權重影響 如果您的網站主要收入來源於廣告，那麼與廣告業務模組的程式碼就要特別關注。Paddy Ganti 的 指令碼 構造了兩個URL（一個是正常的 URL，一個阻止廣告的 URL），提示通過 WebPageTest 生成視訊比較並報告增量。
- 偏差度量標準 一個儀器的測量結果的資料可以讓我們知道這個儀器的可靠性，同理，我們可以通過測試的出來的資料結果分析，然後做出一個平衡。資料結果中，差異很大的標準需要重新設定，並且他還有助於我們瞭解某些頁面是否會因為某些其他原因（例如第三方指令碼）而導致更難以可靠地測量。另外，在推出新的瀏覽器版本時，對比新版本與舊版本在效能上的差異也是度量偏差的一個好方法。
- 自定義度量標準 即由您的業務需求和客戶體驗來定義。它要求您解析重要畫素，關鍵指令碼，必要的 CSS 和其他的相關資源，並預測頁面展現在使用者視覺下的速度。對於這個標準，您可以監視 Hero渲染時間，或使用 Performance API，為業務中很重要的事件標記一個時間戳。此外，您可以通過在測試結束時執行任意 JavaScript，然後通過結果對照 WebPagetest 確定自定義指標。
Steve Souders 詳細的解釋了每個度量。在許多情況下，我們測量出的資料是在特定環境下的使用程式得出的資料，但是輸入響應代表的是使用者的實際體驗，實際當中，使用者的體驗要明顯滯後。所以，保持持續測量和收集使用者行為對於度量的制定相對來說更準確。
根據應用程式的上下文，首選度量可能會有所不同：例如，對於 Netflix TV UI：輸入響應，記憶體使用 和 TTI 更為關鍵，對於維基百科，第一個/最後一個視覺更改和CPU時間花費度量更為重要。
注意：FID 和 TTI 都不考慮滾動行為; 滾動可以獨立發生，因為它是非主執行緒，因此對於許多內容消費網站而言，這些指標可能相對於沒有那麼重要。
4. 從具有代表性的使用者使用的裝置收集資料
為了收集準確的資料，我們需要儘可能全的選擇要測試的裝置。最好是 Moto G4，或者一款中檔的三星裝置又或者是一個 Nexus 5X 這樣的普通的裝置。如果你手邊沒有裝置，可以使用節流 CPU（5× 減速）來限制網速（例如，150 ms 的往返時延，1.5 Mbps 以下和0.7 Mbps 以上）實現在桌面裝置上模擬移動裝置的體驗。最終，切換到常規的 3G，4G 和 Wi-Fi。為了使效能體驗的影響更明顯，你甚至可以使用 2G 或 一個節流的 3G 網路，以便進行更快的測試。
幸運的是，有很多優秀的選項可以幫助你自動收集資料，並根據這些度量衡量你的網站在一段時間內的效能。 請記住，良好的效能度量是需要被動和主動監控工具的組合：
- 被動監測工具，可以根據請求來模擬使用者互動（綜合測試，如Lighthouse，WebPageTest）
- **主動監測工具，**是那些不斷記錄和評價使用者互動行為的（真正的使用者監控，如 SpeedCurve，New Relic —— 這兩種工具也提供綜合測試）
前者在開發過程中特別有用，因為它可以在使用產品時持續跟蹤。 後者在長期維護非常有用，因為它可以幫助你瞭解在實際訪問站點時發生的效能瓶頸。
通過使用 導航定時、資源定時、繪圖定時、長時間任務 等內建的 RUM API，被動和主動效能監視工具一起提供應用程式效能的完整畫面。 例如，你可以使用 PWMetrics，Calibre，SpeedCurve，mPulse，Boomerang 和 Sitespeed.io，這些都是效能監測工具的絕佳選擇。
注意：選擇瀏覽器外部的網路級別的限制器總是比較安全的，例如 DevTools 由於實現的方式而存在與 HTTP/2 推送互動的問題（感謝 Yoav，Patrick！）。對於 Mac OS，我們可以使用 Network Link Conditioner，Windows 可以使用 Windows Traffic Shaper，Linux 可以使用 netem， FreeBSD 可以使用 dummynet。
5. 設定乾淨的使用者配置檔案以進行測試
在監視工具中測試時，需要關閉防病毒和後臺 CPU 任務，刪除後臺頻寬傳輸以及使用乾淨的使用者配置檔案。我們需要注意的是，防止使用瀏覽器（ Firefox，Chrome ）擴充套件而導致結果出現偏差。
有時候，研究客戶經常使用的擴充套件程式以及使用專用的客戶配置檔案進行測試也是一個好辦法。在實際應用當中，如果您的使用者經常使用它們，您可能需要優先考慮到它，因為某些擴充套件可能會對您的應用程式 產生很大的效能影響。我們對於 乾淨 的個人資料結果過於樂觀，因為在實際的使用者應用場景中可能會被粉碎。
6. 與同事分享效能清單
為了避免誤解，要確保你團隊裡的每個同事都對清單很熟悉。每個決策都對效能有影響。專案將極大地受益於前端開發人員正確地將效能價值傳達給整個團隊。從而使每個人都對它負責，而不僅僅是前端開發人員。根據績效預算和清單中定義的優先順序來設計決策。
制定現實的目標
7. 響應時間控制在 100ms，幀速控制在 60幀/秒
為了讓互動感覺起來很順暢，介面有 100ms 來響應使用者的輸入。任何比這更長的時間，都會讓使用者感覺到應用程式很慢。 RAIL，一個以使用者為中心的效能模型 會為你設立一個正確的目標：要達到 < 100ms 響應時間的目標，頁面必須要在小於 50ms 前最遲將控制權返回給主執行緒。預計輸入延遲 時間告訴我們，如果我們能達到這個門檻，那麼在理想情況下，它應該低於 50ms。對於像動畫這樣效能消耗比較大的地方，最好的做法是，在能夠優化的地方，儘量優化到極致；在不能優化的地方，讓效能開銷降至最低。
同時，每一幀動畫應該要在 16 毫秒內完成，從而達到 60 幀每秒（1秒 ÷ 60 = 16.6 毫秒） —— 最好可以在 10 毫秒完成。因為瀏覽器需要時間將新框架繪製到螢幕上，你的程式碼應該在觸發 16.6 毫秒以內完成。在頁面設計上保持樂觀 和 明智地利用空閒時間。顯然，這些目標適用於執行時的效能，而不是載入效能。
8. 速度指標（SpeedIndex） < 1250，3G上的互動時間（Interaction time）小於5s，關鍵檔案大小預算 < 170 Kb（gzip）
雖然這可能很難實現，一個好的最終目標是首次有效渲染低於 1s 並且 SpeedIndex 的值低於 1250。因為我們是以 200 美金為基準的 Android 手機（如 Moto G4）和一個緩慢的 3G 網路上，模擬 400ms 的往返延時和 400kb 的傳輸速度，所以我們的目標是 可互動時間低於5s，並且再次訪問的時間低於 2s。
請注意，當談到可互動時間時，最好來 區分一下首次互動(First CPU Idle)和 連續互動(Time To Interactive) 以避免對它們之間的誤解。前者是在主要內容已經渲染出來後最早出現的點（視窗至少需要 5s，頁面才開始響應）。後者是期望頁面可以一直進行輸入響應的點。
HTML 的前 14~15kb 載入是是最關鍵的有效載荷塊—— 也是第一次往返（這是在400 ms 往返延時下 1 秒內所得到的）預算中唯一可以交付的部分。一般來說，為了實現上述目標，我們必須在關鍵的檔案大小內進行操作。最高預算壓縮之後 170 Kb（0.8-1MB解壓縮），它已經佔用多達 1s （取決於資源型別）來解析和編譯。稍微高於這個值是可以的，但是要儘可能地降低這些值。
儘管如此，還是可以提高繫結的規模預算。例如，你可以在瀏覽器主執行緒的活動中設定效能預算，例如，在開始渲染前的繪製時間或者 跟蹤前端 CPU。像 Calibre，SpeedCurve 和 Bundlesize 這些工具可以幫助你保持你的預算控制，並整合到你的構建過程。
定義環境
9. 根據實際情況選擇並搭建構建工具
不要把太多的關注點放在那些看起來很酷的構建工具上。根據您的專案來構建環境，無論是 Grunt 、 Gulp 、 Webpack 、 Parcel，還是工具組合。只要這個構建工具能夠讓您快速的得到結果，並且保證您的構建過程沒有問題，那麼您就可以選擇該構建工具。
在所有的構建工具中，Webpack 似乎是最成熟的一個，它有數百個外掛可以用來優化構建的大小。如果你作為一位初用者，剛開始使用 Webpack 可能會很困難。所以如果你想開始使用 webpack，下面有一些很好的資源可以給您指引:
- Webpack文件 是一個很好的入手點，同樣 Webpack相關的文章也可以作為很好的入門指引：Raja Rao 的 Confusing Bits 和 Andrew Welch 的 Annotated Webpack Config。
- Sean Learkin 上有一個關於 Webpack 的免費課程: Core Concepts，Jeffrey Way 也釋出了一個關於 Webpack 的免費精彩視訊供大家學習。它們都是深入的介紹了 Webpack。
- Webpack Fundamentals 是一個非常全面的4小時課程，由 FrontendMasters 釋出在 Sean Learkin。
- 如果您對 Webpack 已經有初步的瞭解，Rowan Oulton 釋出了一個使用 Webpack 獲得 更好構建效能 的 應用場景指南，Benedikt Rotsch 對如何將Webpack繫結在一個節點上 進行了深入的研究。
- Webpack示例 包含了數百個即用型 Webpack 配置，主要按主題和用途分類。另外，還有一個 Webpack Config 配置器，可以生成一個基本配置檔案。
- awesome-webpack 是一個非常有用的關於 Webpack 資源、庫和工具的列表，裡面包括一些介紹 Angular 、React 和未使用框架專案的文章、視訊、課程、書籍和示例。
10. 預設情況下使用漸進增強
安全的選擇是將漸進增強作為前端架構和專案部署的指導原則。首先設計和構建核心體驗，然後通過功能強大的瀏覽器的高階功能增強體驗，創造 彈性 體驗。如果你的網站在一個網路不佳、糟糕裝置、效能差的低版本瀏覽器上執行速度還是挺快，那麼這個網站在一個網路環境好、裝置和瀏覽器效能都比較好的環境下會執行起來會更加快。
11. 選擇強大的效能基準
有這麼多的未知影響載入 —— 網路、熱節流、快取回收、第三方指令碼、解析器阻塞模式、磁碟的讀寫、 IPC jank、外掛安裝、CPU、硬體和記憶體限制、L2/L3 快取、RTTS、影象、Web 字型載入行為的差異，其中 Javascript 指令碼的代價是最大的，Web 字型阻塞預設的渲染和圖片的載入使得記憶體消耗太大。隨著效能瓶頸 從伺服器端轉移到客戶端，作為開發人員，我們必須更仔細地考慮所有這些未知因素。
在 170kb 的預算中，已經包括了關鍵路徑的 HTML / CSS / JavaScript、路由器、狀態管理、實用程式、框架和應用程式邏輯，我們必須徹底 檢查網路傳輸成本，解析/編譯時間和執行時間來選擇我們的框架。
Seb Markbage 指出，衡量框架啟動成本的最好的方法就是先渲染檢視，然後刪除，然後再渲染，因為它可以告訴你框架是如何擴充套件的。第一個渲染趨向於預熱一堆編譯遲緩的程式碼，當它擴充套件時，更大的分支可以從中受益。第二次渲染基本上是仿效頁面上的程式碼重用是如何隨著頁面複雜度的增長來影響效能特徵。
12. 評估每個框架和每個依賴項
並不是每個專案都需要一個框架，也不是單頁面應用程式中的每個頁面都需要載入一個框架。在 Netflix 的例子中，刪除 React，來自客戶端的幾個庫和相應的應用程式程式碼將 JavaScript 總量減少了至少 200Kb，從而使 Netflix 登出主頁的互動時間互動時間 縮短了50％以上 。然後，團隊利用使用者在登入頁面上花費的時間，對使用者可能登入的後續頁面進行預取 React (詳細資訊請點選這裡)。
事實上，某些專案可以 完全移除某些框架 並從中受益。一旦選擇了一個框架，你最少會使用好幾年。所以，如果你需要使用它，確保你的選擇是經過 深思熟慮 的並且 對其完全瞭解。
Inian Parameshwaran 測量了前50個框架的效能足跡 (針對 First Contentful Paint--從導航到瀏覽器從DOM渲染第一部分內容的時間)。Inian 發現，在野外，Vue 和 Preact 在桌面和移動端都是最快的，其次是 React (幻燈片)。您可以檢查您的候選框架和建議的體系結構，並研究大多數解決方案的執行情況，例如伺服器端呈現或客戶端呈現。
基準效能成本問題。根據 Ankur Sethi的 一項 研究，**無論你對它的優化程度如何，你的 React 應用程式在印度普通手機上的載入速度絕不會超過 1.1s。你的 Angular 應用程式總是需要至少 2.7s 才能啟動。您的Vue應用程式的使用者需要等待至少 1s 才能開始使用它。儘管您可能不會將印度定位為主要市場，但如果一個使用者在網路狀況不佳的情況訪問您的網站應該也會呈現出相同的體驗。當然，您的專案團隊可以犧牲基準效能換來可維護性和開發人員效率，但是你要確保這個決定是你經過了深思熟慮之後才做的決定。
您可以通過監測特性、可訪問性、穩定性、效能、包生態系統、社群、學習曲線、文件、工具、跟蹤記錄、團隊、相容性、安全性等來評估 Sacha Greif 的 12分制評分系統 上的框架（或任何 JavaScript 庫）。在進行選擇前，至少要考慮總大小的成本 + 初始解析時間：輕量級的選項像 Preact，Inferno，Vue，Svelte 或者 Polymer 都做得很好。框架的大小基線將為你的應用程式程式碼定義約束條件。
一個很好的起點是為您的應用程式選擇一個好的預設堆疊。Gatsby.js（React），Preact CLI 和 PWA Starter Kit 為平均移動硬體上的快速載入提供了合理的預設值。
13. 考慮使用 PRPL 模式和 app shell 架構
不同的框架會對效能產生不同的影響，並且需要不同的優化策略。因此，您必須清楚地瞭解您所依賴的框架的所有細節。在建立一個 web 應用程式時，請參考 PRPL模式 和 應用程式 shell 體系結構。這個想法很簡單: 用最少的程式碼來將初始路由的互動快速呈現，然後使用 service worker 進行快取和預快取資源，然後使用懶載入非同步載入所需的路由。
14. 優化 API 的效能
api是應用程式通過所謂的端點向內部和第三方應用程式來公開資料的通訊通道。在 設計和構建API時，我們需要一個合理的協議來支援伺服器和第三方請求之間的通訊。Representational State Transfer ( REST )是一個相對完善以及合理的選擇：它定義了一組約束，開發人員可以遵循這些約束以一種高效能、可靠和可伸縮的方式訪問內容。符合 REST 約束的 Web 服務稱為 RESTful Web 服務。
與好的 HTTP 請求一樣，當從 API 檢索資料時，伺服器響應中的所有延遲最終都會傳到終端使用者，從而渲染的延遲。當資源想從 API 檢索一些資料時，它需要從相應的端點請求資料。如果需要渲染來自多個資源的資料的元件(例如每篇評論中都有註釋和作者照片的文章)，那麼可能需要多次往返伺服器。此外，通過 REST 查詢返回的資料量常常會超過渲染該元件所需的資料量。
如果很多資源需要 API 的資料，那麼 API 可能會導致效能瓶頸。GraphQL 為這些問題提供了一個效能解決方案。GraphQL 是執行在服務端的 API 查詢語言，用於為資料定義的型別系統執行查詢。與 REST 不同的是， GraphQL 可以在單個請求中檢索所有資料並確定所依賴的資料，而 REST 會獲取過多需要的資料。
此外，由於 GraphQL 使用的是 schema (告訴如何結構化資料的後設資料)。他可以將資料組織到更好的結構中。我們可以使用 GraphQL 來移除用於狀態管理的 JavaScript 程式碼，從而在客戶端生成一個更乾淨的應用程式程式碼來加快執行速度。
如果您想開始學習 GraphQL, Eric Baer 在他的 really Smashing 雜誌上發表了兩篇精彩的文章：GraphQL 入門教程一：為什麼我們需要一種新的 API; GraphQL 入門教程二：API 設計的發展(感謝，Leonardo!)
15. 您是使用 AMP 還是 Instant Articles
根據組織的優先順序和策略，您可以考慮使用谷歌的 AMP 、Facebook 的 Instant Articles 或蘋果的 Apple News。如果不使用它們，你也可以實現很好的效能，但是 AMP 確實提供了一個免費的內容分發網路（ CDN ）的效能框架，而 Instant Articles 將提高你在 Facebook 上的可見性和效能。
對於使用者而言，這些技術主要的優勢是確保效能，所以有時他們更喜歡 AMP-/Apple News/Instant Pages 連結，而不是 常規 和潛在的臃腫頁面。對於那些以內容為主的網站，主要處理很多第三方法內容，這些選擇極大地加速渲染的時間。
除非他們不這樣做。例如，根據 Tim Kadlec 的說法，AMP文件往往比同行更快，但並不一定意味著頁面具有高效能；從效能角度來看，AMP並不是造成最大差異的因素。
對於站長而言，這些樣式在各個平臺可發現性並且 增強在搜尋引擎中的可見性。你也可以重新使用 AMP 作為你的 PWA 資料來源來構建 漸進式 Web AMPs。有什麼缺點呢？顯然，在一個有圍牆的區域裡，開發者可以創造並維持與內容分離的單獨版本，防止 Instant Articles 和 Apple News 沒有實際的URLs。（謝謝，Addy，Jeremy）
16. 合理使用 CDN
根據您擁有的動態資料量，您可以將部分內容 外包 給 靜態站點生成工具，將其推送到 CDN 並從中提供靜態版本，從而避免資料庫請求。您甚至可以選擇基於 CDN 的 靜態主機平臺，這樣就可以通過給頁面新增可互動元件的方式來豐富你的頁面( JAMStack )。事實上，其中一些生成器(比如 React 上面的 Gatsby )實際上是 網站編譯器，提供了許多自動優化功能。隨著編譯器不斷地新增優化，編譯後的輸出會越來越小，速度也會越來越快。
請注意，CDN 也是可以託管並解除安裝（offload）動態內容的，所以我們們沒有必要把 CDN 的服務範圍限定在靜態資源。（另外需要你記住的是），不管你的 CDN 是否執行內容壓縮（GZip）、內容轉換、HTTP/2 傳輸以及 ESI（一種標記語言，可以用它把網頁劃分為單獨的可快取的實體）等操作，我們還是需要複核上述操作的，這是因為上述操作不僅會在 CDN 的 edge 處（伺服器最接近使用者的地方）聚合頁面中的靜態以及動態內容，也還會執行其它任務。
注意：根據 Patrick Meenan 和 Andy Davies 的研究，HTTP / 2 在 許多CDN上 被 有效打破，因此我們不應該對其效能提升過於樂觀。