改善用戶體驗 Web前端優化策略總結

前端是龐大的，包括HTML、CSS、Javascript、Image、Flash等等各類各樣的資源。前端優化是複雜的，針對方方面面的資源都有不一樣的方式。那麼，前端優化的目的是什麼？

 

1. 從用戶角度而言，優化可以讓頁面加載得更快、對用戶的操做響應得更及時，可以給用戶提供更爲友好的體驗。

2. 從服務商角度而言，優化可以減小頁面請求數、或者減少請求所佔帶寬，可以節省可觀的資源。

總之，恰當的優化不只可以改善站點的用戶體驗而且可以節省至關的資源利用。前端優化的途徑有不少，按粒度大體能夠分爲兩類，第一類是頁面級別的優 化，例如HTTP請求數、腳本的無阻塞加載、內聯腳本的位置優化等；第二類則是代碼級別的優化，例如Javascript中的DOM操做優化、CSS選擇 符優化、圖片優化以及HTML結構優化等等。另外，本着提升投入產出比的目的，後文提到的各類優化策略大體按照投入產出比從大到小的順序排列。

1、頁面級優化

1. 減小HTTP請求數

這條策略基本上全部前端人都知道，並且也是最重要最有效的。都說要減小HTTP請求，那請求多了到底會怎麼樣呢？首先，每一個請求都是有成本的，既包 含時間成本也包含資源成本。一個完整的請求都須要通過DNS尋址、與服務器創建鏈接、發送數據、等待服務器響應、接收數據這樣一個「漫長」而複雜的過程。 時間成本就是用戶須要看到或者「感覺」到這個資源是必需要等待這個過程結束的，資源上因爲每一個請求都須要攜帶數據，所以每一個請求都須要佔用帶寬。

另外，因爲瀏覽器進行併發請求的請求數是有上限的(具體參見此處)，所以請求數多了之後，瀏覽器須要分批進行請求，所以會增長用戶的等待時間，會給 用戶形成站點速度慢這樣一個印象，即便可能用戶能看到的第一屏的資源都已經請求完了，可是瀏覽器的進度條會一直存在。減小HTTP請求數的主要途徑包括：

(1). 從設計實現層面簡化頁面

若是你的頁面像百度首頁同樣簡單，那麼接下來的規則基本上都用不着了。保持頁面簡潔、減小資源的使用時最直接的。若是不是這樣，你的頁面須要華麗的皮膚，則繼續閱讀下面的內容。

(2). 合理設置HTTP緩存

緩存的力量是強大的，恰當的緩存設置能夠大大的減小HTTP請求。以有啊首頁爲例，當瀏覽器沒有緩存的時候訪問一共會發出78個請求，共600多K 數據（如圖1.1），而當第二次訪問即瀏覽器已緩存以後訪問則僅有10個請求，共20多K數據（如圖1.2）。（這裏須要說明的是，若是直接F5刷新頁面 的話效果是不同的，這種狀況下請求數仍是同樣，不過被緩存資源的請求服務器是304響應，只有Header沒有Body，能夠節省帶寬）

怎樣纔算合理設置？原則很簡單，能緩存越多越好，能緩存越久越好。例如，不多變化的圖片資源能夠直接經過HTTP Header中的Expires設置一個很長的過時頭；變化不頻繁而又可能會變的資源可使用Last-Modifed來作請求驗證。儘量的讓資源可以 在緩存中待得更久。

(3). 資源合併與壓縮

若是能夠的話，儘量的將外部的腳本、樣式進行合併，多個合爲一個。另外，CSS、Javascript、Image均可以用相應的工具進行壓縮，壓縮後每每能省下很多空間。

(4). CSS Sprites

合併CSS圖片，減小請求數的又一個好辦法。

(5). Inline Images

使用data: URL scheme的方式將圖片嵌入到頁面或CSS中，若是不考慮資源管理上的問題的話，不失爲一個好辦法。若是是嵌入頁面的話換來的是增大了頁面的體積，並且沒法利用瀏覽器緩存。使用在CSS中的圖片則更爲理想一些。

(6). Lazy Load Images

這條策略實際上並不必定能減小HTTP請求數，可是卻能在某些條件下或者頁面剛加載時減小HTTP請求數。對於圖片而言，在頁面剛加載的時候能夠只 加載第一屏，當用戶繼續日後滾屏的時候才加載後續的圖片。這樣一來，假如用戶只對第一屏的內容感興趣時，那剩餘的圖片請求就都節省了。有啊首頁曾經的作法 是在加載的時候把第一屏以後的圖片地址緩存在Textarea標籤中，待用戶往下滾屏的時候才「惰性」加載。

