規(guī)則1——減少HTTP請求（Minimize HTTP Requests）
    只有10%～20%的最終用戶響應(yīng)時間花在接收請求的HTML文檔上，剩下的80%～90%時間都花在HTML文檔所引用的所有組件（圖片、腳本、樣式表、Flash等）進(jìn)行的HTTP請求上。因此，改善響應(yīng)時間最簡單的辦法就是減少組件數(shù)量并由此減少HTTP請求數(shù)。減少組件數(shù)量通常會和產(chǎn)品設(shè)計的初衷相矛盾，因此，此處給出了一些技術(shù)：

   圖片地圖（Image Maps）聯(lián)合多個圖片到一個單獨的圖片中。下載圖片大小的總和保持不變，但是，通過減少HTTP請求數(shù)的方式加速了頁面。圖片地圖適用于導(dǎo)航欄或其他超鏈接中使用多個圖片的情形。但是，在定義圖片地圖上的區(qū)域坐標(biāo)時，如果采用手工方式很難完成且容易出錯，而且除了矩形外幾乎無法定義其他形狀。

   CSS Sprites使用CSS background-image和background-position屬性將多個圖片聯(lián)合成一個獨立的圖片來顯示。它通過合并圖片減少了HTTP請求，并且比圖片地圖更加靈活，同時也降低了圖片的下載量。如果在頁面中需要為背景、按鈕、導(dǎo)航欄、鏈接等提供大量圖片，CSS Sprites是一種優(yōu)秀的解決方案。

   內(nèi)聯(lián)圖片（Inline images）使用data: URL scheme模式將圖片嵌入到HTML文檔中。通過此模式嵌入圖片，不需要任何額外的HTTP請求開銷。但是，目前的主流瀏覽器（主要是IE）不支持此種方式。

   合并文件（Combined files）通過將所有JavaScript腳本合并到一個文件，所有CSS樣式表合并到另一個文件的方式來減少HTTP請求的數(shù)量。但是簡單的合并通常會遇到模塊化、頁面變化等問題，需要根據(jù)頁面引用腳本和樣式表來具體分析以確定具體的組合方式。

規(guī)則2——使用內(nèi)容發(fā)布網(wǎng)絡(luò)（Use a Content Delivery Network）
    用戶同Web服務(wù)器的距離會對頁面響應(yīng)時間產(chǎn)生影響。網(wǎng)站最初通常將其所有服務(wù)器放在同一個地方，當(dāng)用戶群增加時，公司必須面對服務(wù)器放置地點不再合適的事實。因此，有必要在多個地理位置不同的服務(wù)器上部署內(nèi)容。

   作為實現(xiàn)地理位置分離的第一步，不應(yīng)當(dāng)首先嘗試使用分布式架構(gòu)重新設(shè)計Web應(yīng)用程序。這樣的應(yīng)用程序決定了重新設(shè)計將帶來如同步會話狀態(tài)、在服務(wù)器放置地點間復(fù)制數(shù)據(jù)庫事務(wù)等復(fù)雜問題。重新設(shè)計會推遲甚至根本無法實現(xiàn)縮短用戶和網(wǎng)站內(nèi)容距離的愿望。

   如果應(yīng)用程序Web服務(wù)器里用戶更近，則一個HTTP請求的響應(yīng)時間將被縮短；如果組件Web服務(wù)器離用戶更近，則多個HTTP請求的響應(yīng)時間將縮短。因此，與其重新開始設(shè)計應(yīng)用程序，以便將應(yīng)用程序Web服務(wù)器分散開，不如首先將組件Web服務(wù)器分散開。這不僅能達(dá)到響應(yīng)時間大幅減少的目的，還很容易實現(xiàn)。

   內(nèi)容發(fā)布網(wǎng)絡(luò)（CDN）是一組分布在多個不同地理位置的Web服務(wù)器，用于更加有效的向用戶發(fā)布內(nèi)容。向特定用戶發(fā)布內(nèi)容的服務(wù)器基于對網(wǎng)絡(luò)可用度的測量，例如，CDN可能選擇網(wǎng)絡(luò)階躍數(shù)最小的服務(wù)器，或者具有最短響應(yīng)時間的服務(wù)器。

   除了縮短響應(yīng)時間外，CDN還可以帶來其他優(yōu)勢，包括備份、擴(kuò)展存儲能力和進(jìn)行緩存；同時，CDN還有助于緩和Web流量峰值的壓力，如在獲取天氣或股市新聞、瀏覽體育或娛樂事件時。依賴CDN的一個缺點是網(wǎng)站的響應(yīng)時間會受到其他網(wǎng)站——甚至可能是競爭對手流量的影響；另一個缺點是無法直接控制組件服務(wù)器所帶來的問題。

  CDN用于發(fā)布靜態(tài)內(nèi)容（如圖片、腳本、樣式表、Flash）。提供動態(tài)HTML頁面會引入特殊的存儲要求——數(shù)據(jù)庫連接、狀態(tài)管理、驗證、硬件和OS優(yōu)化等，這些復(fù)雜性超過了CDN的范圍。另一方面，靜態(tài)文件更容易存儲并具有較少的依賴。

