Web前端性能優化總結——如何提升網頁加載速度

 

1、提升網頁加載速度的必要性

國際知名的一組來自Jupiter Research的數據顯示：購物者在訪問網站過程當中的不滿會致使銷售損失和品牌受損，其中 77%的人將再也不訪問網站 ，62%的人再也不從該網站上購買，48%會轉向競爭對手，28%的人對公司產生負面印象。

此組數據分析顯示：Google網站訪問速度每慢400 ms就將致使用戶搜索請求降低 0.59%；Amazon表示，增長 100ms的網站延遲將致使其收入降低 1%；雅虎網站若是有400ms 延遲會致使流量降低 5-9%…

大數據分析代表：當網站首頁打開時間超過4秒時，約60%的用戶會放棄繼續訪問瀏覽，83%的用戶但願首頁打開時間不要超過4秒。

據調查發現，影響用戶體驗的因素有不少，如購物方便性、網站合理佈局等，但最重要的是網站性能和網站可用性能，這兩項對用戶的影響佔到了69%。

結語：網站網頁加載速度越慢，用戶體驗度就越低，將致使網站擁有者的收益大幅減小。所以，提升網頁加載速度就成了前端工程師的必修課之一。

2、前端性能優化

網頁加載順序：1.DNS查找 > 2.下載並渲染HTML文件 > 3.下載並執行css及js組件 > 4.下載圖片

如下性能優化列表，按照對網頁加載速度的提高幅度排序

1. 減小DNS查找

DNS查找，即瀏覽器根據url中域名，查找該域名對應的服務器IP地址，而後才能根據服務器IP地址，下載到文件。在DNS查找完成以前，全部的文件下載都沒法執行。每一次DNS查找時間約20-120ms。

通常而言，電腦會進行DNS緩存，包括瀏覽器緩存、系統緩存、路由器緩存、ISP DNS緩存。因此，瀏覽器DNS查找順序通常是這樣的：瀏覽器緩存→系統緩存→路由器緩存→ISP DNS 緩存→遞歸搜索。

遞歸搜索，即ISP的DNS服務器從根域名開始進行遞歸查詢，查找時間通常爲20-120ms。

若沒有DNS緩存，纔會執行DNS遞歸搜索。可是顯而易見，第一次訪問網站首頁時，是不會有DNS緩存的，必然會執行DNS查找。而每個DNS查找，須要耗時20-120ms。所以，減小DNS查找能加快網頁加載速度。

實例：

在開發頁面時，不少時候，咱們都要用到別人已經封裝好了的js及css文件，譬如jquery庫、angularjs庫、時間選擇插件、定位插件等等諸多插件，通常而言，網上都有公用的CDN，咱們不須要將這些文件下載到本地，就可使用它們。

譬如：w3c上推薦了谷歌的CDN，騰訊地圖也有本身的CDN庫，咱們能夠經過如下代碼，獲取到谷歌的jquery庫，以及騰訊的前端定位插件。

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"></script><!-- 引用谷歌jQuery庫 -->
<script type="text/javascript" src="https://3gimg.qq.com/lightmap/components/geolocation/geolocation.min.js"></script><!-- 引用騰訊前端定位插件 -->

　　這樣寫作起來十分方便，咱們能夠省去下載文件這一步驟。但實際上，這樣作會增長兩個DNS查找，即"ajax.googleapis.com"和"3gimg.qq.com"的DNS查找，將會在首次加載網站首頁時，拖慢首頁加載速度40-240ms，並且每再增長一個DNS查找，還會額外拖慢20-120ms的加載時間，這是極爲致命的。

　　不只如此，這兩個文件的下載速度分別取決於谷歌服務器及騰訊服務器的下載速度，這是徹底不可控的。而將本身網站所須要的文件，寄放在別人的服務器上，也是不安全的。例如，某一天谷歌的服務器抽風，沒法再下載文件，或是谷歌再也不支持該jquery庫，那麼咱們的網站將會失去jquery核心庫，會直接崩潰。更可怕的是，若谷歌在該jquery庫文件中添加某些攻擊性手段，將會直接致使網站處於危險狀態中。

　　所以，爲了減小DNS查找，爲了保障網站的安全，咱們必須將網站所需的文件下載到本地，而不是調用別人支持的CDN。

　　2. CSS優先加載，JS延遲加載

　　在解析HTML文件，構建DOM樹時，一旦遇到link標記時，即遇到了CSS樣式表，將之下載，即可當即構建渲染樹，從而當即呈現頁面效果。

　　而一旦遇到script 標記時，即遇到了JS腳本，將當即阻塞DOM樹的構建，將控制權移交給 JavaScript 引擎，等到 JavaScript 引擎運行完畢，瀏覽器纔會從中斷的地方恢復渲染樹的構建。這涉及到瀏覽器渲染原理，詳情請見本人上一篇博客：瀏覽器渲染頁面的原理及流程

