你開始使用漸進啟動了麼？是不是已經使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Brotli、Zofli和HPACK這幾種壓縮技術，或者OCSP協議（線上證照狀態協議）？知不知道資源提醒，客戶端提醒和CSS containment一類的技術？瞭解IPv6，HTTP/2和Service Worker這些協議嗎？
回想那些年，大家往往在完成了產品之後才會去考慮效能。常常把與效能相關的事情拖到專案的最後來做，所做的也不過是對伺服器上的config檔案進行一些微調、串聯、優化以及部分特別小的調整。而現在，技術已經有了翻天覆地的變化。
一個專案的效能是非常重要的，除了要在技術層面上注意，更要在專案的設計之初就開始考慮，這樣才可以使效能的各種隱形需求完美的整合到專案中，隨著專案一起推進。效能最好具有可量化、可監測以及可改動的特性。網路越來越複雜，對網路的監控也變得越來越難，因為監測的過程會受到包括裝置、瀏覽器、協議、網路型別以及其他技術（CDN，ISP，快取，代理伺服器，防火牆，負載均衡器和伺服器對效能的影響都很大）的很大影響。
下文是一份2017年的前端效能優化清單，闡述了作為前端開發人員，為了確保反饋速度以及瀏覽器相容性我們需要考慮的問題。
（你也可以下載checklist PDF或者check in Apple Pages。優化萬歲！）
正文
微優化是保持效能最好的辦法，但是又不能有太過明確的優化目標，因為過於明確的目標會影響在專案中做的每一個決定。以下是一些不同的模型，請按照自己舒服的順序閱讀。
請準備好然後定下目標！
1. 比你最強的競爭對手快20%
根據一個心理學研究，你的網站最少在速度上比別人快20%，才能讓使用者感覺到你的網站比別人的更快。這個速度說的不是整個頁面的載入時間，而是開始載入渲染的時間，首次有效渲染時間（例如頁面需要載入主要內容的時間），或者互動時間（指的是頁面或者應用中主要的頁面載入完成，並主備好與使用者進行互動的時間）。
在Moto G（或中端三星裝置）和Nexus 4（比較主流的裝置）上衡量開始渲染時間（用WebPagetest）以及首頁有效渲染時間（用Lighthouse），最好是在一個開放的實驗室中，使用規範的3G，4G和Wi-Fi連結。
Lighthouse，一個Google開發的新的效能審查工具
你可以通過你的分析報告看看你的使用者處在哪個階段，選取其中前90%的使用者體驗來做測試。接著收集資料，建一個表格，篩去20%的資料並預設一個目標（如：效能預算）。現在你可以將上述兩個值進行對比檢測。如果你始終維持著你的目標並且通過一點一點改變指令碼去加快互動時間，那麼上述方法就是合理可行的。
由Brad Frost建立的效能分析
和你的同事分享這份清單。首先要確保團隊中的每個人都熟悉這份清單。專案中每一個決定都會影響效能，如果前端工程師們都在積極的參與專案概念，UX以及視覺設計的決定，這將會給整個專案帶來巨大收益。地圖設計的決定違背了效能理念，所以他在這份清單內的順序有待考慮。
2. 反應時間為100毫秒，幀數是每秒60幀
RAIL效能模型會為你提供一個優秀的目標，既盡最大的努力在使用者初始操作後的100毫秒內提供反饋。為了達到這個目標，頁面需要放棄許可權，並將許可權在50毫秒內交回給主執行緒。對於像動畫一樣的高壓點，最好的方法就是什麼都不做，因為你永遠無法達到最小絕對值。
同理，動畫的每一幀都需要在16毫秒內完成，這樣才能保證每秒60幀（一秒/60=16.6毫秒），如果可以的話最好能在10毫秒內完成。因為瀏覽器需要一定的時間去在螢幕上渲染新的幀，而且你的程式碼需要在16.6毫秒內完成執行。要注意，上述目標應用於衡量專案的執行效能，而非載入效能。
3. 首次有效渲染時間要低於1.25秒，速度指數要低於1000
縱使這個目標實現起來非常困難，你的最終目標也應該是讓開始渲染時間低於1秒且速度指數低於1000（在網速快的地方）。對於首次有效渲染時間，上限最好是1250毫秒。對於移動端，3G下移動裝置首次渲染時間低於3秒都是可以接受的。稍微高一點也沒關係，但千萬別高太多。
定義你所需要的環境
4. 選擇和安裝你的開發環境
不要過多的關注當下最流行的工具，堅持選擇適合自己開發環境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者組合起來的工具。只要這個工具執行的速度夠快，而且沒有給你的維護帶來太大問題，這就夠了。
5. 漸進增強（progressive enhancement）
在構建前端結構的時候，應始終將漸進增強作為你的指導原則。首先設計並且構建核心體驗，隨後再完善那些為高效能瀏覽器設計的高階特性的相關體驗，建立彈性體驗。如果你的網頁可以在使用低速網路、老舊顯示器的很慢的電腦上執行飛快，那麼在光纖高配電腦上它只會執行的更快。
6. Angular，React，Ember等
最好使用那些支援伺服器端渲染的框架。在使用某個框架錢，先記錄伺服器和客戶端的引導時間，記得要在移動裝置上測試，最終才能使用某個框架（因為面對的是效能問題，如果在使用某個框架後，再做修改是非常困難的）。如果你使用JavaScript框架，要保證你的選擇是被廣泛使用並且經過考驗的。不同框架對效能有著不同程度的影響，同時對應著不同的優化策略，所以最好可以清楚的瞭解你要用的框架的每個方面。在寫網頁應用時可以先看看PRPL pattern和application shell architecture。
本圖描述了PRPL pattern
上圖是application shell，是一個小型的、由HTML,CSS和JavaScript構成的使用者介面
7. AMP還是Instant Articles？
根據你整體組織結構的優先順序和策略，你可以考慮使用Google的AMP或Facebook的Instant Articles。要知道沒有這些你也可以達到不錯的效能，但是AMP可以提供一個效能不錯的免費的內容分發網路框架（CDN），Instant Articles可以在Facebook上促進你的效能。你也可以建立progressive web AMP。
8. 選擇適合你的CDN
根據你的動態資料量，可以將一部分內容外包給靜態網站生成工具，將它置於CDN上，從中生成一個靜態版本，從而避免那些資料庫的請求。也可以選擇基於CDN的靜態主機平臺，通過互動元件豐富你的頁面（JAMStack）。
注意CDN是否可以很好的處理（或分流）動態內容。沒必要單純的將你的CDN限制為靜態。反覆檢查CDN是否執行了內容的壓縮和轉化，檢查智慧HTTP/2傳輸和快取伺服器（ESI），注意哪些靜態或動態的部分處在CDN的邊緣（最接近使用者的伺服器）。
開始優化
9. 直接確定優化順序
首先應該弄清楚你想解決的問題是什麼。檢查一遍你所有的檔案（JavaScript，圖片，字型，第三方script檔案以及頁面中重要的模組，例如輪播，複雜資訊圖示和多媒體內容），並將他們分類。
列一個表格。明確瀏覽器上應該有的基礎核心內容，哪些部分屬於為高效能瀏覽器設計的升級體驗，哪些是附加內容（那些不必要或者可以被延時載入的部分，例如字型，不必要的樣式，輪播元件，播放器，社交網站入口，很大的圖片）。更詳細的細節請參考文章”Improving Smashing Magazine’s Performance‘’。
10. 使用符合標準的技術
使用符合標準的技術向過時的瀏覽器提供核心體驗，向老式瀏覽器提供增強體驗, 同時對所載入的內容要有嚴格的把控。即首要載入核心體驗部分，將增強部分放在DomContentLoaded，把額外內容發在load事件中。
以前我們可以通過瀏覽器的版本推斷出裝置的效能，但現在我們已經無法推測了。因為現在市場上很多廉價的安卓手機都不考慮記憶體限制和CPU效能，直接使用高版本的Chrome瀏覽器。一定要注意，在我們沒有其他選擇的時候，我們選擇的技術同時可能成為我們的限制。
11. 考慮微優化和漸進啟動
在一些應用中，可以在渲染頁面前先初始化應用。最好先顯示框架，而不是一個進度條或指示器。使用可以加速初始渲染時間的模組或技術（例如tree-shaking和code-splitting），因為大部分效能問題來自於應用載入程式的初始分析時間。還可以在伺服器上提前編譯，從而減輕部分客戶端的渲染過程，從而快速輸出結果。最後，考慮使用Optimize.js來加快初始載入速度，它的原理是包裝優先順序高的呼叫函式（雖然現在已經沒什麼必要了）。
漸進啟動指的是使用伺服器端渲染，從而快速得到首次有效渲染，這個渲染過程也包括小部分的JavaScript檔案，目的是使互動時間儘可能的接近首次有效渲染時間。
到底採用客戶端渲染還是伺服器端渲染？不論哪種做法，我們的目標都是建立漸進啟動：使用伺服器端渲染可以得到很短的首次有效渲染時間，這個渲染過程也包括小部分的JavaScript檔案，目的是使互動時間儘可能的接近首次有效渲染時間。接下來，儘可能的增加一些應用的非必要功能。不幸的是，正如Paul Lewis所說，框架基本上對開發者是沒有優先順序的概念的，因此漸進啟動在很多庫和框架上是很難實施的。如果你有時間的話，還是考慮使用策略去優化你的效能吧。
12. HTTP的快取頭使用的合理嗎？
仔細檢查一下例如expires，cache-control，max-age以及其他HTTP快取頭是否被正確的使用。一般來說，資源不論在短時間（如果它會被頻繁改動）還是不確定的時間內（如果它是靜態的）都是可快取的——你大可在需要的時候在URL中成改版本。
如果可能，使用為指紋靜態資源設計的Cache-control:immutable，從而避免二次驗證（2016年12月，只有FireFox在https://處理中支援）。你可以使用，Heroku的primer on HTTP caching headers，Jake Archibald的 ”Caching Best Practices”，還有IIya Grigorik的HTTP caching primer作為指導。
13. 減少使用第三方庫，載入JavaScript非同步操作
當使用者請求頁面時，瀏覽器會抓取HTML同時生成DOM，然後抓取CSS並建立CSS物件模型，最後通過匹配DOM和CSS物件生成渲染樹。在需要處理的JavaScript檔案被解決之前，瀏覽器不會開始對頁面進行渲染。作為開發者，我們要明確的告訴瀏覽器不要等待，直接開始渲染。具體方法是使用HTML中的defer和async兩個屬性。
事實上，defer更好一些（因為對於IE9及以下使用者對於IE9及以下使用者，很有可能會中斷指令碼）。同時，減少第三方庫和指令碼的使用，尤其是社交網站的分享按鍵和嵌入（比如地圖）。你可以使用靜態的社交網站分享按鍵（例如SSBG的）和指向互動地圖的靜態連結去代替他們。
14. 圖片是否被正確優化？
儘可能的使用帶有srcset，sizes還有元素的響應式圖片。你也可以利用元素的WebP格式，用JPEG格式作為替補（參見Andreas Bovens的code snippet）或是使用內容協商（使用接受頭）。Sketch原本就支援WebP，WebP圖片可以直接被Photoshop的WebP plugin匯出。當然也有很多其他方法。
響應圖片斷點生成器可自動處理圖片
你也可以使用客戶端提示，現在瀏覽器也可以做到。在用來生成響應圖片的原始檔過少時，使用響應圖片斷點生成器或類似Cloudinary的服務自動的優化圖片。在很多案例中，單獨使用sreset和sizes都帶來了很大的收益。在本網站上，我們給檔案新增-opt字尾——例如brotli-compression-opt.png；這樣團隊的每一個人就知道這些帶著後最的圖片是被優化過的。
15. 圖片的進一步優化
當你在編寫登陸介面的時候，發現頁面上的圖片載入的特別快，這時你需要確認一下JPEG格式檔案是否已經通過mozJPEG（它可以操作掃描等級從而提高渲染時間）優化和壓縮，PNG格式對應Pingo，GIF需要用到Lossy GIF，SVG要使用SVGOMG。對圖片不重要的部分進行模糊處理（使用高斯模糊過濾器處理他們），從而減少檔案大小，最後你可能還要去彩色化使圖片變成黑白，從而減少更多的容量。對於背景圖片，使用Photoshop保持0到10%的質量輸出是絕對可以接受的。
如果你還覺得不夠，那你可以通過多重背景圖片技術來提高圖片的感知效能。
16. 網頁字型優化了嗎？
你用來修飾網頁字型的服務很有可能毫無用處，包括字形和額外的特性。如果你在使用開源的字型，嘗試用字型庫中某一個小的子集或是自己歸類一個小的子集從而壓縮檔案大小（例如通過一些特殊的注音符號引用Latin）。WOFF2 support是個非常不錯的選擇，如果瀏覽器不支援，那你可以將WOFF和OTF作為備用。你也可以從Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”一文中選擇一個合適的策略，然後使用伺服器來快取字型。如果想要快速入門，Pixel Ambacht的教程與案例會讓你的字型變得盡然有序。
Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”提供了一打可以讓字型傳輸變得更好的選項
如果你用的是第三方伺服器主機，沒辦法自己在伺服器上對字型進行操作，一定看看Web Font Loader。FOUT is better than FOIT中提到，在備選情況下立即渲染文字，並且非同步載入字型——你也可以使用loadCSS實現這個。你可能也會避免本地OS上安裝字型。
17. 快速執行關鍵部分的CSS
為了確保瀏覽器儘可能快的渲染你的頁面，先收集頁面首次可見部分的CSS檔案（也叫決定性CSS或上半版CSS）進行渲染，然後將它加入頁面的部分，從而避免重複操作。因為慢啟動階段對交換包大小的限制，你關鍵CSS檔案的大小也被限制在14KB左右。如果高於這個值，瀏覽器需要重複一些步驟來獲取更多的樣式。關鍵CSS是允許你這樣做的。可能對每個模板都需要這個操作。如果可能，考慮一下用Fiament Group用的條件內斂方法。
通過HTTP/2，關鍵CSS可以單獨存為CSS檔案，通過伺服器傳輸，而且可以避免HTML膨脹。伺服器傳輸缺乏連續支援，並且存在一些超快取記憶體的問題（Hooman Beheshti演示的前144頁）。事實上，這樣會導致網路緩衝區膨脹。因為TCP的慢啟動，伺服器傳輸在穩定的連線下會更有效率。所以你可能需要建立帶有快取的HTTP/2伺服器傳輸機制。但請記住，新的cache-digest規則會否定手動建立的需要快取的伺服器的請求。
18. 通過tree-shaking和code-splitting減少淨負載
Tree-shaking是通過保留那些在專案過程中真正需要的程式碼從而清理你的構建過程的一種方式。你可以用Webpack 2來提出那些沒用的住配置檔案，用UnCSS或Helium從CSS中取出不需要的樣式。同理，也可以考慮學習一下如何編寫高效的CSS選擇器，以及如何避免膨脹和高費的樣式。
Code-splitting是另一個Webpack特性，它可以根據按需載入的塊將你的程式碼分開。只要你在程式碼中定義了分離點，Webpack便會處理好相關的輸出檔案。它基本上能保證你初始下載的內容很小，而且在需求被新增時按需請求程式碼。
Rollup所展示的結果要比Browserify配置檔案所顯示的好得多。所以當我們想使用類似工具的時候，或許應該看看Rollupify，它將ECMAScript2015模組變成了一個更大的CommonJS模組——因為小模組沒準有出乎意料的高效能成本，這源自於你對打包工具模組系統的選擇。
19. 提升渲染效能
使用類似CSS containment的方法對高消耗組建進行隔離，從而限制瀏覽器樣式的範圍，可以作用在為無canvas的瀏覽工作的佈局和裝飾工作中，或是用在第三方工具上。要確保頁面滾動和出現動畫效果時沒有延遲，別忘了之前提到過的每秒60幀的原則。如果沒辦法做到，那就儘可能保證每秒幀數的大致範圍在15到60幀。使用CSS中的will-change通知瀏覽器哪些元素和屬性發生了變化。
也記得要衡量渲染執行中的效能（可以用DevTools）。可以參照Udacity上Paul Lewis的免費課程——瀏覽器渲染優化，作為入門。還有一篇Sergey Chikuyonok的文章講了如何正確的用GPU動畫。
20. 預熱網路連線，加快傳輸速度
使用頁面框架，對高消耗組建延遲載入（字型，JS檔案，迴圈播放，視訊和內嵌框架）。使用資源提示來節省在dns-prefetch（指的是在後臺執行DNS檢索），preconnect（指要求瀏覽器在後臺進行握手鍊接（DNS，TCP，TLS）），prerender（指要求瀏覽器在後臺對特定頁面進行渲染），preload（指的是提前取出暫不執行的原始檔）。根據你瀏覽器的支援情況，儘量使用preconnect來代替dns-prefetch，而且在使用prefetch和prerender要特別小心——後者（prerender）只有在你非常確信使用者下一步操作的情況下再去使用（比如購買流程中）。
HTTP/2
21. 準備好使用HTTP/2
Google開始向著更安全網頁的方向努力，並且將所有Chrome上的HTTP網頁定義為“不安全”時，你或許應該考慮是繼續使用HTTP/1.1，還是將目光轉向HTTP/2環境。雖然初期投入比較大，但是使用HTTP/是大趨勢，而且在熟練掌握之後，你可以使用service worker和伺服器推送技術讓行效能再提升一大截。
現在，Google計劃把所有HTTP頁面標記為不安全，並且將HTTP安全指示器設定為與Chrome用來攔截HTTPS的紅色三角相同的圖示。
使用HTTP/2的環境的缺點在於你要轉移到HTTPS上，並且根據你HTTP/1.1使用者的數量（主要指使用過時作業系統和過時瀏覽器的使用者），你需要適應不同的建構過程，才能傳送不同的建構。注意：不論是遷移還是新的構建過程都可能非常棘手而且耗時很多。
22. 適當部署HTTP/2
重申，使用HTTP/2協議之前，你需要徹底排查目前為止你所使用協議的情況。你需要在打包組建和同時載入很多小組間之間找到平衡。
一方面，你可能想要避免將很多資源鏈式連結，與其將你全部的介面分割成許多小模組，不如將他們壓縮使之成為建構過程的一部分，之後給它們賦予可檢索的資訊並載入它們。這樣的話，對一個檔案將不再需要重新下載整個樣式清單或JavaScript檔案。
另一方面，封裝是很有必要的，因為一次向瀏覽器傳送太多JavaScript檔案會出問題。首先，壓縮會造成損壞。得益於dictionary reuse，壓縮大檔案不會對檔案造成損害，壓縮小檔案則不然。確實有方法可以解決這個問題，但這不是本文討論的範疇。其次，瀏覽器還沒有優化到可以對類似工作流進行優化。例如，Chrome會引發程式間通訊（IPCs），這些通訊的數量與資源的數量成正比，而這成百上千個資源將會消耗大量的瀏覽器的執行時間。
Chrome的Jake Archibald建議，為了用HTTP/2達到最好的效果，考慮一下逐步載入CSS檔案
當然你可以考慮逐步載入CSS檔案。很顯然，你這樣做對HTTP/1.1的使用者非常不利，所以你可能需要根據不同的瀏覽器建立多個版本來應對你的排程過程，這樣就會使過程略微複雜。你也可以避免HTTP/2連線的合併，同時受益於HTTP/2來使用域名碎片，但是實現起來有些困難。
我們到底應該做什麼呢？如果你粗略的用過HTTP/2，似乎成功的傳送過10個左右的包（在老是瀏覽器上執行的也不錯）。那你就能著手開始試驗並且為你的網站找到平衡點。
23. 確保伺服器安全可靠
所有的瀏覽器都支援HTTP/2並且使用TLS，這是有你可能想要避免安全警告，並刪除頁面上沒用的元素。好好檢查你的安全頭部是否設定正確，排除已知的缺陷並檢查證照。
如果還沒有遷移到HTTP， 你那可以先看看HTTPS準則（The HTTPS-Only Standard）。確保所有外部外掛和監視指令碼都能被HTTPS正確載入，確保沒有跨站指令碼出現，HTTP指令碼傳輸的安全頭和內容安全頭也都設定正確。
24. 你的伺服器和CDN支援HTTP/2嗎？
不同伺服器和CDN對HTTP/2的相容性不同，你可以使用TLS夠快嗎？一文來檢視你有什麼選擇。
Is TLS Fast Yet？讓你能看看你的伺服器和CDN在使用HTTP/2的時候你能使用的工具
25. Brotli和Zopfli兩種壓縮演算法還在用嗎？
2015年，Google介紹了Brotli，一個新的開源無損資料格式，它已經被Chrome，Firefox和Opera很好的相容了。具體使用時，Brotli所顯示出的效率要遠高於Gzip和Deflate。它根據不同的配置可能壓縮的時候會比較慢，但是壓縮速度慢最後會讓壓縮效率提高。而且解壓起來非常快。因為這個演算法來自Google，所以瀏覽器只在使用者通過HTTPS訪問網頁的時候使用它，這個事情就不奇怪了。Brotli的隱患是它沒辦法在目前大部分伺服器上預設，而且如果沒有NGINX或者Ubuntu，部署起來還是有難度的。但其實你是可以在不支援它的CDN上使用Brotli（通過service worker）。
你可以看看Zopfli壓縮演算法作為備選，它將資料編碼為Deflate，Gzip和Zlib格式。任何規範的Gzip壓縮資源都受益於Zopfli改進了Deflate編碼，因為檔案會比Zlib壓縮的最大檔案小3%-8%。問題在於檔案會消耗大概80倍的時間去壓縮。這就是為什麼在不怎麼會變得資源上使用Zopfli是不錯的選擇，這樣的檔案一般都壓縮一次，下載多次。
26. OCSP裝訂是否可以使用？
讓伺服器使用OCSP裝訂，可以提升你TLS握手的速度。線證照狀態協議（OCSP）是作為證照廢置列表協議的代替品被創造出來的。兩個協議都可以用來檢測SSL證照是否被取消。然而，OCSP不需要瀏覽器花時間下載和掃描證照資訊的列表，所以它可以減少握手時間。
27. 你是否開始使用IPv6？
因為我們已經沒什麼IPv4的地址可用了，而且行動網路大都開始使用IPv6（美國已經有50%的入口採用IPv6），將你的DNS升級到IPv6為以後作打算是個不錯的選擇。要確保通網路可以支援雙棧協議——它需要允許IPv6和IPv4同時執行。畢竟IPv6不只是做為後備計劃的。而且研究顯示，伴隨鄰居發現（NDP）和路由優化，使用IPv6的網站要比普通網站快10%到15%。
28. 是否使用HPACK？
如果你在使用HTTP/2，看看你的伺服器有沒有執行HPACK對HTTP的響應頭進行壓縮，來減少不必要的消耗。因為HTTP/2伺服器相對較新，所以有些像HPACK這樣的規格目前還沒有被支援。我們可以用H2spec來檢查HPACK是否在工作。
H2spec的截圖
29. service workers是否為超快取記憶體和網路提供預設機制？
沒有經過優化的網路可以比使用者機器的本地快取跑得更快。如果你的網站在HTTPS上執行，你可以參考“實用主義者的service workers手冊”，然後把靜態資源存在service worker的快取中，把離線預設（甚至離線頁面）存在使用者機器方便檢索，這樣比多次進行網路連線更有效。你還可以參考Jake的離線使用手冊和免費的Udactiy課程“離線網路應用”。如果瀏覽器支援，那就再好不過了，預設就能在任何地方代替網路了。
測試與監聽
30. 監聽混合內容中的警告
如果你近期完成了HTTP到HTTPS的遷移，你可以利用類似Report-URI.io一類的對主動和被動的混合內容警告都進行監聽。也可以利用混合內容掃描器來對你使用HTTPS的網頁進行掃描。
31. 你的開發流程是否使用Devtools進行了優化？
選一個除錯工具來對每一個按鈕進行檢查。確保自己明白如何分析渲染效能和控制檯輸出、明白如何除錯JavaScript以及編輯CSS樣式。Umar Hansa最近有一個關於使用DevTools除錯和測試的分享，主要包括一些不常用的技巧和技術。
32. 是否使用代理瀏覽器和過時瀏覽器測試過？
僅僅使用Chrome和Firefox測試是不夠的。還應該看看你的網頁在代理瀏覽器和過時瀏覽器上執行的怎麼樣。比如UC瀏覽器和Opera Min, 它們在亞洲市場的份額很高（高達35%）。在推廣時，利用目標客戶所在國家的平均網速來進行測試，避免日後出現大的誤差。同樣的，不僅要在節流網路以及模擬的高資料處理裝置上進行測試，還要在真實裝置上測試。
33. 有無建立持續監聽？
在進行快速、無限制的測試時，最好使用一個個人的WebPageTest例項。建立一個能自動預警的效能預算監聽。建立自己的使用者時間標記從而測量並監測具體商用的資料。使用SpeedCurve對效能的變化進行監控，同時利用New Relic獲取WebPageTest沒法提供的資料。SpeedTracker，Lighthouse和Calibre都是不錯的選擇。
快速入門
這份清單綜合性很強，幾乎介紹了所有的可用的優化方式。那麼，如果你只有一個小時進行優化，你應該幹什麼呢？讓我們從中總結10個最有用的來。別忘了在你開始優化前和結束優化後，記錄你的結果，包括開始渲染時間以及在3G，有限連線下的速度。
- 有線連線下，你的目標是將開始渲染時間降低至1s一下，而3G的目標是保持在3s一下，SpeedIndex值保持在1000一下。為開始渲染時間和互動時間做優化。
- 為你主要的模板準備關鍵CSS檔案，將它們放在頁面的
中（你可以使用14KB）。- 對於你自己和第三方的指令碼檔案，儘可能的延遲載入它們——尤其是社交網站按鈕，播放器和高消耗的JavaScript檔案。
- 使用更快的
dns-lookup，preconnect，prefetch，preload和prerender新增資源提示，從而加快傳輸速度。- 將字型一類屬性作為子集，非同步載入（或者使用系統字型代替）。
- 優化圖片，並考慮在關鍵頁中使用WebP（例如登陸頁面）。
- 確保HTTP的快取頭和安全頭都被正確的設定。
- 在伺服器上使用Brotli或Zopfli壓縮演算法。（如果不支援這兩個，嘗試一下Gzip）
- 如果HTTP/2可用，使用HPACK壓縮演算法，並監聽混合內容的警告。如果你在使用LTS，就可以使用OCSP裝訂。
- 如果可能，將類似字型，JavaScript檔案以及圖片快取在service worker快取中——事實上越多越好！