高性能網站建設指南

規則1——減小HTTP請求

只有10%到20%的最終用戶響應時間花在接收請求的HTML文檔上面。剩下80%到90%的 時間花在爲HTML文檔所引用的全部組件（圖片，腳本，flash，樣式表等）進行的HTTP請求上。所以改善響應的最簡單途徑就是減小組件數量，由此減小HTTP請求的數量。

圖片地圖

使用map標籤進行座標定位，減小圖片數量。導航欄中使用了多個圖片時候可使用。 

缺點不少：手工方式很難完成座標定位，且容易出錯。除了矩形以外也難以定義其餘形狀，經過DHTML定義的圖片IE中還沒法工做。不建議使用。

 

CSS Sprites (雪碧圖/精靈圖)

經過把多個圖片合併到一個圖片，而後利用background-position進行定位，比使用分離圖片快50%。圖片地圖中的圖片必須是連續的，而CSS Sprites則沒有這個限制。也有人認爲合併後的圖片比分離的圖片總和還要大，合併後的圖片包含附加的空白區域。實際是變小的，雪碧圖下降了圖片自身的開銷。（顏色表，格式信息，等等） 

若是頁面中背景，按鈕，導航欄，連接須要使用不少圖片，可使用。優勢——乾淨的標籤，不多的圖片和很短的響應時間。

 

缺點：後期修改麻煩，難以維護，牽一髮動全身，沒有以前改一個圖片就行了容易

 

雪碧圖製做方法:

 

1. 百度搜索CSS Sprites 可找到相應制做軟件軟件下載地址

2. gulp等自動化工具，自動合成

3. ps本身製做

 

內聯圖片

使用 data:URL的模式在WEB頁面中包含圖片，但無需任何額外的HTTP請求。咱們都熟悉http:模式的URL。其餘相似模式包括ftp:,file:和maito:

 

data:url模式

 

在1995年提出來：容許將小數據塊內聯爲當即數，數據就在url自身中。

 

什麼是內聯圖片

 

內聯圖片是一種新型的圖像格式(在我看來是這樣不知道理解對否),官方稱爲：data URI scheme。一般咱們存儲的圖片在網頁中須要寫：

 

<img src="http://blog.xmaoseo.com/images/xmaoseo.jpg"/>

而內聯圖片寫法會是

 

<img src="data:image/png;base64,iVAGRw0KGDCFGNSUhEUgACBBQAVGADCAIATYJ7ljmRGGAAGElEVQQIW2P4DwcMDAxAfBvMAhEQMYgcACEHG8ELxtbPACCCTElFTEVBQmGA"/>

內聯圖片語法

 

<img src="data:image/png;base64,iVBOR....>

1. data - 取得數據的協定名稱

2. image/png - 數據類型名稱

3. base64 - 數據的編碼方法

4. iUANR.... - 編碼後的數據

5. : , ; - data URI scheme 指定的分隔符號

