摘要：性能最好具有可量化可監(jiān)測以及可改動的特性。下文是一份年的前端性能優(yōu)化清單，闡述了作為前端開發(fā)人員，為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。地圖設計的決定違背了性能理念，所以他在這份清單內的順序有待考慮。

2017前端性能優(yōu)化清單

你開始使用漸進啟動了么？是不是已經使用過React和Angular中tree-shaking和code-splitting兩個工具？有沒有用過Brotli、Zofli和HPACK這幾種壓縮技術，或者OCSP協(xié)議（在線證書狀態(tài)協(xié)議）？知不知道資源提醒，客戶端提醒和CSS containment一類的技術？了解IPv6，HTTP/2和Service Worker這些協(xié)議嗎？

回想那些年，大家往往在完成了產品之后才會去考慮性能。常常把與性能相關的事情拖到項目的最后來做，所做的也不過是對服務器上的config文件進行一些微調、串聯(lián)、優(yōu)化以及部分特別小的調整。而現(xiàn)在，技術已經有了翻天覆地的變化。

一個項目的性能是非常重要的，除了要在技術層面上注意，更要在項目的設計之初就開始考慮，這樣才可以使性能的各種隱形需求完美的整合到項目中，隨著項目一起推進。性能最好具有可量化、可監(jiān)測以及可改動的特性。網絡越來越復雜，對網絡的監(jiān)控也變得越來越難，因為監(jiān)測的過程會受到包括設備、瀏覽器、協(xié)議、網絡類型以及其他技術（CDN，ISP，緩存，代理服務器，防火墻，負載均衡器和服務器對性能的影響都很大）的很大影響。

下文是一份2017年的前端性能優(yōu)化清單，闡述了作為前端開發(fā)人員，為了確保反饋速度以及瀏覽器兼容性我們需要考慮的問題。

（你也可以下載checklist PDF或者check in Apple Pages。優(yōu)化萬歲！）

正文

微優(yōu)化是保持性能最好的辦法，但是又不能有太過明確的優(yōu)化目標，因為過于明確的目標會影響在項目中做的每一個決定。以下是一些不同的模型，請按照自己舒服的順序閱讀。

請準備好然后定下目標！ 1. 比你最強的競爭對手快20%

根據(jù)一個心理學研究，你的網站最少在速度上比別人快20%，才能讓用戶感覺到你的網站比別人的更快。這個速度說的不是整個頁面的加載時間，而是開始加載渲染的時間，首次有效渲染時間（例如頁面需要加載主要內容的時間），或者交互時間（指的是頁面或者應用中主要的頁面加載完成，并主備好與用戶進行交互的時間）。

在Moto G（一個中端三星設備）和Nexus 4（比較主流的設備）上衡量開始渲染時間（用WebPagetest）以及首頁有效渲染時間（用Lighthouse），最好是在一個開放的實驗室中，使用規(guī)范的3G，4G和Wi-Fi鏈接。

Lighthouse，一個Google開發(fā)的新的性能審查工具

你可以通過你的分析報告看看你的用戶處在哪個階段，選取其中前90%的用戶體驗來做測試。接著收集數(shù)據(jù)，建一個表格，篩去20%的數(shù)據(jù)并預設一個目標（如：性能預算）。現(xiàn)在你可以將上述兩個值進行對比檢測。如果你始終維持著你的目標并且通過一點一點改變腳本去加快交互時間，那么上述方法就是合理可行的。

由Brad Frost創(chuàng)建的性能分析

和你的同事分享這份清單。首先要確保團隊中的每個人都熟悉這份清單。項目中每一個決定都會影響性能，如果前端工程師們都在積極的參與項目概念，UX以及視覺設計的決定，這將會給整個項目帶來巨大收益。地圖設計的決定違背了性能理念，所以他在這份清單內的順序有待考慮。

2. 反應時間為100毫秒，幀數(shù)是每秒60幀

RAIL性能模型會為你提供一個優(yōu)秀的目標，既盡最大的努力在用戶初始操作后的100毫秒內提供反饋。為了達到這個目標，頁面需要放棄權限，并將權限在50毫秒內交回給主線程。對于像動畫一樣的高壓點，最好的方法就是什么都不做，因為你永遠無法達到最小絕對值。
同理，動畫的每一幀都需要在16毫秒內完成，這樣才能保證每秒60幀（一秒/60=16.6毫秒），如果可以的話最好能在10毫秒內完成。因為瀏覽器需要一定的時間去在屏幕上渲染新的幀，而且你的代碼需要在16.6毫秒內完成執(zhí)行。要注意，上述目標應用于衡量項目的運行性能，而非加載性能。

3. 首次有效渲染時間要低于1.25秒，速度指數(shù)要低于1000

縱使這個目標實現(xiàn)起來非常困難，你的最終目標也應該是讓開始渲染時間低于1秒且速度指數(shù)低于1000（在網速快的地方）。對于首次有效渲染時間，上限最好是1250毫秒。對于移動端，3G下移動設備首次渲染時間低于3秒都是可以接受的。稍微高一點也沒關系，但千萬別高太多。

定義你所需要的環(huán)境 4. 選擇和安裝你的開發(fā)環(huán)境

不要過多的關注當下最流行的工具，堅持選擇適合自己開發(fā)環(huán)境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者組合起來的工具。只要這個工具運行的速度夠快，而且沒有給你的維護帶來太大問題，這就夠了。

5. 漸進增強（progressive enhancement）

在構建前端結構的時候，應始終將漸進增強作為你的指導原則。首先設計并且構建核心體驗，隨后再完善那些為高性能瀏覽器設計的高級特性的相關體驗，創(chuàng)建彈性體驗。如果你的網頁可以在使用低速網絡、老舊顯示器的很慢的電腦上運行飛快，那么在光纖高配電腦上它只會運行的更快。

