只有10-20%的最終用戶響應(yīng)時間花在了下載HTML文檔上。其余的80-90%時間花在了下載頁面中的所有組件上。

HTTP概述

1. 壓縮
2. 條件GET請求
3. Expire
4. Keep-Alive

規(guī)則1、減少HTTP請求

1. 圖片地圖：將多個圖片合并成一個，而后通過css定位顯示不同的位置
2. CSS Sprites:同上
3. 內(nèi)聯(lián)圖片
4. 合并腳本和樣式表

規(guī)則2、使用內(nèi)容發(fā)布網(wǎng)絡(luò)（CDN，Content Delivery Network）

規(guī)則3、添加Expires頭

1. Expires頭：在這一日期/時間之后，響應(yīng)將被認(rèn)為是無效的
2. Max-Age: 設(shè)置相對有效時間Cache-Control:max-age=100
3. 空緩存VS完整緩存：盡可能將頁面內(nèi)容放入大緩存中
4. 不僅僅是圖片：圖片應(yīng)該使用緩存，但這一優(yōu)質(zhì)實踐不應(yīng)該僅限于圖片
5. 修訂文件名：為能夠獲取最新的文件，最有效的解決方案是修改其所有鏈接，這樣，全新的請求將從原始服務(wù)器下載最新的內(nèi)容。

規(guī)則4、壓縮組件

1. gzip:Accept-Encoding:gzip,deflate。gzip是目前最流行和最有效的壓縮方法，是最理想的壓縮方法
2. 壓縮內(nèi)容：壓縮腳本和樣式表是非常值得的，同時還有XML和JSON在內(nèi)的文本。圖片和PDF不應(yīng)該壓縮，因為它們本來就已經(jīng)被壓縮了。
3. 節(jié)省率：壓縮通常能將響應(yīng)的數(shù)據(jù)量減少將近70%
4. gzip配置：不同的web服務(wù)器有不同的gzip配置方式，但大多支持gzip
5. 代理緩存：Web服務(wù)器基于Accept-Encoding來檢測是否對響應(yīng)進(jìn)行壓縮。不管是否壓縮過，瀏覽器都會基于響應(yīng)中的其他HTTP頭如Expires和Cache-Control來緩存響應(yīng)。由于壓縮的決定是基于Accept-Encoding請求頭的，因此需要在服務(wù)器的Vary響應(yīng)頭中包含Accept-Encoding。
6. 邊緣情形：服務(wù)器和客戶端的壓縮對等性看似簡單，但必須正確才行。無論是客戶端還是服務(wù)器發(fā)生錯誤（發(fā)送壓縮內(nèi)容到不支持它的客戶端、忘記將壓縮內(nèi)容聲明為已經(jīng)進(jìn)行了gzip編碼等），頁面都會被破壞。錯誤并不會經(jīng)常發(fā)生，但它們是必須考慮的邊緣情形（Edge Case）。這種情況雖然可以通過瀏覽器白名單方式解決，但設(shè)置瀏覽器白名單的指令過于復(fù)雜，無法使用HTTP頭進(jìn)行編碼。優(yōu)質(zhì)做法是將User-Agent作為代理的另外一種判斷標(biāo)準(zhǔn)添加到Vary頭中Vary:Accept-Encoding,User-Agent

規(guī)則5、將樣式表放在頂部

      規(guī)則5對于加載頁面所需的實際時間沒有太多影響，它影響更多的是瀏覽器對這些組件順序的反應(yīng)。為避免當(dāng)樣式變化時重繪頁面中的元素，瀏覽器會等待位于底部的樣式表加載完成后才會呈現(xiàn)，這時瀏覽器會延遲任何可視化組件。實際上，用戶感覺緩慢的頁面反而是可視化組建加載得更快的頁面。使用LINK標(biāo)簽將樣式表放在文檔的HEAD中可以解決該問題。

     在使用樣式表時，頁面逐步呈現(xiàn)會被阻止，直到所有的樣式表下載完成。將樣式表移到文檔head中，這樣就能首先下載它們而不會阻止頁面呈現(xiàn)。

規(guī)則6、將腳本放在底部

