（轉）Web性能優化方案

第一章 打開網站慢現狀分析

 

在公司訪問部署在IDC機房的VIP網站時會感受很慢。是什麼緣由形成的？爲了縮短頁面的響應時間，改進咱們的用戶體驗，咱們須要知道用戶的時間花在等待什麼東西上。

 

       能夠跟蹤一下咱們的登陸頁面，以下圖所示

 

    從上圖咱們能夠分析知道，HTML文檔只佔了總響應時間的20%，其它80%響應時間用來下載JS、CSS、圖片等組件。因此WEB前端有很大的優化空間，咱們將從WEB的前端優化、後端優化兩方面綜合考慮給出WEB的性能優化方案。

 

 

 

第二章 WEB前臺的優化規則

 

1、儘可能減小 HTTP 請求

 

有幾種常見的方法能切實減小 HTTP 請求：

 

一、 合併腳本跟樣式文件，如能夠把多個 CSS 文件合成一個，把多個 JS 文件合成一個。

 

二、 CSS Sprites 利用 CSS background 相關元素進行背景圖絕對定位,把多個圖片合成一個圖片。

 

 

 

2、使用瀏覽器緩存

 

       在用戶瀏覽網站的不一樣頁面時，不少內容是重複的，好比相同的JS、CSS、圖片等。若是咱們可以建議甚至強制瀏覽器在本地緩存這些文件，將大大下降頁面產生的流量，從而下降頁面載入時間。

 

   根據服務器端的響應header，一個文件對瀏覽器而言，有幾級不一樣的緩存狀態。

 

   一、服務器端告訴瀏覽器不要緩存此文件，每次都到服務器上更新文件。

 

   二、服務器端沒有給瀏覽器任何指示。

 

   三、在上次傳輸中，服務器給瀏覽器發送了Last-Modified或Etag數據，再次瀏覽時瀏覽器將提交這些數據到服務器，驗證本地版本是否最新的，若是爲最新的則服務器返回304代碼，告訴瀏覽器直接使用本地版本，不然下載新版本。通常來講，有且只有靜態文件，服務器端纔會給出這些數據。

 

   四、服務器強制要求瀏覽器緩存文件，並設置了過時時間。在緩存未到期以前，瀏覽器將直接使用本地緩存文件，不會與服務器端產生任何通訊。

 

       咱們要作的是儘可能強制瀏覽器到第四種狀態，特別是對於JS、CSS、圖片等變更較少的文件。

 

 

 

3、使用壓縮組件

 

IE和Firefox瀏覽器都支持客戶端GZIP，傳輸以前，先使用GZIP壓縮再傳輸給客戶端，客戶端接收以後由瀏覽器解壓，這樣雖然稍微佔用了一些服務器和客戶端的CPU，可是換來的是更高的帶寬利用率。對於純文原本講，壓縮率是至關可觀的。若是每一個用戶節約50%的帶寬，那麼租用來的那點帶寬就能夠服務多一倍的客戶，而且縮短了數據的傳輸時間。

 

 

 

4、圖片、JS的預載入

 

預載入圖像最簡單的方法是在 JavaScript 中實例化一個新 Image() 對象，而後將須要載入的圖像的 URL 做爲參數傳入。

 

function preLoadImg(url) {

 

var img = new Image();

 

img.src = url;

 

}

 

能夠在登陸頁面預載入JS和圖片

 

 

 

5、將腳本放在底部

 

腳本放在頂部帶來的問題，

 

一、  使用腳本時，對於位於腳本如下的內容，逐步呈現將被阻塞

 

二、  在下載腳本時會阻塞並行下載

 

放在底部可能會出現JS錯誤問題，當腳本沒加載進來，用戶就觸發腳本事件。

 

要綜合考慮狀況。

 

 

 

6、將樣式文件放在頁面頂部

 

若是樣式表任在加載，構建呈現樹就是一種浪費，樣式文件放在頁面底部可能會出現兩種狀況：

 

一、  白屏

 

二、  無樣式內容的閃爍

 

 

 

7、使用外部的JS和CSS

 

將內聯的JS和CSS作成外部的JS、CSS。減小重複下載內聯的JS和CSS。

 

 

 

8、切分組件到多個域

 

主要的目的是提升頁面組件並行下載能力。但不要跨太多域名，建議採用2個子域名。

 

 

 

