為什么要提升web性能？

Web性能黃金準(zhǔn)則：只有10%~20%的最終用戶響應(yīng)時(shí)間花在了下載html文檔上，其余的80%~90%時(shí)間花在了下載頁(yè)面組件上。

web性能對(duì)于用戶體驗(yàn)有及其重要的影響，根據(jù)著名的`2-5-8`原則：

當(dāng)用戶在2秒以內(nèi)得到響應(yīng)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)非常快 當(dāng)用戶在2-5秒之內(nèi)得到響應(yīng)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度還可以 當(dāng)用戶在5-8秒之內(nèi)得到響應(yīng)，會(huì)感覺(jué)系統(tǒng)的響應(yīng)非常慢，但還可以接受 當(dāng)用戶在8秒之后都沒(méi)有得到響應(yīng)，會(huì)感覺(jué)系統(tǒng)糟透了，甚至系統(tǒng)已經(jīng)掛掉；要么打開(kāi)競(jìng)爭(zhēng)對(duì)手的網(wǎng)站，要么重新發(fā)起第二次請(qǐng)求。

凡事都需要研究，通過(guò)科學(xué)的研究我們就可以找到事物的發(fā)展規(guī)律。這里要感謝工程師總結(jié)的14條前端優(yōu)化法則，使得我們可以站在巨人的肩膀上。《高性能網(wǎng)站建設(shè)》這本書(shū)中的14條優(yōu)化原則，總結(jié)起來(lái)主要是以下個(gè)方面的優(yōu)化：

減少HTTP請(qǐng)求

頁(yè)面內(nèi)部?jī)?yōu)化

啟用緩存

減少下載量

網(wǎng)絡(luò)連接上的優(yōu)化

為什么減少HTTP請(qǐng)求可以提高Web性能？

要回答這個(gè)問(wèn)題，我們就要了解當(dāng)瀏覽器向服務(wù)器發(fā)送一個(gè)http請(qǐng)求知道獲取數(shù)據(jù)都經(jīng)歷哪些過(guò)程：

開(kāi)啟一個(gè)鏈接（tcp/ip的三次握手過(guò)程） -> 發(fā)送請(qǐng)求 -> 等待（網(wǎng)絡(luò)延遲跟服務(wù)器的處理時(shí)間） -> 下載數(shù)據(jù)

我們看一下百度首頁(yè)中的http請(qǐng)求在各階段耗費(fèi)的時(shí)間，上面不同的顏色代表下圖中的不同階段

可以看到除了圖片之外，其余大部分http請(qǐng)求的事件花在了建立連接與等待階段。

http協(xié)議建立在TIC/IP協(xié)議之上，在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個(gè)連接。 簡(jiǎn)單來(lái)說(shuō)三次握手就是一個(gè)身份確認(rèn)的過(guò)程：

（第一次握手：主機(jī)A發(fā)送位碼為syn＝1,隨機(jī)產(chǎn)生seq number=1234567的數(shù)據(jù)包到服務(wù)器，主機(jī)B由SYN=1知道，A要求建立聯(lián)機(jī)；）

（第二次握手：主機(jī)B收到請(qǐng)求后要確認(rèn)聯(lián)機(jī)信息，向A發(fā)送ack number=(主機(jī)A的seq+1),syn=1,ack=1,隨機(jī)產(chǎn)生seq=7654321的包）

（第三次握手：主機(jī)A收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1,以及位碼ack是否為1，若正確，主機(jī)A會(huì)再發(fā)送ack number=(主機(jī)B的seq+1),ack=1，主機(jī)B收到后確認(rèn)seq值與ack=1則連接建立成功。）

言歸正傳，這個(gè)過(guò)程也是需要消耗時(shí)間的，在百度首頁(yè)找到一個(gè)極端的例子：

而等待的時(shí)間通常也大于內(nèi)容下載的時(shí)間，這里同樣找到一個(gè)極端例子：

由此我們可以得出結(jié)論：一個(gè)http請(qǐng)求絕大多數(shù)的時(shí)間消耗在了建立連接跟等待的時(shí)間，優(yōu)化的方法是減少http請(qǐng)求。

如何提高web性能？

1、減少HTTP請(qǐng)求

一般來(lái)說(shuō)要減少http請(qǐng)求通常從兩個(gè)方面下手：減少圖片的請(qǐng)求、減少腳本文件與樣式表的請(qǐng)求

圖片的減少通常有兩種方式：css sprites、內(nèi)聯(lián)圖片、IconFont。

