關於Web效能優化方案的詳細介紹

#第一章 開啟網站慢現況分析

在公司訪問部署在IDC機房的VIP網站時會感覺很慢。是什麼原因造成的？為了縮短頁面的回應時間，改善我們的使用者體驗，我們需要知道使用者的時間花在等待某些東西上。

       可以追蹤我們的登入頁面，如下圖

    從上圖我們可以分析知道，HTML文件只佔了總回應時間的20%，其它80%回應時間用來下載JS、CSS、圖片等組件。所以WEB前端有很大的最佳化空間，我們將從WEB的前端優化、後端優化兩方面綜合考慮給出WEB的效能最佳化方案。

第二章 WEB#1 前台的最佳化規則

一、盡量減少 HTTP 請求

有幾種常見的方法可以實際減少 #請求：

1、 合併腳本跟樣式文件，如可以把多個CSS 文件合成一個，把多個 JS 檔合成一個。

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

二、使用瀏覽器快取

#

       當使用者瀏覽網站的不同頁面時，許多內容是重複的，例如相同的JS、CSS、圖片等。如果我們能夠建議甚至強制瀏覽器在本地快取這些文件，將大大降低頁面產生的流量，從而降低頁面載入時間。

   根據伺服器端的回應header，一個檔案對瀏覽器而言，有幾個不同的快取狀態。

   1、伺服器端告訴瀏覽器不要快取此文件，每次都會到伺服器更新文件。

   2、伺服器端沒有給瀏覽器任何指示。

   3、在上次傳輸中，伺服器給瀏覽器發送了Last-Modified或Etag數據，再次瀏覽時瀏覽器將提交這些資料到伺服器，驗證本機版本是否最新的，如果為最新的則伺服器傳回304程式碼，告訴瀏覽器直接使用本機版本，否則下載新版本。一般來說，有且只有靜態文件，伺服器端才會給出這些資料。

   4、伺服器強制要求瀏覽器快取文件，並設定了過期時間。在快取未到期之前，瀏覽器將直接使用本機快取文件，不會與伺服器端產生任何通訊。

       我們要做的是盡量強制瀏覽器到第四種狀態，特別是對於JS、CSS、圖片等變動較少的文件。

三、使用壓縮元件

IE和Firefox瀏覽器都支援客戶端GZIP，傳輸之前，先使用GZIP壓縮再傳送給客戶端，客戶端接收之後由瀏覽器解壓縮，這樣雖然稍微佔用了一些伺服器和客戶端的CPU，但是換來的是更高的頻寬利用率。對於純文字來講，壓縮率是相當可觀的。如果每個用戶節省50%的頻寬，那麼租用來的那點頻寬就可以服務多一倍的客戶，並且縮短了資料的傳輸時間。

四、圖片、JS的預載入

#預先載入映像最簡單的方法是在 JavaScript 中實例化一個新 Image() 對象，然後將需要載入的圖像的 URL 作為參數傳入。

function preLoadImg(url) {
var img = new Image();
img.src = url;
}

可以在登入頁面預先載入JS和圖片

五、將腳本放在底部

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

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

2、

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

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

要綜合考慮情況。

六、

將樣式檔放在頁面頂部

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

1、 白屏

2、 無樣式內容的閃爍

七、使用外部的JS和CSS

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

八、切分元件到多個網域

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

九、精簡#JS

可以做到兩個等級

1、精簡：從程式碼移除不必要的字元以減少其大小，

#2、混淆：在精簡的同時，也會改寫程式碼，函數、變數名稱轉換成更短的字串

#第十、精簡CSS

#從程式碼移除不必要的字元以減少大小，

十一、       精簡圖片、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那樣等待的，會並發的下載。

以上是關於Web效能優化方案的詳細介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！