1. 并行下載 對響應(yīng)時間影響的是頁面中組件的數(shù)量，如果一個Web頁面平均地將其組件分別放在兩個主機(jī)名下，整體響應(yīng)時間將可以減少大約一半。但并行下載數(shù)量并不是越多越快，因為增加并行下載數(shù)量是有開銷的，其優(yōu)劣取決于帶寬和cpu速度。
2. 腳本阻塞下載 并行下載組件的優(yōu)點是很明顯的，然而，在下載腳本時并行下載實際上被禁用的。即使使用了不同的主機(jī)名，瀏覽器也不會啟動其他的下載。其中一個原因是，腳本可能使用document.write來修改頁面內(nèi)容，因此瀏覽器會等待，已確保頁面能夠恰當(dāng)?shù)夭季?。另一個原因是為了保證腳本能夠按照正確的順序執(zhí)行。

     在使用腳本時，對于所有位于腳本以下的內(nèi)容，逐步呈現(xiàn)都被阻塞了。將腳本放在頁面越靠下的地方，意味著越多的內(nèi)容能逐步地呈現(xiàn)。

規(guī)則7、避免css表達(dá)式

規(guī)則8、使用外部JavaScript和Css

1. 純碎而言，內(nèi)聯(lián)快一些
2. 頁面查看 每個用戶產(chǎn)生的頁面查看越少，內(nèi)聯(lián)JavaScript和Css的論據(jù)越強(qiáng)勢。另一方面，如果普通用戶能夠產(chǎn)生很多的頁面查看，瀏覽器很可能將（具有長久的Expires頭的）外部文件放在其緩存中。
3. 組件重用  如果你的網(wǎng)站中的每一個頁面都使用了相同的JavaScript和Css，使用外部文件可以提高這些組件的重用率。在這種情況下使用外部文件更加具有優(yōu)勢，因為當(dāng)用戶在頁面間瀏覽時，JavaScript和Css組件已經(jīng)位于瀏覽器的緩存中了。
4. 動態(tài)內(nèi)聯(lián)  如果主頁服務(wù)器知道一個組件是否在瀏覽器的緩存中，它可以在內(nèi)聯(lián)和使用外部文件之間做出優(yōu)質(zhì)選擇。盡管服務(wù)器不能查看瀏覽器緩存中有些什么，但可以用cookies做指示器。如果cookie不存在，就內(nèi)聯(lián)了JavaScript和Css。如果cookie出現(xiàn)了，則有可能外部組件位于瀏覽器的緩存中，并使用了外部文件。

規(guī)則9、減少DNS查找

     Internet是通過IP地址來查找服務(wù)器的。由于IP地址很難記憶，通常使用包含主機(jī)名的URL來取代它，但當(dāng)瀏覽器發(fā)送其請求時，IP地址仍然是必需的。這就是Domain Name System(DNS) 所處的角色。DNS也有開銷，通常瀏覽器查找一個給定的主機(jī)名的IP地址要花費20-120毫秒。響應(yīng)時間依賴于DNS解析器（通常由你的ISP提供）、它所承擔(dān)的請求壓力、你與它之間的距離和你的帶寬速度。

1. DNS緩存  DNS查找可以被緩存起來提高性能。這種緩存可以發(fā)生在由你的ISP或局域網(wǎng)中的一臺特殊的緩存服務(wù)器上，但這里探討的是發(fā)生在獨立用戶的計算機(jī)上的DNS緩存。在用戶請求了一個主機(jī)名之后，DNS信息會留在操作系統(tǒng)的DNS緩存中，之后對于該主機(jī)名的請求將無需進(jìn)行過多的DNS查找，至少短時間內(nèi)不需要?！?
2. 影響DNS緩存的因素 首先，服務(wù)器可以表明記錄可以被緩存多久。查找返回的DNS記錄包含了一個存活時間（Time-to-live,TTL）值。該值告訴客戶端可以對該記錄緩存多久，盡管操作系統(tǒng)緩存會考慮TTL值，但瀏覽器通常忽略該值，并設(shè)置它自己的時間限制。另外瀏覽器對緩存的DNS記錄的數(shù)量也有限制，TTL設(shè)置值通常是1天。
3. 減少DNS查找  當(dāng)客戶端的DNS緩存為空（瀏覽器和操作系統(tǒng)都是）時，DNS查找的數(shù)量與Web頁面中唯一主機(jī)名的數(shù)量相等。這包括頁面URL、圖片、腳本文件、樣式表、Flash對象等的主機(jī)名。減少唯一主機(jī)名的數(shù)量就可以就可以減少DNS查找的數(shù)量。
4. 通過使用Keep-Alive和較少的域名來減少DNS查找

規(guī)則10、精簡JavaScript

      JavaScript作為一門解釋型語言，是構(gòu)建Web頁面的首選。當(dāng)以快速原型為基準(zhǔn)開發(fā)用戶界面時，解釋語言要優(yōu)于其他語言。