CSS Sprites：將多張圖片合并成一幅單獨(dú)的圖片，使用css的background-position屬性，將html元素的背景圖片放到sprites 圖片中的期望位置上。使用這項(xiàng)技術(shù)的附加優(yōu)點(diǎn)是他降低了下載量，合并后的圖片比分離的圖片和更小，因?yàn)樗档土藞D片自身的開(kāi)銷(xiāo)（顏色表、格式信息等等）。實(shí)際項(xiàng)目中css sprites是一項(xiàng)體力活，因?yàn)殚_(kāi)發(fā)過(guò)程中需要對(duì)這張大圖進(jìn)行維護(hù)（添加、減少圖片），張?chǎng)涡裢瑢W(xué)的文章中有介紹如何管理sprites圖片可以作為參考（這里）。如果需要在頁(yè)面中為背景、鏈接、導(dǎo)航欄提供大量的圖片，css sprites絕對(duì)是一種優(yōu)秀的解決方案（干凈的標(biāo)簽、較少的圖片、較短的響應(yīng)時(shí)間）。

內(nèi)聯(lián)圖片：通過(guò)使用data:URL模式可以再頁(yè)面中包含圖片而無(wú)需任何額外的請(qǐng)求。缺點(diǎn)就是IE8以下的瀏覽器不支持這種方式，而IE8在數(shù)據(jù)大小上有限制，只能支持23kb以內(nèi)的數(shù)據(jù)。對(duì)于較小的圖片來(lái)說(shuō)可以直接內(nèi)聯(lián)到web頁(yè)面中，但對(duì)于大圖片內(nèi)聯(lián)到頁(yè)面里會(huì)導(dǎo)致頁(yè)面變大，聰明的做法是使用css，將內(nèi)聯(lián)的圖片作為背景使用，并放到外部樣式表中，這意味著數(shù)據(jù)可以緩存在樣式表內(nèi)部。使用外部樣式表雖然增加了一個(gè)http請(qǐng)求，但樣式可以被瀏覽器緩存，得到額外的收獲。另外一點(diǎn)需要注意：base64是有損壓縮。

IconFont：圖標(biāo)字體，這是近年來(lái)新流行的一種以字體代替圖片的技術(shù)。它可以適應(yīng)任何分辨率而不會(huì)出現(xiàn)圖片模糊問(wèn)題，與圖片相比它具有更小的容量，更高的靈活性（像字體一樣可以設(shè)置圖標(biāo)大小、顏色、透明度、hover狀態(tài)、反轉(zhuǎn)等），IE8以上的瀏覽器都支持該技術(shù)。在使用IconFont之前，你首先要確定你選則的字體庫(kù)是否是收費(fèi)。詳細(xì)內(nèi)容可以參考這篇文章：圖標(biāo)字體化淺談

減少腳本與樣式表的請(qǐng)求主要原則就是合并。在實(shí)際開(kāi)發(fā)中我們遵循模塊化的原則將代碼分散到許多小文件中，按照軟件開(kāi)發(fā)的原則這是完全正確的，但對(duì)于上線頁(yè)面來(lái)說(shuō)，每一個(gè)文件都會(huì)產(chǎn)生一個(gè)http請(qǐng)求，嚴(yán)重影響性能。和css sprites一樣，將這些小文件合并到一個(gè)文件中，可以減少http請(qǐng)求的數(shù)量并縮短最終用戶響應(yīng)時(shí)間。在合并過(guò)程中我們還需要使用工具精簡(jiǎn)（移除不必要的字符以減小文件大小縮減下載時(shí)間）和混淆（除了移除不必要字符外，還會(huì)改寫(xiě)源代碼，比如函數(shù)和變量名使用更短的標(biāo)量名）Javascript代碼。對(duì)于采用AMD或CMD進(jìn)行模塊化開(kāi)發(fā)的同學(xué)，在合并過(guò)程中通常會(huì)將依賴的其他模塊打包到一個(gè)文件中，而模板html通常以字符串的方式內(nèi)聯(lián)到Javascript文件中。目前最常用的前端構(gòu)建工具就是glup，這里有一篇初步應(yīng)用的文章：前端 | gulp 打包 require.js 模塊依賴

2、頁(yè)面內(nèi)部?jī)?yōu)化

關(guān)于頁(yè)面內(nèi)部?jī)?yōu)化主要方向：樣式表放在頂部、腳本文件放在底部、避免css表達(dá)式、把腳本的樣式表放在外部、移除重復(fù)腳本

關(guān)心性能的工程師都希望頁(yè)面能否盡快的展現(xiàn)在用戶面前，對(duì)于頁(yè)面中很多內(nèi)容的頁(yè)面我們都希望內(nèi)容能夠逐步加載，為用戶提供可視化回饋。而將樣式表放在底部會(huì)導(dǎo)致瀏覽器阻止內(nèi)容逐步呈現(xiàn)。為避免當(dāng)頁(yè)面變化時(shí)重繪頁(yè)面元素，瀏覽器會(huì)阻塞頁(yè)面呈現(xiàn)，直到樣式表解析完畢（詳細(xì)內(nèi)容可以查看我的這篇博客）。所以如果將樣式表放在頂部并不會(huì)減少資源的加載時(shí)間，它減少的是頁(yè)面的呈現(xiàn)時(shí)間。小米主頁(yè)曾經(jīng)犯過(guò)這樣的錯(cuò)誤：