規(guī)則3——添加Expires頭（Add an Expires or a Cache-Control Header）
   Web頁面包含大量組件，并且數(shù)量在不斷增長。頁面的初訪者會進(jìn)行很多的HTTP請求，但通過一個長久的Expires頭，可以使這些組件被緩存下來，可以在后續(xù)的頁面瀏覽中避免不必要的HTTP請求。長久的Expires頭最長用于圖片，但應(yīng)該將其用于所有組件上，包括腳本、樣式表和Flash。

Web服務(wù)器使用Expires頭告訴Web客戶端它可以使用一個組件的當(dāng)前副本，知道指定時間為止。HTTP規(guī)范中簡要的稱該頭為“在這一日期/時間之后，響應(yīng)將被認(rèn)為是無效的”。例如：

告訴瀏覽器該響應(yīng)的有效性持續(xù)到2010年4月15日。

因為Expires頭使用一個特定的時間，它要求服務(wù)端和客戶端的時鐘嚴(yán)格同步；另外，過期日期需要經(jīng)常檢查，一旦過期日期到了，需要在服務(wù)器中配置提供一個新的日期。所以，HTTP1.1引入了Cache-Control頭來克服Exipres頭的限制。Cache-Control使用max-age指令指定組件被緩存多久，它以秒為單位定義了一個更新窗。使用帶有max-age的Cache-Control可以消除Expires的限制，但對于不支持HTTP1.1的應(yīng)用，仍希望使用Expires頭。可以同時制定這兩個響應(yīng)頭，如果兩者同時出現(xiàn)時，HTTP規(guī)范規(guī)定max-age指令將重寫Expires頭。

當(dāng)出現(xiàn)了Expires頭時，直到過期時間為止一直會使用緩存的版本，瀏覽器不會檢查任何更新，直到過了過期時間。為了確保用戶能夠獲取組件的最新版本，需要在所有的HTML頁面中修改組件的文件名。Yahoo在此使用了將版本號嵌入在組件的文件名中的方法。

規(guī)則4——壓縮組件（Gzip Components)
壓縮組件通過減少HTTP請求產(chǎn)生的響應(yīng)包的大小，從而降低傳輸時間的方式來提高性能。從HTTP1.1開始，Web客戶端可以通過HTTP請求中的Accept-Encoding頭來標(biāo)識對壓縮的支持：

如果Web服務(wù)器看到請求中的這個頭，就會使用客戶端列出的方法中的一種來壓縮響應(yīng)。Web服務(wù)器通過響應(yīng)中的Content-Encoding頭來通知Web客戶端：


目前許多網(wǎng)站通常會壓縮HTML文檔，腳本和樣式表的壓縮也是值得的（包括XML和JSON在內(nèi)的任何文本響應(yīng)理論上都值得被壓縮）。但是，圖片和PDF文件不應(yīng)該被壓縮，因為它們本來已經(jīng)被壓縮了。

壓縮通常能將響應(yīng)的數(shù)據(jù)量減少近70%，但是壓縮通常情況下會帶來服務(wù)端和客戶端的CPU開銷，要檢測受益是否大于開銷，需要綜合考慮響應(yīng)大小、連接的帶寬和客戶端也服務(wù)端直接的距離等因素。通常需要對大于1KB或2KB的文件進(jìn)行壓縮。

當(dāng)瀏覽器通過代理來發(fā)送請求時，有可能出現(xiàn)瀏覽器期望接受的壓縮后內(nèi)容和實際接收到的不一致的情況。解決這一問題的方法是在Web服務(wù)器的響應(yīng)中添加Vary頭。Web服務(wù)器可以告訴代理根據(jù)一個或多個請求頭來改變緩存的響應(yīng)。由于壓縮的決定是基于Accept-Encoding請求頭的，因此需要在服務(wù)器的Vary響應(yīng)頭中包含Accept-Encoding:

目前大約90%的通過瀏覽器進(jìn)行的Internet通信都需要使用gzip，使得服務(wù)端和客戶端的對等性變得額外重要。無論是客戶端還是服務(wù)端發(fā)送錯誤，都會造成頁面被破壞。避免錯誤的一種方式是采用“瀏覽器白名單”方式，即只為經(jīng)過證實支持壓縮的瀏覽器提供壓縮內(nèi)容，但是當(dāng)代理緩存加進(jìn)來以后，處理邊緣情形瀏覽器將變得更加復(fù)雜。另一種方式是使用Vary: *或Cache-Control: private頭來禁用代理緩存。此種方式會為所有瀏覽器禁用代理緩存，從而增加帶寬開銷。如何平衡壓縮和代理支持需要在加快響應(yīng)時間、減小帶寬開銷和邊緣情形瀏覽器缺陷之間進(jìn)行權(quán)衡：

如果網(wǎng)站的用戶很少，并且他們處于一個小圈子中，邊緣情形瀏覽器不需要太多關(guān)注，可以壓縮內(nèi)容并使用Vary: Accept-Encoding。

如果更注重帶寬開銷，可以和前一種情形一樣，壓縮內(nèi)容并使用Vary: Accept-Encoding。

如果網(wǎng)站擁有大量的、多變的用戶群，能夠應(yīng)付較高的帶寬開銷，并且享有高質(zhì)量的名聲，需要壓縮內(nèi)容并使用Cache-Control: Private。（Google和Yahoo都使用這種方式）

規(guī)則5——將樣式表放在頂部（Put Stylesheets at the Top）
我們都希望頁面能夠逐步加載，也就是說，我們希望瀏覽器能夠盡快顯示內(nèi)容。當(dāng)瀏覽器逐步加載頁面時，頁頭、導(dǎo)航欄、頂端logo等所有這些都會等待頁面的用戶提供視覺反饋，這改善了用戶體驗。將樣式表放在底部，為避免當(dāng)樣式變化時重繪頁面中的元素，瀏覽器會阻塞內(nèi)容逐步呈現(xiàn)。

樣式表在頁面中的位置并不影響下載時間，但是會影響頁面的呈現(xiàn)。根據(jù)HTML規(guī)范“和A不一樣，[LINK]只能出現(xiàn)在文檔的HEAD節(jié)中，但其出現(xiàn)次數(shù)是任意的”。因此，問題的解決方式應(yīng)該是遵循HTML規(guī)范，使用LINK標(biāo)簽將樣式表放在文檔的HEAD中。

規(guī)則6——將腳本放在底部（Put Scripts at the Bottom）
對響應(yīng)時間影響最大的是頁面中的組件數(shù)量，而腳本會阻塞組件的并行下載，帶來性能上的問題。HTTP1.1規(guī)范建議瀏覽器從每個主機名并行下載兩個組件。如果一個Web頁面平均將其組件分別放在兩個主機名下，整體響應(yīng)時間可以減少大約一半。我們可以通過對瀏覽器默認(rèn)設(shè)置的修改來增加每個主機名并行下載組件的數(shù)量，也可以使用CNAME（DNS別名）將組件分別放到多個主機名下。但是，增加并行下載數(shù)量通常會帶來性能上的開銷，過多的并行下載有時反而會降低性能。Yahoo!研究表明，使用兩個主機名比使用1、4或10個主機名能帶來更好的性能。

需要我們注意的是，下載腳本時并行下載實際上是被禁用的，即使此時使用了不同的主機名，瀏覽器也不會啟動其他下載。因此，如果將腳本放在頂部，腳本會阻塞后面內(nèi)容的呈現(xiàn)，也會阻塞后面組件的下載。因此，放置腳本最好的地方是頁面底部，這不會阻止頁面內(nèi)容呈現(xiàn)，而且頁面中的可視組件可以盡早下載。

規(guī)則7——避免CSS表達(dá)式(Avoid CSS Expressions)
CSS表達(dá)式是動態(tài)設(shè)置CSS屬性的一種強大（并且危險）的方式。它從IE5以后的版本被支持，在IE8中已經(jīng)被廢棄。
表達(dá)式的問題在于對其進(jìn)行的求值頻率比人們期望的要高。它們不只在呈現(xiàn)頁面和大小改變時求值，當(dāng)頁面滾動，甚至用戶鼠標(biāo)在頁面上移過時都要進(jìn)行求值。