　　若將引入JS腳本的連接放到HTML頁面頂部，那麼在加載該頁面時，一旦遇到JS，頁面渲染就會停滯，出現一段時間的灰色空白，直到JS加載完成，纔會出現頁面內容，這對用戶體驗是不友好的。所以，咱們須要將JS腳本放置到頁面底部，或者讓JS腳本異步或是延遲加載。

　　實例：以下圖所示，該首頁有CSS樣式表一個，若將CSS樣式表置於JS腳本之下，那麼在加載完JS腳本以前，頁面都不會進行渲染，會出現108ms的灰色空白。該首頁有JS腳本文件5個，若將這5個JS文件放置在該首頁的頂部，那麼該首頁加載JS腳本時，也將會出現108ms的灰色空白。

　　

　　從嚴格意義上來講，CSS的優先加載及JS的延遲加載並不能從根本上提高網頁加載速度，可是它們能使網頁更快被渲染出來，使頁面內容逐步呈現，增長用戶等待的耐心，提高用戶體驗。

　　3. 減小HTTP請求

　　HTTP請求，即客戶端到服務器端的請求消息，包括資源請求、數據處理等。

　　HTTP請求需從客戶端發起請求，而後由服務器端進行數據處理，而後再返回數據或資源。通常而言，耗時據請求資源的大小，服務器網速，約數ms-數百ms之間。請求資源越大，所花費的時間越長，服務器網速越慢，所花費的時間也越長。

　　通常而言，完成了DNS查找後，接下來即是進行HTTP請求，獲取資源。首先下載HTML文件，而後解析HTML文件，根據HTML內容，獲取CSS、JS及圖片文件。每個CSS連接、JS連接以及圖片連接都是一個HTTP請求。

　　每個HTTP請求都須要花費額外的時間。所以，咱們能夠將一些可合併的資源進行合併，譬如將全部頁面的css合併成一個style.css文件，譬如將全部頁面的js合併成一個function.js文件，再譬如將一批小圖標利用ps合成一張圖片（此手段效果最顯著，也最經常使用）。雖然有時文件會變大，可是在HTTP請求中，請求下載一個大小爲100KB的資源文件，比請求下載兩個大小爲50KB的資源文件要快。

　　從實際測試來看，每減小一個HTTP請求，據請求資源大小，能加快網頁加載速度約數ms-數百ms。

　　實例：合併圖標

　　"用戶信息頁面"以下圖所示：四個輸入框左側，有四張icon，合計大小8.9KB，四個HTTP請求合計時間23ms。

　　我利用ps，將此四張圖片進行合併，而後以css的背景圖片進行引用，其結果以下圖所示：四個輸入框左側，四張icon合併後的大小6.0KB，一個HTTP請求時間8ms。減少圖片大小2.9KB，提高加載速度15ms。看起來提高速度很少，但按比例算，提高幅度巨大。

　　4. 縮小文件

　　衆所周知，HTTP請求中，返回的資源越大，HTTP請求所花費的時間越長，所以，縮小資源文件能夠提高HTTP請求的速度，進而提高頁面加載速度。不只如此，還能節省服務器流量及空間。

　　通常而言，縮小文件主要是指圖片壓縮，也包括CSS、JS文件壓縮，網上有成熟的代碼在線壓縮工具，譬如：在線JS/CSS/HTML 壓縮

　　而圖片壓縮主要是指圖片在不一樣的格式下、不一樣的分辨率下保存，其大小將會有巨大的差別。譬如同一張圖片的png格式與jpg格式肉眼看起來幾乎沒有區別，可是其大小相差了約5倍。而jpg格式中級也比高級要小約莫1倍。固然，圖片的不一樣格式有不一樣的用處，且分辨率越高，圖片也越清晰。

　　所以，根據需求爲圖片選擇合適的格式及分辨率，就能獲得最小的圖片文件。

　　具體操做：在ps中打開圖片，同時按下ctrl+alt+shift+s，打開"存儲爲web所用格式"彈框，便可任意選擇保存圖片的格式及分辨率（若按操做沒法順利壓縮圖片，請自行度娘）。

 　　實例：同一張圖片，jpg格式比png格式小約5倍，加載速度快約3倍。

　　縮小文件來提高頁面加載速度，從我我的的項目優化經驗來看，其效果極爲顯著，多個項目都提高了超過100ms的加載時間。

　　5. 善於利用緩存

　　避免在HTML文件中使用style標籤插入CSS樣式，及使用script標籤插入JS腳本。若在HTML文件中插入CSS及JS，那麼它們沒法進入緩存，每次刷新頁面，都要從新加載，不但浪費了瀏覽器資源，拖慢了頁面加載速度，並且顯得冗餘且複用性低，不利於往後的維護。所以，將CSS樣式與JS腳本分離出來，造成CSS文件及JS文件，就能進入緩存，進而提升頁面加載速度。

　　靈活使用cookie和localstorage。在使用接口時，靈活使用cookie和localstorage來緩存接口返回的信息，避免沒必要要的接口查詢，從而提高頁面加載速度。譬如：在登陸頁面登陸時，緩存好用戶信息，設置過時時間。在進入用戶我的中心頁面時，若數據並未過時，能夠直接從緩存中取用戶信息，沒必要再調起接口去獲取用戶信息。