將樣式表放在底部會(huì)阻塞頁(yè)面的逐步呈現(xiàn)，而將script文件放在頁(yè)面頂部同樣會(huì)阻塞頁(yè)面的逐步呈現(xiàn)。script元素會(huì)阻塞后續(xù)內(nèi)容的解析，因?yàn)閟cript中可以同過(guò)document.write來(lái)更改頁(yè)面。解決的辦法就是將script標(biāo)簽放在頁(yè)面底部。這樣既可以讓內(nèi)容逐步呈現(xiàn)，也可以提高下載的并行度。如果我們確定不需要document.write那可以為script標(biāo)簽加上asyn屬性（Ie中要加上defer）提高并行下載度。

CSS表達(dá)式是ie支持的可以用來(lái)動(dòng)態(tài)更改css屬性的一種方式，我們不需要了解太多，她的書(shū)寫(xiě)方式如下，一旦在產(chǎn)品中發(fā)現(xiàn)expression關(guān)鍵字就要徹底消滅。

使用外部腳本和樣式這一條，我想凡是有點(diǎn)經(jīng)驗(yàn)的工程師都會(huì)這么干。

移除重復(fù)腳本：這條說(shuō)的主要是避免在頁(yè)面中多次加入同一份Javascript代碼，如果我們的開(kāi)發(fā)中有依賴管理的方式比如AMD、CMD，基本不會(huì)出現(xiàn)這種情況。

3、啟用緩存

關(guān)于緩存的使用這里介紹兩套方案：expires/If-Modified-Since、Cache-Control/Etag；前者是HTTP1.0中的緩存方案，后者是HTTP1.1中緩存方案，若http頭部中同時(shí)出現(xiàn)二者，后者的優(yōu)先級(jí)更高。

If-modified-since的方式通常被稱為條件Get。瀏覽器緩存中保存了一個(gè)文件的副本，但需要向服務(wù)器詢問(wèn)此副本是否可用。If-Modified-Since是瀏覽器將最后修改時(shí)間發(fā)送給服務(wù)器，服務(wù)器相應(yīng)頭中Last-Modified進(jìn)行對(duì)比；若If-Modified-Since <= Last-Modified 則瀏覽器讀取本地副本。此時(shí)響應(yīng)狀態(tài)為304 Not Modified, 并不在發(fā)送響應(yīng)體。

Expries：雖然使用條件GET和304響應(yīng)能夠節(jié)省時(shí)間，但瀏覽器跟服務(wù)器端仍然要發(fā)送一次請(qǐng)求進(jìn)行確認(rèn)。通過(guò)明確設(shè)置副本的過(guò)期時(shí)間可以避免條件GET。當(dāng)瀏覽器發(fā)現(xiàn)響應(yīng)頭中的expires時(shí)，會(huì)將過(guò)期時(shí)間和文件一起保存到緩存中去。在過(guò)期之前一直從緩存中讀取。expires頭使用一個(gè)特定的時(shí)間來(lái)指定緩存的有效期，他要求瀏覽器與服務(wù)器時(shí)間完全一致。而且一旦過(guò)期，服務(wù)器端配置中需要重新設(shè)頂一個(gè)過(guò)期時(shí)間。

ETag（實(shí)體標(biāo)簽）：是服務(wù)器用于檢查瀏覽器緩存有效性的一種機(jī)制。ETag在HTTP1.1中引入，ETag是唯一標(biāo)識(shí)了一個(gè)組件的一個(gè)特定版本的字符串。唯一的格式約束是這個(gè)字符串必須使用雙引號(hào)。如果瀏覽器要驗(yàn)證一個(gè)組件是否有效他會(huì)使用If-None-Match將etag字符串傳送給服務(wù)器。如果ETag是匹配的，服務(wù)器端會(huì)返回304.（如果實(shí)體數(shù)據(jù)需要根據(jù)User-Agent或Accept-Language來(lái)改變時(shí)，ETag提供了更高的靈活性）。對(duì)于使用服務(wù)器集群的網(wǎng)站來(lái)說(shuō)，從一臺(tái)服務(wù)器到另一臺(tái)服務(wù)器，ETag通常是無(wú)法匹配的。這是ETag的問(wèn)題。而且即便同時(shí)使用If-Modified-Since和If-None-Match也并不能達(dá)到預(yù)期效果。解決方法總是有的：自定義Etag格式