減少CSS表達(dá)式求值次數(shù)的一種方式是使用一次性表達(dá)式，如果CSS表達(dá)式必須被求值一次，可以在這一次中執(zhí)行重寫它本身。除此之外，還可以使用事件處理器來為特定的事件提供所期望的動態(tài)行為。

規(guī)則8——使用外部JavaScript和CSS（Make JavaScript and CSS External）
在現(xiàn)實環(huán)境中使用外部文件通常會產(chǎn)生較快的頁面，因為JavaScript和CSS有機會被瀏覽器緩存起來。對于內(nèi)聯(lián)的情況，由于HTML文檔通常不會被配置為可以進(jìn)行緩存的，所以每次請求HTML文檔都要下載JavaScript和CSS。所以，如果JavaScript和CSS在外部文件中，瀏覽器可以緩存它們，HTML文檔的大小會被減少而不必增加HTTP請求數(shù)量。

決定是否使用外部文件的關(guān)鍵在于被緩存的外部文件占請求的HTML文檔數(shù)的比重。如果網(wǎng)站用戶在每次會話中進(jìn)行多次頁面訪問，同時頁面重用了多個腳本和樣式表，使用外部文件時很好的選擇。

對于大多數(shù)網(wǎng)站而言，難以精確度量以判斷是否使用內(nèi)聯(lián)或外部文件，此時建議是使用外部文件的方式。對于這個問題的一個例外是網(wǎng)站主頁，由于主頁對于響應(yīng)時間要求更高，因此更加傾向于內(nèi)聯(lián)而不是外部文件。

對于內(nèi)聯(lián)文件而言，由于無法利用瀏覽器緩存，因此給人感覺依然比較低效。我們可以通過加載后下載和動態(tài)內(nèi)聯(lián)的方式來使得網(wǎng)站主頁既可以獲得內(nèi)聯(lián)的優(yōu)勢，同時也能緩存外部文件。

規(guī)則9——減少DNS查找（Reduce DNS Lookups）
DNS對于網(wǎng)站來說會帶來開銷。通常瀏覽器查找一個給定主機名的IP要花費20～120毫秒的時間。在DNS查找完成之前，瀏覽器不能從此主機下載任何東西。

DNS查找可以被緩存起來以提高性能，這種緩存可以發(fā)生在ISP或局域網(wǎng)中的一臺特殊的緩存服務(wù)器上，同時，緩存也會發(fā)生在獨立的用戶機器上。在用戶請求一個主機名后，DNS信息會留在操作系統(tǒng)的DNS緩存中，大多數(shù)瀏覽器也擁有自己的緩存，和操作系統(tǒng)緩存相分離。只要瀏覽器在其緩存中保留了DNS記錄，就不會通過操作系統(tǒng)來請求這個記錄。

當(dāng)客戶端瀏覽器和操作系統(tǒng)中DNS緩存同時為空時，DNS查詢的數(shù)量等于頁面中唯一主機名的數(shù)量，這些主機名包括了頁面的URL、圖片、腳本、樣式表、Flash等。所以，減少唯一主機名數(shù)量，可以減少DNS查詢數(shù)。

減少唯一主機名數(shù)量會潛在的減少頁面中并行下載的數(shù)量。避免DNS查找降低了響應(yīng)時間，但減少并行下載可能會增加響應(yīng)時間。對于這種情形，建議將這些組件放在至少2個，但不要超過4個主機名下。

規(guī)則10——精簡JavaScript和CSS（Minify JavaScript and CSS）
精簡是從代碼中移除不必要的字符以減小其大小，進(jìn)而改善加載時間。在代碼被精簡后，所有注釋以及不必要的空白字符（空格、換行和制表符）都將被移除。對于JavaScript而言，因為需要下載的文件大小減小了，可以改善響應(yīng)時間。

混淆是可以應(yīng)用在源代碼上的另一種優(yōu)化方式。相比較于精簡，混淆更加復(fù)雜，因此更容易產(chǎn)生bug?；煜梢愿蟪潭壬蠅嚎s源代碼，但是也存在著一定的風(fēng)險。

除了外部JavaScript外，內(nèi)聯(lián)在<script>和<style>塊中的源代碼也需要被精簡。即使使用了gzip來壓縮JavaScript和CSS，使用精簡能夠?qū)⒋a大小再減少5%或者更多。

規(guī)則11——避免重定向（Avoid Redirects）
重定向用于將用戶從一個URL路由到另一個URL。重定向有很多種，其中301和302是最常用的兩種。下面是一個301響應(yīng)頭的示例：