2. 將外部腳本置底

前文有談到，瀏覽器是能夠併發請求的，這一特色使得其可以更快的加載資源，然而外鏈腳本在加載時卻會阻塞其餘資源，例如在腳本加載完成以前，它後面 的圖片、樣式以及其餘腳本都處於阻塞狀態，直到腳本加載完成後纔會開始加載。若是將腳本放在比較靠前的位置，則會影響整個頁面的加載速度從而影響用戶體 驗。解決這一問題的方法有不少，在這裏有比較詳細的介紹（這裏是譯文和更詳細的例子），而最簡單可依賴的方法就是將腳本儘量的日後挪，減小對併發下載的 影響。

3. 異步執行inline腳本

inline腳本對性能的影響與外部腳本相比，是有過之而無不及。首頁，與外部腳本同樣，inline腳本在執行的時候同樣會阻塞併發請求，除此之 外，因爲瀏覽器在頁面處理方面是單線程的，當inline腳本在頁面渲染以前執行時，頁面的渲染工做則會被推遲。簡而言之，inline腳本在執行的時 候，頁面處於空白狀態。鑑於以上兩點緣由，建議將執行時間較長的inline腳本異步執行，異步的方式有不少種，例如使用script元素的defer屬 性（存在兼容性問題和其餘一些問題，例如不能使用document.write）、使用setTimeout，此外，在HTML5中引入了Web Workers的機制，偏偏能夠解決此類問題。

4. Lazy Load Javascript

隨着Javascript框架的流行，愈來愈多的站點也使用起了框架。不過，一個框架每每包括了不少的功能實現，這些功能並非每個頁面都須要 的，若是下載了不須要的腳本則算得上是一種資源浪費-既浪費了帶寬又浪費了執行花費的時間。目前的作法大概有兩種，一種是爲那些流量特別大的頁面專門定製 一個專用的mini版框架，另外一種則是Lazy Load。YUI則使用了第二種方式，在YUI的實現中，最初只加載核心模塊，其餘模塊能夠等到須要使用的時候才加載。

5. 將CSS放在HEAD中

若是將CSS放在其餘地方好比BODY中，則瀏覽器有可能還未下載和解析到CSS就已經開始渲染頁面了，這就致使頁面由無CSS狀態跳轉到CSS狀 態，用戶體驗比較糟糕。除此以外，有些瀏覽器會在CSS下載完成後纔開始渲染頁面，若是CSS放在靠下的位置則會致使瀏覽器將渲染時間推遲。

6. 異步請求Callback

在某些頁面中可能存在這樣一種需求，須要使用script標籤來異步的請求數據。相似：

 1 <script type="text/javascript">
 2    //Javascript:  
 3    /*Callback函數*/
 4    function myCallback(info) {
 5        //do something here  
 6    } 
 7 </script>    
 8 
 9 <!-- HTML:   -->
10 <script type = "text/javascript"
11 src = "http://abc.com/cb" >
12 </script>
13 <!-- cb返回的內容:  -->
14 <!-- myCallback('Hello world!'); -->

 

像以上這種方式直接在頁面上寫<script>對頁面的性能也是有影響的，即增長了頁面首次加載的負擔，推遲了DOMLoaded和 window.onload事件的觸發時機。若是時效性容許的話，能夠考慮在DOMLoaded事件觸發的時候加載，或者使用setTimeout方式來 靈活的控制加載的時機。

7. 減小沒必要要的HTTP跳轉

對於以目錄形式訪問的HTTP連接，不少人都會忽略連接最後是否帶’/'，假如你的服務器對此是區別對待的話，那麼你也須要注意，這其中極可能隱藏了301跳轉，增長了多餘請求。具體參見下圖，其中第一個連接是以無’/'結尾的方式訪問的，因而服務器有了一次跳轉。

8. 避免重複的資源請求

這種狀況主要是因爲疏忽或頁面由多個模塊拼接而成，而後每一個模塊中請求了一樣的資源時，會致使資源的重複請求。出現的概率不大，可是仍是要注意排查，否則可能會出現以下局面，來自這裏。

 

 

在網上看見的這篇，以爲總結的很是好，在這裏借鑑一下，不要見怪！