Cache-Control：HTTP1.1引入了來(lái)代替Expires，它使用max-age指令來(lái)指定副本被緩存多久，該指令以秒為單位定義了一個(gè)更新窗，組件從被請(qǐng)求開(kāi)始到現(xiàn)在的秒數(shù)小于設(shè)定值，則一直使用副本。避免了一次http請(qǐng)求。相比Expries，Cache-Control指令提供了更細(xì)粒度的控制。詳細(xì)內(nèi)容請(qǐng)看大額同學(xué)的文章：透過(guò)瀏覽器看HTTP緩存

4、減少下載量

減少下載量最有效的方式就是開(kāi)啟gzip壓縮，gzip是GNU開(kāi)發(fā)的一種免費(fèi)格式。壓縮組件通過(guò)減小http響應(yīng)的大小來(lái)加快響應(yīng)速度。HTTP1.1通過(guò)使用Accept-Encoding來(lái)標(biāo)識(shí)支持的壓縮，如果服務(wù)器看到這個(gè)標(biāo)識(shí)，會(huì)使用請(qǐng)求頭中的一種方式來(lái)壓縮響應(yīng)。并通過(guò)Content-Encoding來(lái)通知web客戶端。很多網(wǎng)站會(huì)壓縮html文件，實(shí)際上包括xml跟json在內(nèi)的任何文本都可以壓縮，但圖片和pdf不應(yīng)該壓縮。根據(jù)經(jīng)驗(yàn)通?？梢詫?duì)大于1kb或2kb的文件進(jìn)行壓縮。壓縮通常能將響應(yīng)的數(shù)據(jù)量減少70%。壓縮的成本在于：服務(wù)器需要耗費(fèi)額外的cpu進(jìn)行壓縮，客戶端需要解壓縮。所以需要在cpu的消耗和數(shù)據(jù)塊的大小之間進(jìn)行取舍。

5、優(yōu)化網(wǎng)絡(luò)連接

網(wǎng)絡(luò)連接的優(yōu)化主要有三個(gè)規(guī)則：使用CDN加速、減少DNS查找、避免重定向

CDN：CDN是地理上分布的web server的集合，用于更高效地發(fā)布內(nèi)容。通?；诰W(wǎng)絡(luò)遠(yuǎn)近來(lái)選擇給具體用戶服務(wù)的web server。 這縮短了資源的傳輸響應(yīng)時(shí)間，有效提高web性能。

DNS用于映射主機(jī)名和IP地址，一般一次解析需要20～120毫秒。瀏覽器會(huì)首先根據(jù)頁(yè)面的主機(jī)名進(jìn)行域名解析，在有ISP返回結(jié)果之前頁(yè)面不會(huì)加載任何內(nèi)容，所以減少DNS查找可以有效降低等待時(shí)間。為達(dá)到更高的性能，DNS解析通常被多級(jí)別地緩存，如由ISP或局域網(wǎng)維護(hù)的caching server，本地機(jī)器操作系統(tǒng)的緩存（如windows上的DNS Client Service），瀏覽器。IE的缺省DNS緩存時(shí)間為30分鐘，F(xiàn)irefox的缺省緩沖時(shí)間是1分鐘。 我們能做的是盡量減少一個(gè)頁(yè)面的主機(jī)名，但要在瀏覽器最大并行下載數(shù)跟dns查找之間做權(quán)衡。根據(jù)研究，最好將主機(jī)名控制在2-4個(gè)內(nèi)。

重定向：將一個(gè)URL重新路由到另一個(gè)URL。重定向功能是通過(guò)301和302這兩個(gè)HTTP狀態(tài)碼完成的，如：

HTTP/1.1 301 Moved Permanently

Content-Type: text/html

瀏覽器自動(dòng)重定向請(qǐng)求到Location指定的URL上，重定向的主要問(wèn)題是降低了用戶體驗(yàn)。 種最耗費(fèi)資源、經(jīng)常發(fā)生而很容易被忽視的重定向是URL的最后缺少/，導(dǎo)致自動(dòng)產(chǎn)生結(jié)尾斜線的原因是，瀏覽器在進(jìn)行g(shù)et請(qǐng)求是必須指定一些路徑；如果沒(méi)有路徑它就會(huì)簡(jiǎn)單的使用文檔根。（主機(jī)缺少結(jié)尾斜線是不會(huì)發(fā)生重定向）缺少結(jié)尾斜線發(fā)生重定向是很多web服務(wù)器的默認(rèn)行為。需要在服務(wù)器端設(shè)置方可消除。以下圖片是豆瓣的一個(gè)url請(qǐng)求：

這14條優(yōu)化規(guī)則在很長(zhǎng)的一段時(shí)間里發(fā)揮著重要作用，隨著技術(shù)的發(fā)展，單單這十四條原則已經(jīng)不能夠滿足前端性能優(yōu)化。