瀏覽器會自動將用戶帶到Location字段給出的URL。重定向所必需的所有信息都包含在這個頭中，響應(yīng)體通常是空的。不管叫什么名字，301或者302響應(yīng)在實際中都不會被緩存，除非有附加的頭（如Expires或Cache-Control等）要求它這么做。meta refresh標(biāo)簽和JavaScript也可以用于重定向，但是最好的技術(shù)是使用標(biāo)準(zhǔn)的3xx狀態(tài)碼，以保證后退按鈕能夠正常工作。

需要我們記住的是重定向會使頁面變慢。在用戶和HTML文檔間插入一個重定向后，在此HTML文檔到達(dá)之前頁面上不會描繪任何東西，任何組件也不會被下載。

有一種重定向最為浪費，發(fā)生的也很頻繁，但是Web開發(fā)人員通常都沒有意識到它，它發(fā)生在URL的結(jié)尾必須出現(xiàn)斜線（/）而沒有出現(xiàn)的情形。例如訪問地址http://astrology.yahoo.com/astrology將導(dǎo)致一個301響應(yīng)包含重定向至http://astrology.yahoo.com/astrology/。當(dāng)主機名后缺少結(jié)尾斜線時不會發(fā)生重定向。在Apache中，我們可以通過Alias指令或者mod_rewrite模塊或者DirectorySlash指令來處理缺少結(jié)尾斜線時的重定向問題。

從一個舊的站點鏈接到新的站點是使用重定向的另一種常見場景。其他形式還包括將一個網(wǎng)站的不同部分連接起來，以及基于一些條件（瀏覽器類型、用戶帳戶類型等）來引導(dǎo)用戶。使用重定向來連接兩個網(wǎng)站很簡單而且只需要很少的額外代碼。但是，雖然重定向降低了開發(fā)的復(fù)雜性，也損害了用戶體驗，通?？梢赃M(jìn)行其他的選擇：如果兩個代碼的路徑在同一臺服務(wù)器上，可以使用Alias和mod_rewrite；如果域名由于重定向發(fā)生改變，可以使用一個CNAME（一條DNS記錄，用于創(chuàng)建一個域名指向另一個域名的別名）讓兩個主機名指向相同的服務(wù)器，然后使用Alias和mod_rewrite。

規(guī)則12——移除重復(fù)腳本（Remove Duplicate Scripts）
在一個頁面中兩次保護(hù)同一個JavaScript文件會損傷性能。導(dǎo)致一個腳本重復(fù)的因素主要有兩個——團(tuán)隊大小和腳本數(shù)量。

當(dāng)重復(fù)腳本的現(xiàn)象發(fā)生時，將產(chǎn)生不必要的HTTP請求和浪費執(zhí)行JavaScript的時間。不必要的HTTP請求會發(fā)生在IE中，而不會發(fā)生在Firefox中。在IE中，如果腳本被包含兩次且沒有被緩存，瀏覽器會在頁面加載期間產(chǎn)生兩個HTTP請求；即使腳本可以緩存，當(dāng)用戶重新加載頁面時也會產(chǎn)生額外的HTTP請求。對JavaScript進(jìn)行的多余的執(zhí)行從而浪費時間的現(xiàn)象在IE和Firefox中都存在，與腳本是否被緩存無關(guān)。

避免意外包含同一腳本兩次的一種方法是在你的模塊系統(tǒng)中實現(xiàn)一個腳本管理模塊。包含腳本的典型方式是在HTML頁面中使用SCRIPT標(biāo)簽：

另一種選擇是在PHP中創(chuàng)建一個函數(shù)：

為了防止統(tǒng)一個腳本被重復(fù)添加多次，insertScript函數(shù)需要添加處理腳本的依賴性和版本的功能。

規(guī)則13——配置Etag（Configure ETags）
實體標(biāo)簽（Entity Tag，ETag）是Web服務(wù)器和瀏覽器用于確認(rèn)緩存組件的有效性的一種機制。ETag在HTTP1.1中引入，用于檢測瀏覽器緩存中的組件與原始服務(wù)器上的組件是否匹配。ETag是唯一標(biāo)識了一個組件的一個特定版本字符串。唯一的約束是該字符串必須用引號引起來。原始服務(wù)器使用Etag響應(yīng)頭來指定組件的ETag。