9、精簡JS

 

能夠作到兩個級別

 

一、精簡：從代碼中移除沒必要要的字符以減小其大小，

 

二、混淆：在精簡的同時，還會改寫代碼，函數、變量名被轉換成更短的字符串

 

可使用ShrinkSafe來精簡JS  http://shrinksafe.dojotoolkit.org/

 

 

 

10、精簡CSS

 

從代碼中移除沒必要要的字符以減小其大小，

 

可使用CSS Compressor http://www.cssdrive.com/index.php/main/csscompressor /

 

 

 

11、       精簡圖片、Flash

 

對大圖片、Flash，要在效果和大小之間作出平衡。

 

第三章 程序的優化

 

第四章 數據庫的優化

 

附錄A 頁面請求分析

 

  從輸入URL到頁面呈現須要下面5個步驟

 

1． 輸入URL地址或者點擊URL的一個連接

 

　2． 瀏覽器根據URL地址，結合DNS，解析出URL對應的IP地址

 

　3． 發送HTTP請求

 

　4． 開始鏈接請求的服務器而且請求相關的內容

 

　5． 瀏覽器解析從服務器端返回的內容，而且把頁面顯現出來

 

 

 

上面基本上就是一個頁面從請求到實現的基本過程，下面咱們將剖析這個過程。

 

 

 

當輸入URL以後，瀏覽器就要知道這個URL對應的IP是什麼，只有知道了IP地址，瀏覽器才能準備的把請求發送到指定的服務器的具體IP和端口號上面。瀏覽器的DNS解析器負責把URL解析爲正確的IP地址。這個解析的工做是要花時間的，並且這個解析的時間段內，瀏覽器不是能從服務器那裏下載到任何的東西的。瀏覽器和操縱系統提供了DNS解析緩存支持。

 

 

 

當得到了IP地址以後，那麼瀏覽器就向服務器發送HTTP的請求，過程以下：

 

1．瀏覽器經過發送一個TCP的包，要求服務器打開鏈接

 

2．服務器也經過發送一個包來應答客戶端的瀏覽器，告訴瀏覽器鏈接開了。

 

3．瀏覽器發送一個HTTP的GET請求，這個請求包含了不少的東西了，例如咱們常見的cookie和其餘的head頭信息。

 

這樣，一個請求就算是發過去了。

 

 

 

請求發送去以後，以後就是服務器的事情了，服務器端的程序把最後的結果發送到客戶端。

 

  其實首先到達瀏覽器的就是html的那些文檔，所謂的html的文檔，就是純粹的html代碼，不包含什麼圖片，腳本，CSS等的。也就是頁面的html結構。由於此時返回的只是頁面的html結構。這個html文檔的發送到瀏覽器的時間是很短的，通常是佔整個響應時間的10%左右。

 

  這樣以後，那麼頁面的基本的骨架就在瀏覽器中了，下一步就是瀏覽器解析頁面的過程，也就是一步步從上到下的解析html的骨架了。

 

若是此時在html文檔中，遇到了img標籤，那麼瀏覽器就會發送HTTP請求到這個img響應的URL地址去獲取圖片，而後呈現出來。若是在html文檔中有不少的圖片，flash，那麼瀏覽器就會一個個的請求，而後呈現，若是每一個圖片都要請求，那麼就要進行以前說的那些步驟：解析url，打開tcp鏈接等等。打開鏈接也是要消耗資源的，就像咱們在進行數據庫訪問同樣，咱們也是儘量的少開數據庫鏈接，多用鏈接池中的鏈接。道理同樣，tcp鏈接也是能夠重用的。http1.1提出了持久鏈接（persistent connection）的概念，也就是說同一條 HTTP 鏈接，能夠同時處理多個請求，減小tcp鏈接。

 

當頁面的html骨架載入了以後,瀏覽器就開始解析頁面中標籤,從上到下開始解析。

 

首先是head標籤的解析，若是發如今head中有要引用的JS腳本，那麼瀏覽器此時就開始請求腳本，此時整個頁面的解析過程就停了下來，一直到JS請求完畢。以後頁面接着向下解析，如解析body標籤，若是在body中有img標籤，那麼瀏覽器就會請求img的src對應的資源，若是有多個img標籤，那麼瀏覽器就一個個的解析，解析不會像JS那樣等待的，會併發的下載。