摘要：規(guī)則使用內(nèi)容發(fā)布網(wǎng)絡(luò)用戶同服務(wù)器的距離會(huì)對頁面響應(yīng)時(shí)間產(chǎn)生影響。這不僅能達(dá)到響應(yīng)時(shí)間大幅減少的目的，還很容易實(shí)現(xiàn)。提供動(dòng)態(tài)頁面會(huì)引入特殊的存儲(chǔ)要求數(shù)據(jù)庫連接狀態(tài)管理驗(yàn)證硬件和優(yōu)化等，這些復(fù)雜性超過了的范圍。

鏈接參考： https://developer.yahoo.com/performance/rules.html

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

  
規(guī)則1——減少HTTP請求（Minimize HTTP Requests）

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

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

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

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

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

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

    用戶同Web服務(wù)器的距離會(huì)對頁面響應(yīng)時(shí)間產(chǎn)生影響。網(wǎng)站最初通常將其所有服務(wù)器放在同一個(gè)地方，當(dāng)用戶群增加時(shí)，公司必須面對服務(wù)器放置地點(diǎn)不再合適的事實(shí)。因此，有必要在多個(gè)地理位置不同的服務(wù)器上部署內(nèi)容。

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

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

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

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

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

  
規(guī)則3——添加Expires頭（Add an Expires or a Cache-Control Header）

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

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

Expires: Thu, 15 Apr 2010 20:00:00 GMT

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

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

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

  
規(guī)則4——壓縮組件（Gzip Components)

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


Accept-Encoding: gzip, deflate

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


Content-Encoding: gzip

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

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

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


Vary: Accept-Encoding

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

如果網(wǎng)站的用戶很少，并且他們處于一個(gè)小圈子中，邊緣情形瀏覽器不需要太多關(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)瀏覽器逐步加載頁面時(shí)，頁頭、導(dǎo)航欄、頂端logo等所有這些都會(huì)等待頁面的用戶提供視覺反饋，這改善了用戶體驗(yàn)。將樣式表放在底部，為避免當(dāng)樣式變化時(shí)重繪頁面中的元素，瀏覽器會(huì)阻塞內(nèi)容逐步呈現(xiàn)。

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

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

  
規(guī)則7——避免CSS表達(dá)式(Avoid CSS Expressions)

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

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

  
規(guī)則8——使用外部JavaScript和CSS（Make JavaScript and CSS External）

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

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

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

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

  
規(guī)則9——減少DNS查找（Reduce DNS Lookups）

DNS對于網(wǎng)站來說會(huì)帶來開銷。通常瀏覽器查找一個(gè)給定主機(jī)名的IP要花費(fèi)20～120毫秒的時(shí)間。在DNS查找完成之前，瀏覽器不能從此主機(jī)下載任何東西。

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

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

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

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

混淆是可以應(yīng)用在源代碼上的另一種優(yōu)化方式。相比較于精簡，混淆更加復(fù)雜，因此更容易產(chǎn)生bug。混淆可以更大程度上壓縮源代碼，但是也存在著一定的風(fēng)險(xiǎn)。

除了外部JavaScript外，內(nèi)聯(lián)在

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




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

  
規(guī)則13——配置Etag（Configure ETags）

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


HTTP/1.1 200 OK


Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT


ETag: “10c24bc-4ab-457e1c1f”


Content-Length: 12195

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

GET /i/yahoo.gif HTTP/1.1


Host: us.yimg.com


f-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT


If-None-Match: “10c24bc-4ab-457e1c1f”


HTTP/1.1 304 Not Modified

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

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

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

  
規(guī)則14——使Ajax可緩存（Make Ajax Cacheable）

Ajax的一個(gè)最重要的優(yōu)點(diǎn)就是向用戶提供即時(shí)反饋，因?yàn)樗惒降膹暮笈_Web服務(wù)器請求信息。但是，使用Ajax并不保證用戶不會(huì)等到異步的JavaScript和XML返回響應(yīng)。在很多應(yīng)用程序中，用戶是否需要等待取決于如何使用Ajax。用戶是否需要等待的關(guān)鍵因素在于Ajax請求是主動(dòng)的還是被動(dòng)的。主動(dòng)請求是基于用戶的當(dāng)前操作而發(fā)起的，被動(dòng)請求則是為了將來使用而預(yù)先發(fā)起的。我們需要注意的是，“異步”并沒有暗示“實(shí)時(shí)”。

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