此后，如果瀏覽器必須驗證一個組件，它會使用If-None-Match頭將ETag傳回原始服務(wù)器。如果ETag是匹配的，就會返回304狀態(tài)碼，在此例中使響應(yīng)減少12195字節(jié)。


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

Apache1.3和2.x的ETag格式是inode-size-timestamp。文件系統(tǒng)使用inode來存儲諸如文件類型、所有者、組和訪問模式等信息。盡管在多臺服務(wù)器上一個給定的文件可能位于相同的目錄、具有相同的文件大小、權(quán)限、時間戳等，從一臺服務(wù)器到另一臺服務(wù)器，器inode仍然是不同的。
IIS5.0和6.0在ETag上有著類似的問題。IIS上ETag的格式是Filetimestamp:ChangeNumber。ChangeNumber適用于跟蹤IIS配置變化的計數(shù)器。對于一個網(wǎng)站背后的所有IIS服務(wù)器來說，ChangeNumber不大可能相同。
最

終的結(jié)果是，對于完全相同的組件，從一臺服務(wù)器到另一臺，Apache和IIS產(chǎn)生的ETag是不會匹配的。如果ETag不匹配，用戶就不會按照ETag的設(shè)計計劃那樣接收到更小更快的304響應(yīng)；相反，它們會收到普通的200響應(yīng)以及組件的所有數(shù)據(jù)。如果只在一臺服務(wù)器上部署網(wǎng)站，這通常不會產(chǎn)生問題；但如果使用了服務(wù)器集群，同時使用Apache或者IIS進(jìn)行默認(rèn)的ETag配置，用戶響應(yīng)將變慢，服務(wù)器負(fù)載將變高，將消耗更多的帶寬，同時代理緩存的效率也會下降。即使組件具有長久的Expires頭，一旦用戶單擊了Reload或Refresh按鈕，依然會產(chǎn)生條件GET請求。
如果組件必須通過最新修改日期之外的一些東西來進(jìn)行驗證，則ETag是一種強大的方法；如果無須自定義ETag，則最好將其移除。Last-Modified頭基于組件的時間戳進(jìn)行驗證，可以提供完全等價的信息，而且移除ETag可以減少響應(yīng)和后續(xù)請求的HTTP頭的大小。在Apache中，只要向Apache配置文件中簡單地添加下面一行配置就能移除ETag：
FileETag none

規(guī)則14——使Ajax可緩存（Make Ajax Cacheable）
Ajax的一個最重要的優(yōu)點就是向用戶提供即時反饋，因為它異步的從后臺Web服務(wù)器請求信息。但是，使用Ajax并不保證用戶不會等到異步的JavaScript和XML返回響應(yīng)。在很多應(yīng)用程序中，用戶是否需要等待取決于如何使用Ajax。用戶是否需要等待的關(guān)鍵因素在于Ajax請求是主動的還是被動的。主動請求是基于用戶的當(dāng)前操作而發(fā)起的，被動請求則是為了將來使用而預(yù)先發(fā)起的。我們需要注意的是，“異步”并沒有暗示“實時”。

為了提升性能，最重要的是優(yōu)化Ajax響應(yīng)。而改善這些主動Ajax請求的最重要的方式就是使響應(yīng)可緩存。如同在“添加Expires頭”中討論的，一些其他規(guī)則也適用于Ajax，包括：壓縮組件、減少DNS查找、精簡JavaScript、避免重定向、配置Etag。

PS：具體的關(guān)于優(yōu)化的知識點或問題

1. 為什么網(wǎng)頁設(shè)置緩存后仍然有請求（304響應(yīng)）？

瀏覽器刷新是conditional request，所以如果通過刷新來看緩存是否有效肯定是304。可以試試輸入網(wǎng)址按回車或者回退鍵來看效果。另外由于HTML文檔很少設(shè)置完全緩存（一般要和服務(wù)器驗證），可以看靜態(tài)組件的緩存效果（200 ok (from cache)）。

2. expirationTime = responseTime + freshnessLifetime - currentAge

freshnessLifetime具體怎么算可以參考https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching_FAQ。

3. Flash of unstyled content（無樣式內(nèi)容閃爍）

Flash of unstyled content（FOUC）就是在加載外部樣式表之前，瀏覽器按默認(rèn)樣式顯示了內(nèi)容，這是因為瀏覽器在所有資源都下載好前就開始渲染頁面了。一旦外部樣式被加載，瀏覽器就會修正樣式，但這種修正可能是可見的，也就是FOUC。

怎么避免？在<head>中通過<link>引入樣式，避免使用@import。