這種圖片格式無需額外的HTTP請求是不錯，可是還有一個重要的一點，瀏覽器不會緩存這種圖像。 data url 節省了HTTP請求,可是若是這個圖像在網頁多個地方顯示會加大網頁的內容，延長下載時間。還有一點 IE8 如下都不支持這種圖像，因此仍是IE6的用戶就比較悲催了。而且超過 100kb 圖像使用base64編碼也會增大圖片大小。致使網頁總體下載量增長。 (BASE64編碼圖片致使網站瀏覽緩慢崩潰http://blog.xmaoseo.com/125.html) 可是不少聰明人作法是把背景平鋪類圖片做爲內聯圖片使用，這樣效果很不錯。也減小了HTTP請求加快了網站速度。那麼你可能會問到如何獲取圖片的base64編碼呢。網絡上有不少免費的base編碼和解碼工具，可是有個最簡單方法就是咱們寫一個PHP文件。使用base64_encode()進行編碼：好比：

 

echo base64_encode(file_get_contents('211-11.JPG'));

如何解決網頁下載延遲問題。最簡單一個方法就是用寫成CSS裏的背景去調用CLASS 類名就能夠了。好比我們用上面的例子：

 

.blogxmao{background:url(data:image/png;base64,iVAGRw0KGDCFGNSUhEUgACBBQAVGADCAIATYJ7ljmRGGAAGElEVQQIW2P4DwcMDAxAfBvMAhEQMYgcACEHG8ELxtbPACCCTElFTEVBQmGA")}

 

<div>..內容...</div><div>..內容...</div>

合併腳本和樣式表

根據模塊化原則， 咱們應該將代碼放到多個小文件中，可是這樣會下降性能，由於每一個文件都會致使一個額外的http請求。理想狀況，一個頁面不該該使用多餘一個的腳本和樣式表。世界前十網站腳本和樣式表通常不超過2個。

使用模塊化工具，好比seajs,requirejs進行優化。否則隨着文件的增多，手動合併將會很麻煩。

 

規則2——使用內容分發網絡 CDN

內容分發網絡（conten delivery network）是一組分佈在多個不一樣地理位置的Web服務器。可使用CDN服務提供商。

 

CDN優勢：

 

縮短相應時間，備份擴展存儲能力和進行緩存，緩和WEB流量峯值壓力(獲取天氣，娛樂體育新聞等等)

CDN缺點：

 

你的響應時間會受到其餘網站——甚至是競爭對手的流量的影響。沒法控制組件服務器所帶來的特殊麻煩。好比，修改HHTP表頭必須由服務提供商來完成。

若是CDN服務性能降低了，你的工做也會受到影響。固然你可使用兩個CDN服務提供商。

 

CDN用於發佈靜態圖片（將全部靜態組件轉移到CDN），圖片，腳本樣式表，Flash，靜態文件更易存儲，有較少的依賴性。

 

規則3——添加Expires頭

Web頁面包含大量組件，首次訪問時間並非惟一須要考慮的，頁面的初訪者會進行不少HTTP請求，可是可使用一個長久的Expires頭，使得這些組件被緩存。

Expires頭

長久的expires常常用於圖片，然而能夠用於全部組件，不少頂級網站並無作到這一點，由於添加長久的ecpires頭會帶來額外的開發成本。

 

Expires:Mon,15 Apr 2025 00:00:00 GMT

 

它會告訴瀏覽器該響應的有效性會持續到2025年。

 

Max-Age 和mod_expires

由於expires使用一個特定的時間，要求客戶端和服務器端時鐘嚴格同步，過時日期須要檢查，還要配置新的日期，因此使用麻煩。HTTP1.1引入了Cache-Control頭來克服它的限制。Cache-Control使用max-age指令來指定組件被緩存多久。以秒爲單位定義了一個更 新窗。

對於不支持HTTP1.1的瀏覽器，你能夠同時指定兩個響應頭——Expires和max-age.若是二者同時出現，後者將會重寫前者。若是你很盡責，你仍然會擔憂Expires過時問題以及時鐘同步問題。

 

幸運的是,mod_expires使你經過ExpirsDefault指令以相對方式設置日期。

 

ExpirsDefault 'access plus 10 years'

時間能夠設置爲年月日時分秒。它同時向響應中發送Expires頭和max-age頭。實際過時日期根據什麼時候獲得請求而變，可是max-age有優先權。時鐘同步問題和固定日期更新不用擔憂了。

 

跨瀏覽器改善緩存最佳方案就是使用 ExpirsDefault設置的Expires.

 

空緩存vs完整緩存

用戶第一次訪問你的網站它不會對HTTP的請求的數量產生任何影響。此時瀏覽器的緩存是空的。性能改進取決因而否有完整緩存。

在那些每日一次一更新的網站，帶有完整緩存的頁面瀏覽百分比不多。

旅遊網站，email網站中每一個用戶會話可能產生屢次頁面瀏覽，百分比就高。

 

只要用戶每月至少訪問一次，或者每次會話產生屢次頁面瀏覽，完整緩存就頗有用，使用長久Expires就頗有必要。

 

不只僅是圖片

腳本，樣式表，flash均可以緩存，可是HTML文檔不該該使用，由於包含動態內容，每次都要更新。

大型網站，圖片，樣式表，腳本大部分都要緩存30天以上。可是常常須要變化的新聞圖片等等，不該該使用。咱們能夠查看Last-Modifed中的值來看改變時間以及頻率。

 

修訂文件名

使用長久的Expires缺點是 ：瀏覽器不會檢查任何更新，直到過了過時日期。即便在服務器上更新了組件，瀏覽器由於緩存也不能得到最新組件。

爲了確保用戶能得到更新過的組件，須要在全部HTML頁面中修改組件的文件名。

 

最有效的解決方案是修改其全部連接，這樣。全新的請求將從原始服務器下載最新的內容。

 

使用php等動態語言生成HTML頁將很簡單，爲全部組件的文件名使用變量，使用這種方法，在頁面中更新文件名只須要簡單地在某個地方修改變量。Yahoo常常將這一步做爲生成過程的一部分——版本號嵌入在組件的文件名中（例如yahoo_2.0.6.js），並且在全局映射中修訂過的文件名會自動更新。嵌入版本號不只能夠改變文件名，還能在調試中更容易找到準確的源代碼文件。

 

規則4——壓縮組件

規則1--3都是限制沒必要要的HTTP請求來減小響應時間，如今咱們經過減小響應大小來減小響應時間。

 

壓縮是如何工做的

用於減少文件體積的文件壓縮已經在email應用和ftp站點中使用了十年，一樣的技術也能夠用於向瀏覽器發佈壓縮的web頁面。

 

從HTTP1.1開始，web客戶端能夠經過請求中的Accept-Encoding頭來表示對文件壓縮的支持。

 

————>

 

Accept-Encoding:gzip

若是web服務器看到請求中有這個頭，就會使用客戶端列出來的方法中的一種來壓縮響應。並經過響應中的Content-Ecoding來通知客戶端。

<————

 

Content-Ecoding:gzip

gzip是目前最有效，最流行的壓縮方法，免費模式，並被標準化爲RFC 1952.（90%使用）

 

壓縮什麼

不少網站會壓縮HTML文檔，壓縮腳本和樣式表也是很是值得的，還包括XML和JSON在內的任何文本響應。圖片和PDF不該該解壓縮，由於已經被壓縮了。再壓縮只會浪費CPU資源，還有可能會增長文件大小。

 

壓縮的成本：服務器會花費額外的CPU週期來完成壓縮，客戶端要對壓縮文件進行解壓縮。要檢測受益是否大於開銷，須要考慮響應的大小，鏈接的帶寬和和客戶端服務器之間的Internet距離。

根據經驗，一般對大於1KB或2KB的文件進行壓縮。mod_gzip_minimum_file_size指令控制着但願壓縮文件的最小值，默認值是500B。

 

美國十大流行網站中9個壓縮了html,七個壓縮了大多數腳本和樣式表，只要五個壓縮了全部腳本和樣式表。這能夠將頁面減小70%。

 

節省

壓縮以後能將響應總體減小60%左右

 

配置

配置gzip時使用的模塊取決於Apache(intert上最流行的web服務器，份額70%以上)的版本。Apache1.3使用mod_gzip,2.3使用mod_deflate.

 

具體配置詳情如何壓縮，壓縮哪些文件，壓縮程度，類型（可以使用正則匹配）可搜索mod_gzip的網站參考。

 

規則5——將樣式表放在頂部

使用link標籤將樣式表放在文檔head中

白屏

將css放在底部的時候（有觀點以爲DHTML特性東西在最後展示，因此會把css放在底部以爲更優化。）實則否則，這樣容易發生白屏和無樣式內容的閃爍。

 

DHTML不是 W3C 標準

DHTML 指動態 HTML（Dynamic HTML）。

DHTML 是一個營銷術語 - 被網景公司（Netscape）和微軟公司用來描述 4.x 代瀏覽器應當支持的新技術。

DHTML 是一種用來建立動態站點的技術組合物。

對大多數人來講，DHTML 意味着 HTML 4.0、樣式表以及 JavaScript 的結合物。

W3C 曾講過：「動態HTML是一個被某些廠商用來描述可以使文檔動態性更強的HTML、樣式表以及腳本的結合物的術語。」

 

好比一些打字機效果文字，閃爍文字，遮罩濾鏡等等。

 

白屏容易產生的地方，特別是在IE中：

 

1. 新窗口中打開時

2. 從新加載時

3. 做爲主頁（打開新的瀏覽器窗口）

無樣式內容的閃爍FOUC

FOUC flash of unstyles content 產生緣由是沒有吧樣式表放在head頂部，或者使用了@import導入（即使放在前面了，樣式表仍是會最後下載）

 

因此避免無樣式內容閃爍最好方法就是使用link標籤將其放在head頂部

 

規則6——將腳本放在底部

腳本放在頂部會阻塞後面內容的呈現和組件的下載。進而產生白屏現象。

放在底部將會產生最小影響和最佳效應。

 

規則7——避免css表達式

css表達式 expression方法被其餘瀏覽器忽略，IE支持，這種方法雖然強大可是很是危險。

表達式求之的頻率遠高於人們的指望，不只在頁面呈現和大小改變時求值，鼠標拖拽，頁面滾動時候都會求值。因此要避開css表達式，用事件處理器來爲特定的事件提供所指望的動態行爲。

 

規則8—— 使用外部的js和css

**內聯VS外置**

單純比較而言，內聯在第一次加載時要快一點，由於內聯只有一個http請求。

可是多方面考慮仍是要用外置。

內聯沒法緩存，外置能夠緩存，並且當你頁面使用了相同的js和css時候，能夠組件重用，緩存優點更明顯。

 

最重要的是，外置能夠下降耦合度，調試更加方便~~~

 

規則9——減小DNS查找

Internet經過IP地址查找服務器，瀏覽器查找一個給定主機名的IP地址要花費20—120毫秒，也是有開銷的，充當這個角色的就是DNS(domain name system)

如何減小DNS查找

使用較少的域名，谷歌只有一個，由於只有兩個組件，能夠一次並行下載完，兩個主機是最好的，平衡並行下載和DNS查詢。

在HTTP請求中使用 Connection:keep-alive 來保持持久鏈接。早期HTTP請求中。每一個請求都要打開一個socket鏈接，由於頁面中不少請求收拾指向同一個服務器，因此這樣效率很低。持久鏈接的引入使得瀏覽器能夠在一個單獨的鏈接上進行多個請求。

 

HTTP1.1中定義的管道能夠在一個單獨的socket上發送多個請求而無需等待響應，並且性能優於持久鏈接。

 

規則10——精簡javascript

精簡

精簡是從代碼中移除沒必要要的字符以減少其大小。進而改善加載時間的實踐。

代碼精簡以後全部的註釋以及沒必要要的空白字符（空格，換行，製表符），能夠減少20%。

 

混淆

混淆是能夠應用在源代碼上的另一種優化方式，和精簡同樣，也會移除註釋和空白，做爲改寫的一部分，函數和變量的名字將被轉換爲更短的字符串。

這樣的代碼更加精煉，可是更難閱讀。一般這樣作是爲了增長對代碼進行反向工程的難度，但對提升性能也有幫助。

 

混淆js的三個缺點

 

1. 缺陷：混淆更加複雜，混淆過程自己頗有可能引入錯誤。

2. 維護： 因爲混淆會改變js符號，所以須要對任何不能改變的符號（例如API函數）進行標記，防止混淆修改他們。

3. 調試：很難閱讀，調試更加困難。

精簡歷來不會帶來問題，可是混淆會帶來不少問題和缺陷。維護龐大的js建議使用精簡而不是混淆。

 

實際通過gzip壓縮以後，精簡和混淆差異很小。

 

精簡css

精簡css帶來的節省一般小於js,由於註釋和空白比較少。最大的潛在節省來自於優化css——合併相同的類，移除不使用的類等。css依賴順序的本質（成爲層疊樣式表的緣由）決定了這是一個複雜的問題。這個領域還須要進一步的研究和工具開發。

 

一般解決方案有使用顏色縮寫，用0代替0px。

 

規則11——避免重定向