1. 精簡 是從代碼中移除不必要的字符以減少其大小，進(jìn)而改善加載時間的實踐。在代碼被精簡后，所有的注釋以及不必要的空白字符（空格、換行和制表符）都將被移除。對于JavaScript而言，這可以改善響應(yīng)時間效率，因為需要下載的文件大小減少了。精簡JavaScript最流行的工具是JSMin。
2. 混淆  是可以應(yīng)用在源代碼上的另外一種優(yōu)化方式。和精簡一樣，它也會移除注釋和空白，同時它還會改寫代碼。作為改寫的一部分，函數(shù)和變量的名字將被轉(zhuǎn)換為更短的字符串，這時的代碼更加精煉。但是會帶來三個弊端：可能引入錯誤、增加調(diào)試難度、需要對JavaScript關(guān)鍵字標(biāo)記
3. 內(nèi)聯(lián)腳本  內(nèi)聯(lián)的JavaScript塊也應(yīng)該精簡

規(guī)則11、避免重定向

     重定向用于將用戶從一個URL重新路由到另一個URL，種類有很多，常用的是301和302。它是損傷性能的，可以采用Alias、mod_rewirte、DirectorySlash和直接連接代碼來避免重定向。

規(guī)則12、移除重復(fù)腳本

1. 重復(fù)腳本--確有其事 開發(fā)一個網(wǎng)站需要極大數(shù)量的資源，除了核心團(tuán)隊要構(gòu)建網(wǎng)站外，其他團(tuán)隊也會向頁面貢獻(xiàn)HTML代碼。由于來自不同團(tuán)隊的很多人都要向頁面中添加HTML，很容易想到相同的腳本可能會被添加多次
2. 重復(fù)腳本傷害性能 引起不必要的HTTP請求和執(zhí)行JavaScript所消耗的時間

規(guī)則13、配置ETag

    實體標(biāo)簽（Entity Tag，ETag）是Web服務(wù)器和瀏覽器用于確認(rèn)緩存組件的有效性的一種機(jī)制。減少呈現(xiàn)頁面時所必需的HTTP請求的數(shù)量是加速用戶體驗的優(yōu)質(zhì)方式?？梢酝ㄟ^化瀏覽器緩存組件的能力來實現(xiàn)這一目標(biāo)，但當(dāng)網(wǎng)站被宿主在多于一臺服務(wù)器上時，ETag頭可能會阻礙緩存。

    ETag帶來的問題 ETag的問題在于，通常使用組件的某些屬性來構(gòu)造它，這些屬性對于特定的、寄宿了網(wǎng)站的服務(wù)器來說是唯一的。當(dāng)瀏覽器從一臺服務(wù)器上獲取了原始組件，之后又向另外一臺不同的服務(wù)器發(fā)起條件GET請求時，ETag是不會匹配的----而對于使用服務(wù)器集群來處理請求的網(wǎng)站來說，這是很常見的一種情況。默認(rèn)情況下，對于擁有多臺服務(wù)器的網(wǎng)站，Apache和IIS向ETag中嵌入的數(shù)據(jù)都會大大地降低有效性驗證的成功率。

   解決該問題的兩種方式：選擇ETag的配置方式或者直接移除ETag

規(guī)則14、使Ajax可緩存

    Ajax表示異步JavaScript和XML（Asynchronous JavaScript and XML），盡管今天除了XML有很多其他選擇，最著名的是JSON。Ajax的目的是為了突破Web本質(zhì)的開始--停止交互方式。向用戶顯示一個白屏然后重繪整個頁面不是一種后的用戶體驗。而Ajax在UI和Web服務(wù)器之間插入了一層。這個Ajax層位于客戶端，與Web服務(wù)器進(jìn)行交互以獲取請求的信息，并與表現(xiàn)層交互，僅更新哪些必要的組件。它將Web體驗從“瀏覽頁面”轉(zhuǎn)變?yōu)椤芭c應(yīng)用程序進(jìn)行交互”。

  Ajax的一個明顯優(yōu)點是向用戶提供了及時反饋，因為它異步地從后端Web服務(wù)器請求信息。但Ajax并不保證用戶就不會一邊玩弄自己的手指一邊等著“異步JavaScript和XML”返回響應(yīng)，記住“異步”并沒有暗示“即時”，這一點很重要。用戶是否需要等待的關(guān)鍵因素在于Ajax請求是被動的還是主動的。被動請求是為了將來使用而預(yù)先發(fā)起的。主動請求是基于用戶當(dāng)前的操作而發(fā)起的。

    改善Ajax請求的最重要的方式就是使響應(yīng)可緩存，前面第4、9、10、11、13原則也適用于此。

    確保Ajax請求遵守性能指導(dǎo)，尤其應(yīng)具有長久的Expires頭。