　　實例：css、js、圖片均可進行緩存，從緩存中獲取文件，時間爲0ms。

　　

　　總結：以上幾點，對於頁面加載速度的提高效果都很顯著，只要作到以上幾點，只要服務器不坑，項目頁面加載速度都不會很慢。如下我將會從代碼的角度來提出幾點項目優化的經驗。

 　　6. HTML文件代碼優化

　　　　1. 避免使用空請求，包括空的href連接、空src連接。空連接自己沒法請求成功，所以會把一個HTTP請求拖到超時，並且空連接會阻塞頁面中其餘資源的下載進程，會拖慢頁面加載速度。譬如：<img src="" alt="">。

　　　　2. 根據項目大小，選擇主要使用class仍是id。id選擇器優先級最高，訪問速度最快。可是在html中每聲明一個id，就會在JS底層聲明一個全局變量，而全局變量的增多，將會拖慢JS中變量遍歷的效率，若變量遍歷達到十萬次以上，就會出現較顯著的延遲，並且容易形成全局變量污染。對於小項目，並沒有影響，可是對中大型項目來講，尤爲是遊戲項目，影響很大。我的推薦，當項目較小時，靈活使用class和id，當項目較大時，儘可能少使用id。

　　　　3. 預先設定圖片大小。在頁面加載過程當中，圖片最後加載，若不對圖片預設大小，當圖片加載完成後，將會引發大量的重排，將會浪費瀏覽器資源及拖慢頁面加載速度。

　　　　4. 儘可能減小DOM元素的數量與層級。解析HTML時，標籤的數量越多，標籤的層級越深，瀏覽器解析構建DOM樹的時間就越長，應儘量的減小DOM元素的數量和層級。

　　　　5. 儘可能避免使用table標籤。瀏覽器對table標籤的解析是所有生成後再一次性繪製的，所以會形成表格位置較長時間的空白，推薦使用ul及li標籤繪製表格。

　　　　6. 使用異步加載iframe標籤。瀏覽器加載iframe標籤時，會阻塞父頁面渲染樹的構建及HTTP請求，所以儘可能使用異步加載iframe。

　　　　等等…

　　7. CSS樣式代碼優化

　　　　1. 禁止使用樣式表達式。CSS表達式從IE5起開始支持，但僅有IE支持。它的解析速度較慢，並且運算次數遠比咱們想象的要大，隨意動動鼠標就能輕鬆達到上萬次運算，會對頁面性能形成影響。譬如："#myDiv{width:expression(document.body.offsetWidth - 110 + "px"); }"

 　　　　2. 優化關鍵選擇器，去掉無效的父級選擇器，儘可能少在選擇器末尾使用通配符。大多數人都認爲，瀏覽器對CSS選擇器的解析式從左往右進行的，譬如選擇器："#myDiv ul li a"，大多數人會認爲這個選擇器效率極高，畢竟第一個ID #myDiv 就已經把範圍限定了，先選擇 #myDiv ，再在 #myDiv 下尋找 ul ，再一級一級往下，直到找到 a 標籤，效率很高。事實上這是錯的，瀏覽器對CSS選擇器的解析式從右往左進行的。在上述選擇器中，瀏覽器會先去尋找 a 標籤，範圍爲全局，再在 a 標籤的列表中，尋找父級標籤是 li 標籤的 a 標籤，一直向上，直到最後，找到父級標籤是 #myDiv ul li 的a標籤。所以，效率並不像想象中那麼高。顯而易見，"#myDi a"選擇器比"#myDiv ul li a"選擇器效率要高得多。而通配符 a 的效率遠比類選擇器及id選擇器低，若給 a 標籤添加一個class myA ，構造新選擇器："#myDiv .myA"，它的效率又遠比"#myDi a"要高了。瀏覽器對CSS選擇器的解析式從右往左進行，所以在選擇器末尾最好使用類選擇器，而不是通配符。CSS選擇器效率問題詳情請見：CSS選擇器效率問題

 　　　　等等…

　　8. JS代碼優化

　　　　1. ajax請求方法按需求選擇get或是post，訪問接口所花費的時間在頁面加載時間中佔很大的比重，而接口訪問方法中，get方法遠比post方法要快，所以按需選擇接口訪問方法很重要。

　　　　2. 減小全局變量，儘可能使用局部變量。js中，全局變量運算速率遠低於局部變量，速度差別達到上百倍，且全局變量越多，全局變量的查找速率便越慢。詳情請見：減小全局變量對效率的提高

　　　　3. 減小對DOM的操做。js操做DOM將會引發頁面的重繪及重排，須要花費時間及耗費瀏覽器資源。

　　　　等等…

　　結語：前端性能優化是一門完整的學問，並不是一兩篇博客所能詳盡的。以上我只是按照頁面加載速度的提高幅度寫了幾點，其實還有大量優化手段，難以詳盡。譬如：圖片懶加載、按需加載、預加載等等，再譬如：從網絡加載角度進行優化、從渲染角度進行優化、從架構協議角度進行優化等等

　　學無止境，諸君共勉！