關於提升網站性能的幾點建議（一）

  最近在學習《高性能網站建設指南》這本書，本文算是一個學習筆記，將學到的東西進行整理一下，方便後面查看。

  性能黃金法則（Performance Golden Rule)解釋了只有10%~20%的最終用戶響應時間花在接受所請求的用戶HTML文檔上，剩餘的80%~90%時間花在爲HTML文檔所引用的全部組件（圖片、腳本、樣式表等）進行的HTTP請求上，最終用戶響應時間花費在頁面組件上
  ——Steve Sounders

1 文件合併（減小HTTP請求數量）

• CSS Sprites

  利用css sprites將網站用到的圖片合併成一張圖片，經過background-position、width、height控制背景圖位置來使用某一個圖標，這種方式能夠將多個圖片請求縮減爲一次，生成css sprites的工具也不少，grunt和gulp中都有相關的插件，CssGaga也不錯。

• 合併js和css

  和精靈圖同樣，合併css和js文件也是減小HTTP請求很重要的方式，對css文件的合併目前來講沒有什麼爭議，可是對於當前js模塊化盛行，將全部js文件合併成一個文件，彷彿是一種倒退。正確的方式是遵照編譯型語言的模式，保持js的模塊化，在生成過程當中只對初始請求用到的js文件生成目標文件。

2 使用內容發佈網絡（減小HTTP請求時間）

  HTTP請求時間另外一個影響因素是你與網站web服務器所處的距離，顯然距離越遠，請求所需的時間也越久，經過CDN能夠大大改善這一點。

  CDN是分佈在多個不一樣地理位置的web服務器，用於更加有效的向用戶發佈內容。CDN最主要的功能是給終端用戶存放靜態文件，另外也提供下載、安全服務等功能。

3 設置瀏覽器緩存（避免重複HTTP請求）

• 使用Expire/Cache-control

  瀏覽器經過使用緩存能夠避免每次都進行重複的請求，HTTP 1.0和HTTP1.1分別有不一樣的緩存實現方式，Expires(1.0)和Cache-control(1.1)。Web服務器經過expires告訴客戶端在指定的時間內，都使用該文件的緩存副本，再也不向服務端重複發出請求，例如：

Expires: Thu, 01 Dec 2016 16:00:00 GMT （GMT格式）

  這個設置意味着截止到2016年12月1日，均可以使用該緩存副本，無需再發出請求。

  Expires這種經過截止日期的方式，存在一個限制：要求客戶端和服務端時鐘嚴格同步，而HTTP 1.1引入的Cache-Control經過指定一個以秒爲單位的時間指定緩存日期，則不存該限制，例如：

Cache-Control: max-age=31536000

  這個設置意味緩存時間爲一年，推薦使用Cache-Control，可是在支持HTTP 1.1的狀況下，另外要注意的一點：Cache-Control和Expire同時存在時，Cache-Control具備更高的優先級。

• 配置或移除ETag

  使用Expire/Cache-Control能夠避免第二次訪問時，使用本地緩存避免重複HTTP請求，提升網站速度。然而，在用戶點擊了瀏覽器刷新或者在expire已過時的狀況下，仍然會向服務端發出HTTP GET請求，而此時若是該文件並無發生變化，服務端不會返回整個文件而是會返回304 Not Modified狀態碼。

  服務端判斷該文件是否發生變化的依據有兩個：Last-Modified（最新修改日期）和ETag（實體標籤）;

  ETag（Entity Tags）是在HTTP 1.1引入的，與Last-Modified同時存在時要有更高的優先級。服務端經過對比客戶端發來的ETag（If-None-Match）和當前ETag，若相同返回304 Not Modifed，不然返回整個文件以及200 OK。

  ETag存在一個問題：當瀏覽器向一個服務器發送GET請求原始組件，以後又向另外一臺服務器請求該組件時，ETag是不匹配的，固然，若是你的網站寄宿在一臺服務器上不存在這個問題，而如今不少網站使用多臺服務器，ETag的存在就大大下降驗證有效性的成功率。

  存在這個問題是時的解決辦法是對ETag進行配置，移除服務器innode值只保留修改時間戳和大小做爲ETag值，或者直接移除ETag，使用Last-Modified來驗證文件有效性。

4 壓縮組件（減少HTTP請求大小）

  經過對HTTP傳輸的文件進行壓縮減少HTTP請求的大小，提升請求速度，GZIP是目前最經常使用也是最有效的壓縮方式。

  然而，並不是全部的資源文件都須要壓縮，壓縮的成本包括服務端須要花費CPU週期進行壓縮，而客戶端也須要對壓縮文件進行解壓縮，必須結合本身網站進行權衡。如今絕大多數網站都對其HTML文檔進行壓縮，部分網站選擇對js、css進行壓縮，幾乎沒有網站對圖片、PDF等文件進行GZIP壓縮，緣由在於這些文件是已經被壓縮過的，採用HTTP壓縮已經被過壓縮的東西並不能使它更小。事實上，添加標頭，壓縮字典，並校驗響應體實際上使它變得更大，並且還浪費了CPU。

  如何對網站開啓GZIP，須要在所使用的web服務器（IIS、Nginx、Apache等）中進行設置。

5 CSS文件放在首部

  將CSS文件放在首部和放在尾部，並不影響HTTP請求，所以從請求時間上來說是一致的，然而從用戶體驗的角度，將CSS文件放在首部，會得到更好的用戶體驗。

  緣由在於瀏覽器是從上到下依次解析html文檔，將CSS文件置於頭部，頁面會首先對CSS文件發出請求，隨後加載DOM樹並對其進行渲染，頁面會逐步呈如今用戶面前。

  而與之相反，若是將CSS文件放置在尾部，頁面加載完整DOM以後請求CSS文件，而後對整個DOM樹渲染並呈現給用戶，從用戶的角度，在css文件沒有請求完成以前，整個頁面是出於白屏狀態的，白屏是瀏覽器的一種行爲，David Hyatt對其的解釋是這樣的

在樣式樹沒有徹底加載以前，渲染dom樹就是一種浪費，由於在樣式樹加載完成以後會再次渲染，出現FOUC(無樣式內容閃爍)問題。

  另外要注意的一點，使用link而不是@import引入css樣式表，使用@import引入的樣式即便寫在首部，也會在文檔最後加載。

6 JS文件放在尾部

  HTTP請求是並行的，不一樣瀏覽器並行下載的數目也不同（二、四、或者8個），並行下載提升了HTTP請求的速度。而將JS文件放在首部，不只會阻塞後面文件的下載並且會阻塞頁面的渲染。

  爲何會這樣呢？緣由有兩個：

• JS文件中可能存在document.write修改頁面的內容，所以頁面會在腳本執行完成以後纔可以使渲染。
• 不一樣JS文件無論大小如何，可能存在依賴關係，所以必須按照順序進行執行，所以在加載腳本的時候並行下載是禁止的。

  因此，最好的方式是講js文件放置在尾部，等頁面全部可視化組件加載完成以後再進行請求，提升用戶體驗。

博文做者：vicfeel 博文出處：http://www.cnblogs.com/vicfeel 本文版權歸做者和博客園共有，歡迎轉載，但須保留此段聲明，並給出原文連接，謝謝合做！ 若是閱讀了本文章，以爲有幫助，您能夠爲個人博文點擊「推薦一下」！