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

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

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

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

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

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

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

正文

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

請準(zhǔn)備好然后定下目標(biāo)！ 1. 比你最強的競爭對手快20%

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

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

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

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

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

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

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

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

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

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

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

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

5. 漸進增強（progressive enhancement）

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

6. Angular，React，Ember等

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

本圖描述了PRPL pattern

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

7. AMP還是Instant Articles？

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

8. 選擇適合你的CDN

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

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

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

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

10. 使用符合標(biāo)準(zhǔn)的技術(shù)

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

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

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

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

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

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

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

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

如果可能，使用為指紋靜態(tài)資源設(shè)計的Cache-control:immutable，從而避免二次驗證（2016年12月，只有FireFox在https://處理中支持）。你可以使用，Heroku的primer on HTTP caching headers，Jake Archibald的 ”Caching Best Practices”，還有IIya Grigorik的HTTP caching primer作為指導(dǎo)。

13. 減少使用第三方庫，加載JavaScript異步操作

當(dāng)用戶請求頁面時，瀏覽器會抓取HTML同時生成DOM，然后抓取CSS并建立CSS對象模型，最后通過匹配DOM和CSS對象生成渲染樹。在需要處理的JavaScript文件被解決之前，瀏覽器不會開始對頁面進行渲染。作為開發(fā)者，我們要明確的告訴瀏覽器不要等待，直接開始渲染。具體方法是使用HTML中的defer和async兩個屬性。

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