6. Angular，React，Ember等

最好使用那些支持服務器端渲染的框架。在使用某個框架錢，先記錄服務器和客戶端的引導時間，記得要在移動設備上測試，最終才能使用某個框架（因為面對的是性能問題，如果在使用某個框架后，再做修改是非常困難的）。如果你使用JavaScript框架，要保證你的選擇是被廣泛使用并且經過考驗的。不同框架對性能有著不同程度的影響，同時對應著不同的優(yōu)化策略，所以最好可以清楚的了解你要用的框架的每個方面。在寫網頁應用時可以先看看PRPL pattern和application shell architecture。

本圖描述了PRPL pattern

上圖是application shell，是一個小型的、由HTML,CSS和JavaScript構成的用戶界面

7. AMP還是Instant Articles？

根據(jù)你整體組織結構的優(yōu)先順序和策略，你可以考慮使用Google的AMP或Facebook的Instant Articles。要知道沒有這些你也可以達到不錯的性能，但是AMP可以提供一個性能不錯的免費的內容分發(fā)網絡框架（CDN），Instant Articles可以在Facebook上促進你的性能。你也可以建立progressive web AMP。

8. 選擇適合你的CDN

根據(jù)你的動態(tài)數(shù)據(jù)量，可以將一部分內容外包給靜態(tài)網站生成工具，將它置于CDN上，從中生成一個靜態(tài)版本，從而避免那些數(shù)據(jù)庫的請求。也可以選擇基于CDN的靜態(tài)主機平臺，通過交互組件豐富你的頁面（JAMStack）。

注意CDN是否可以很好的處理（或分流）動態(tài)內容。沒必要單純的將你的CDN限制為靜態(tài)。反復檢查CDN是否執(zhí)行了內容的壓縮和轉化，檢查智能HTTP/2傳輸和緩存服務器（ESI），注意哪些靜態(tài)或動態(tài)的部分處在CDN的邊緣（最接近用戶的服務器）。

開始優(yōu)化 9. 直接確定優(yōu)化順序

首先應該弄清楚你想解決的問題是什么。檢查一遍你所有的文件（JavaScript，圖片，字體，第三方script文件以及頁面中重要的模塊，例如輪播，復雜信息圖標和多媒體內容），并將他們分類。
列一個表格。明確瀏覽器上應該有的基礎核心內容，哪些部分屬于為高性能瀏覽器設計的升級體驗，哪些是附加內容（那些不必要或者可以被延時加載的部分，例如字體，不必要的樣式，輪播組件，播放器，社交網站入口，很大的圖片）。更詳細的細節(jié)請參考文章”Improving Smashing Magazine’s Performance‘’。

10. 使用符合標準的技術

使用符合標準的技術向過時的瀏覽器提供核心體驗，向老式瀏覽器提供增強體驗, 同時對所加載的內容要有嚴格的把控。即首要加載核心體驗部分，將增強部分放在DomContentLoaded，把額外內容發(fā)在load事件中。

以前我們可以通過瀏覽器的版本推斷出設備的性能，但現(xiàn)在我們已經無法推測了。因為現(xiàn)在市場上很多廉價的安卓手機都不考慮內存限制和CPU性能，直接使用高版本的Chrome瀏覽器。一定要注意，在我們沒有其他選擇的時候，我們選擇的技術同時可能成為我們的限制。

11. 考慮微優(yōu)化和漸進啟動

在一些應用中，可以在渲染頁面前先初始化應用。最好先顯示框架，而不是一個進度條或指示器。使用可以加速初始渲染時間的模塊或技術（例如tree-shaking和code-splitting），因為大部分性能問題來自于應用引導程序的初始分析時間。還可以在服務器上提前編譯，從而減輕部分客戶端的渲染過程，從而快速輸出結果。最后，考慮使用Optimize.js來加快初始加載速度，它的原理是包裝優(yōu)先級高的調用函數(shù)（雖然現(xiàn)在已經沒什么必要了）。

漸進啟動指的是使用服務器端渲染，從而快速得到首次有效渲染，這個渲染過程也包括小部分的JavaScript文件，目的是使交互時間盡可能的接近首次有效渲染時間。

到底采用客戶端渲染還是服務器端渲染？不論哪種做法，我們的目標都是建立漸進啟動：使用服務器端渲染可以得到很短的首次有效渲染時間，這個渲染過程也包括小部分的JavaScript文件，目的是使交互時間盡可能的接近首次有效渲染時間。接下來，盡可能的增加一些應用的非必要功能。不幸的是，正如Paul Lewis所說，框架基本上對開發(fā)者是沒有優(yōu)先級的概念的，因此漸進啟動在很多庫和框架上是很難實施的。如果你有時間的話，還是考慮使用策略去優(yōu)化你的性能吧。

12. HTTP的緩存頭使用的合理嗎？

仔細檢查一下例如expires，cache-control，max-age以及其他HTTP緩存頭是否被正確的使用。一般來說，資源不論在短時間（如果它會被頻繁改動）還是不確定的時間內（如果它是靜態(tài)的）都是可緩存的——你大可在需要的時候在URL中成改版本。

如果可能，使用為指紋靜態(tài)資源設計的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文件被解決之前，瀏覽器不會開始對頁面進行渲染。作為開發(fā)者，我們要明確的告訴瀏覽器不要等待，直接開始渲染。具體方法是使用HTML中的defer和async兩個屬性。

事實上，defer更好一些（因為對于IE9及以下用戶對于IE9及以下用戶，很有可能會中斷腳本）。同時，減少第三方庫和腳本的使用，尤其是社交網站的分享按鍵和