2017前端性能優化清單
你開始使用漸進啟動了么？是不是已經使用過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 或非死book的 Instant Articles 。要知道沒有這些你也可以達到不錯的性能，但是AMP可以提供一個性能不錯的免費的內容分發網絡框架（CDN），Instant Articles可以在非死book上促進你的性能。你也可以建立 progressive web AMP 。
8. 選擇適合你的CDN
根據你的動態數據量，可以將一部分內容外包給 靜態網站生成工具 ，將它置于CDN上，從中生成一個靜態版本，從而避免那些數據庫的請求。也可以選擇基于CDN的 靜態主機平臺 ，通過交互組件豐富你的頁面（ JAMStack ）。
注意CDN是否可以很好的處理（或分流）動態內容。沒必要單純的將你的CDN限制為靜態。反復檢查CDN是否執行了內容的壓縮和轉化，檢查智能HTTP/2傳輸和緩存服務器（ESI），注意哪些靜態或動態的部分處在CDN的邊緣（最接近用戶的服務器）。
開始優化
9. 直接確定優化順序
首先應該弄清楚你想解決的問題是什么。檢查一遍你所有的文件（JavaScript，圖片，字體，第三方script文件以及頁面中重要的模塊，例如輪播，復雜信息圖標和多媒體內容），并將他們分類。
列一個表格。明確瀏覽器上應該有的基礎核心內容，哪些部分屬于為高性能瀏覽器設計的升級體驗，哪些是附加內容（那些不必要或者可以被延時加載的部分，例如字體，不必要的樣式，輪播組件，播放器，社交網站入口，很大的圖片）。
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緩存中——事實上越多越好！
來自：http://web.jobbole.com/91025/