大家好，我是戈多，從事web開發工作接近三年了，今天來歸納下web前端優化的解決方案（碼農搬磚工，來自各網絡匯總）

1.減少Http請求

http請求越多，那麽消耗的時間越多，如果在加上網絡很糟糕，那麽問題就更多了。且如果網頁中的圖片、css文件、js文件很多甚至有音樂文件時，這勢必會造成負擔。

（1）圖片地圖

　即多個圖片排成一行作為鏈接到其他頁面的按鈕，我們當然可以使用五福圖片，發送5個http請求，但是這是不合適的。

　我們可以選擇使用圖片地圖，即只用一張圖片，然後使用<map>屬性通過控制坐標來實現

優點： 大幅加快加載速度，減少http請求； 缺點： 手工設置坐標非常麻煩

（2）CSS Sprite（可行）

即一個網頁上有很多的小圖片，比如有20個，如果我們都請求一遍，就需要使用20個http請求，這是很耗時的。

但是我們可以把這些圖片合成一個大的圖片，然後將之作為 background-img插入進去， 根據不同的圖片設置不同的background-postion即可，網易等就是采取的這種做法。

說明：雖然在不同的位置需要請求很多的圖片，但是，實際上我們查看網絡只會請求一次，如下面的頁面：

優點： 速度快，可以和圖片地圖相比擬。

使用場景： 一些很少改變的圖片（靜態的），如背景、按鈕、導航欄、連接等。缺點： 沒有缺點。

2.使用CDN內容分發網絡

CDN即 content distribute network,內容分發網絡。其原理是---盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。下面的這個例子可以很好的說明問題：古代打仗大家一定都知道，由於古代的交通很不發達，所以當外族進攻的時候往往不能及時的反擊，等朝廷征完兵再把兵派往邊境的時候那些侵略者卻是早已不見了蹤影，這個讓古代的帝王很是郁悶。後來帝王們學聰明了，都將大量的兵員提前派往邊境駐紮，讓他們平時屯田，戰時當兵，這樣的策略起到了很顯著的作用。

　　曾經一個網站的所有服務器都只在一個地方，但是現在不同了，因為我們知道http請求是耗時的，如果服務器用戶更近，請求的時間不久更短了嗎？ 所以可以將服務器置於多個分散的地方，而使用cdn就可以保證我們每次從最近的地方獲取到響應。

　　說明1： CDN只是用來提供靜態內容的，如圖片、腳本、樣式表和Flash。提供動態html頁面會引入特殊的存儲需求 - 數據庫連接、狀態管理、驗證、硬件和OS優化等。

　　說明2： 你所測試的CDN速度與你所處的位置、服務器位置都有很大的關系。

　　優點： 響應速度更快（大部分時間是這樣的）；

　　缺點1： 依賴CDN使得你的響應時間會受到其他網站-甚至是競爭對手網站流量的影響。因為CDN服務器提供商在其所有的客戶之間共享其Web服務器。

　　缺點2： 無法直接控制組件服務器所帶來的特殊麻煩。 如，修改HTTP響應頭必須通過服務提供商來完成，而不是你的工作團隊完成。

3.添加http Expires頭：

（1）為圖片視頻之類很少改變的資源設置長的Expires時間將直接減少http請求

（2）如果資源設置了Expires頭為將來的某個時間,下次訪問時候瀏覽器發現資源還沒有過期,會直接從緩存中讀取,不會再次產生http請求

4.壓縮組件:

在Server端對Response資源進行壓縮再傳給瀏覽器,一般使用GZIP

　使用減小文件體積的壓縮已經在E-mail和FTP站點中使用了10年，目前HTTP1.1也是開始支持了。其中，web客戶端可以通過HTTP請求中的Accept-Encoding來表示對壓縮的支持，如下所示：

　　顯然，只要是同一個客戶端，都會發送這樣的請求，其中，ｇｚｉｐ是免費的、標準的壓縮形式，而ｄｅｆｌａｔｅ用的則非常少。　

　　服務器端接收到這樣的請求之後，如果服務器將一個文件壓縮就會在響應的時候包含下面的字段表示對之進行了壓縮，如下所示：

　　一般，大多數的網站都會壓縮hTML、CSS和js腳本，通常不會壓縮圖片和PDF，因為他們本來就是已經被壓縮過的。

　　另外，壓縮是有成本的，因為服務器需要花費額外的CPU周期來完成對文件的壓縮， 並且當壓縮文件響應到了客戶端時，客戶端需要進行解壓縮，這都要時間，如果說耗費的時間還不如節省的時間，那就不要壓縮了。 美國前十的網站有9個都在壓縮HTML、而 css和js則是選擇性的。通過壓縮，可以將響應的額外的數據量較少將近70%。

5.使用link將CSS樣式表放在頂部: 能加快頁面內容顯示,並且能避免頁面產生白屏

6.將JS腳本放在底部

• JS會阻塞對其後面內容的呈現
• JS會阻塞對其後面內容的下載

7.避免CSS表達式：這是IE5支持的，早已不被推薦

8.將JS,CSS放在外部文件中

9.通過使用Keep-Alive和較少的域名來減少DNS查找

10.精簡JS和CSS文件

11.尋找一種避免重定向的方法

在重定向中使用的最多的狀態碼是 301 和 302， 而 303 和 307 是在HTTP1.1規範中添加的，用來澄清對302的使用（濫用），但是幾乎沒有人使用303和307，絕大多數網站仍然使用302.

一旦發生了重定向，就會嚴重阻塞html的傳輸。

12.移除重復的腳本

13.配置Etag

14.確保Ajax請求遵守性能知道,必要時候應具備長久的expires頭

我們可以使用Yahoo的Yslow firefox插件來檢查網站的前端性能.

最後,我們隨便打開一個淘寶寶貝頁面,用Fiddler查看一下,發現淘寶至少做了如下優化:

• 大規模使用CDN,圖片,jS,css互相之間都使用了不同的域名.單是圖片服務器,下面又使用了很多不同的服務器,比如img01.taobaocdn.com等等
• 當第二次瀏覽同一寶貝的時候,產生大量的Http 304請求.這樣既能保證獲取最新的資源,又能盡量減少數據傳輸
• CSS,JS文件大都精簡過
• 對於資源類的東西比如圖片,設置為不受保護.也就是說不需要登錄依然可以直接訪問的,這樣就避免設置/讀取cookie,達到節省網絡資源的目的

唯一一點沒有優化的是圖片,服務端返回的圖片都是沒有Gzip壓縮的,或許是為了減少服務器的壓力（壓縮是看服務器性能與網絡環境做的權衡）

web 前端優化-戈多編程