關于yahoo軍規的詳細介紹

1.盡量減少HTTP請求數

分類: 內容

80%的終端用戶響應時間都花在了前端上，其中大部分時間都在下載頁面上的各種組件：圖片，樣式表，腳本，Flash等等。減少組件數必然能夠減少頁面提交的HTTP請求數。這是讓頁面更快的關鍵。

減少頁面組件數的一種方式是簡化頁面設計。但有沒有一種方法可以在構建復雜的頁面同時加快響應時間呢？嗯，確實有魚和熊掌兼得的辦法。

合并文件是通過把所有腳本放在一個文件中的方式來減少請求數的，當然，也可以合并所有的CSS。如果各個頁面的腳本和樣式不一樣的話，合并文件就是一項比較麻煩的工作了，但把這個作為站點發布過程的一部分確實可以提高響應時間。

CSS Sprites 是減少圖片請求數量的首選方式。把背景圖片都整合到一張圖片中，然后用CSS的 background-image 和 background-position 屬性來定位要顯示的部分。

圖像映射 可以把多張圖片合并成單張圖片，總大小是一樣的，但減少了請求數并加速了頁面加載。圖片地圖只有在圖像在頁面中連續的時候才有用，比如導航條。給image map設置坐標的過程既無聊又容易出錯，用image map來做導航也不容易，所以不推薦用這種方式。

行內圖片（Base64編碼）用 data: URL模式 來把圖片嵌入頁面。這樣會增加HTML文件的大小，把行內圖片放在（緩存的）樣式表中是個好辦法，而且成功避免了頁面變“重”。但目前主流瀏覽器并不能很好地支持行內圖片。

減少頁面的HTTP請求數是個起點，這是提升站點首次訪問速度的重要指導原則。就像Tenni Theurer的博客 Browser Cache Usage – Exposed! 里寫到的,40%到60%的訪客在訪問你的站點時，緩存都是空的。所以，加快頁面首次訪問速度對提高用戶體驗是極其重要的。

2.使用CDN（Content Delivery Network）

分類: 服務器

用戶與服務器的物理距離對響應時間也有影響。把內容部署在多個地理位置分散的服務器上能讓用戶更快地載入頁面。但具體要怎么做呢？

實現內容在地理位置上分散的第一步是：不要嘗試去重新設計你的web應用程序來適應分布式結構。這取決于應用程序，改變結構可能包括一些讓人望而生畏的任務，比如同步會話狀態和跨服務器復制數據庫事務（翻譯可能不準確）。縮短用戶和內容之間距離的提議可能被推遲，或者根本不可能通過，就是因為這個難題。

記住終端用戶80%到90%的響應時間都花在下載頁面組件上了：圖片，樣式，腳本，Flash等等，這是 業績黃金法則 。最好先分散靜態內容，而不是一開始就重新設計應用程序結構。這不僅能夠大大減少響應時間，還更容易表現出CDN的功勞。

內容分發網絡（CDN）是一組分散在不同地理位置的web服務器，用來給用戶更高效地發送內容。典型地，選擇用來發送內容的服務器是基于網絡距離的衡量標準的。例如：選跳數（hop）最少的或者響應時間最快的服務器。

一些互聯網公司巨頭擁有他們自己的CDN，但用一個CDN服務提供者是比較劃算的，比如 Akamai Technologies ， EdgeCast ，或者 level3 。對剛剛起步的公司和個人網站來說，CDN服務的成本是很高的，但如果你的用戶群卻越來越大，越來越全球化，那么用CDN來換取更快的響應時間還是很有必要的。在Yahoo!，把靜態內容從應用程序的web服務器搬到CDN(包括上面提到的3rd party和Yahoo自己的 CDN )能夠提高終端用戶20%甚至更多的響應時間。換到CDN是一個相當簡單的代碼變更，但這將急劇提升站點的響應速度。

3.添上Expires或者Cache-Control HTTP頭

分類: 服務器

這條規則有兩個方面：

對于靜態組件：通過設置一個遙遠的將來時間作為 Expires 來實現永不失效

多余動態組件：用合適的 Cache-Control HTTP頭來讓瀏覽器進行條件性的請求

網頁設計越來越豐富，這意味著頁面里有更多的腳本，圖片和Flash。站點的新訪客可能還是不得不提交幾個HTTP請求，但通過使用有效期能讓組件變得可緩存，這避免了在接下來的瀏覽過程中不必要的HTTP請求。有效期HTTP頭通常被用在圖片上，但它們應該用在 所有 組件上，包括腳本、樣式和Flash組件。

瀏覽器（和代理）用緩存來減少HTTP請求的數目和大小，讓頁面能夠更快加載。web服務器通過有效期HTTP響應頭來告訴客戶端，頁面的各個組件應該被緩存多久。用一個遙遠的將來時間做有效期，告訴瀏覽器這個響應在2010年4月15日前不會改變。

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

如果你用的是Apache服務器，用ExpiresDefault指令來設置相對于當前日期的有效期。下面的例子設置了從請求時間起10年的有效期：

ExpiresDefault "access plus 10 years"

記住，如果你用一個遙遠的未來時間做有效期，就不得不在組件發生變化后及時修改組件的文件名。在Yahoo!，我們經常把這一步作為構建過程的一部分：把版本號內嵌在組件的文件名里，例如：yahoo_2.0.6.js

用一個遙遠的未來時間做有效期HTTP頭，只有在用戶已經訪問過站點之后才會影響頁面視圖。如果是新訪客或者瀏覽器的緩存被清空時，對HTTP請求的數量并沒有影響。因此這種性能提升取決于已緩存各個組件的用戶訪問站點的頻率。我們 在Yahoo!測量了這個數據 ，發現已緩存各個組件的頁面訪問量（PV）占75%到85%。通過把一個遙遠的未來時間作為有效期HTTP頭，增加了被瀏覽器緩存的組件數量，在后續頁面訪問量中不需要用Internet連接多發送哪怕一個字節。

4.Gzip組件

分類: 服務器

前端工程師可以想辦法明顯地縮短通過網絡傳輸HTTP請求和響應的時間。毫無疑問，終端用戶的帶寬速度，網絡服務商，對等交換點的距離等等，都是開發團隊所無法控制的。但還有別的能夠影響響應時間的因素，壓縮可以通過減少HTTP響應的大小來縮短響應時間。

從HTTP/1.1開始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。

Accept-Encoding: gzip, deflate

如果web服務器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮響應。web服務器通過Content-Encoding相應頭來通知客戶端。

Content-Encoding: gzip

Gzip是目前最常見的高效壓縮方法，由GNU項目開發并被 RFC 1952 標準化。唯一一個你可能會看到的其它壓縮格式是deflate，但它效率不高而且并不常見。

Gzipping一般能夠把響應壓縮到70%左右，目前大約90%的通過瀏覽器的網絡傳輸都支持gzip。如果是Apache服務器，配置gzip的模塊取決于版本：Apache 1.3用 mod_gzip 而Apache 2.x是 mod_deflate 模塊。

瀏覽器和代理的某些因素可能會引起瀏覽器所期望的和它收到的壓縮內容不匹配。幸運的是，隨著老舊瀏覽器的淘汰，這些極少遇到的情況正在逐漸減少，而且Apache模塊可以通過自動添加合適的Vary響應頭來幫你搞定。

服務器會根據文件類型來決定要不要用gzip壓縮，但這非常有限。大多數網站都用gzip壓縮HTML文件，其實壓縮腳本，樣式表也是不錯的選擇，但很多網站卻錯失了這個機會。其實，可以壓縮任何文本內容，包括XML和JSON，而圖片和PDF不用壓縮，因為它們已經被壓縮過了，再用gzip壓縮不僅浪費CPU還可能會越壓越大。

盡可能多地用gzip壓縮能夠給頁面減肥，這也是提升用戶體驗最簡單的方法。

5.把樣式表放在頂部

分類: css

在Yahoo!研究性能的時候，我們發現把樣式表放到文檔的HEAD部分能讓頁面 看起來 加載地更快。這是因為把樣式表放在head里能讓頁面逐步渲染。

關注性能的前端工程師想讓頁面逐步渲染。也就是說，我們想讓瀏覽器盡快顯示已有內容，這在頁面上有一大堆內容或者用戶網速很慢時顯得尤為重要。給用戶顯示反饋（比如進度指標）的重要性已經被廣泛研究過，并且被 記錄 下來了。在我們的例子中，HTML頁面就是進度指標！當瀏覽器逐漸加載頁面頭部，導航條，頂部logo等等內容的時候，這些都被正在等待頁面加載的用戶當作反饋，能夠提高整體用戶體驗。

在很多瀏覽器（包括IE）中，把樣式表放在HTML文檔底部都會阻止頁面逐漸渲染。這些瀏覽器阻塞渲染過程，以避免因為樣式變動而重繪頁面元素，用戶這時就只能盯著空白頁面。

HTML官方文檔 清楚地描述了樣式表應該放在頁面的HEAD里面：”Unlike A, [LINK] may only appear in the HEAD section of a document, although it may appear any number of times.”（不像a標簽，link標簽可能只出現在HEAD部分，雖然它能可以出現任意多次）。空白屏幕或者沒有樣式的falsh內容都是不可取的。理想方案就是遵循HTML官方文檔，把樣式表放在HTML文檔的HEAD部分。

6.把腳本放在底部

分類: javascript

腳本會阻塞并行下載， HTTP/1.1官方文檔 建議瀏覽器每個主機名下并行下載的組件數不要超過兩個，如果圖片來自多個主機名，并行下載的數量就可以超過兩個。如果腳本正在下載，瀏覽器就不開始任何其它下載任務，即使是在不同主機名下的。

有時候，并不容易把腳本移動到底部。舉個例子，如果腳本是用 document.write 插入到頁面內容中的，就沒辦法再往下移了。還可能存在作用域問題，在多數情況下，這些問題都是可以解決的。

一個常見的建議是用推遲（deferred）腳本，有 DEFER 屬性的腳本意味著不能含有document.write，并且提示瀏覽器告訴他們可以繼續渲染。不幸的是，Firefox不支持 DEFER 屬性。在IE中，腳本可能被推遲，但不盡如人意。如果腳本可以推遲，我們就可以把它放到頁面底部，頁面就可以更快地載入。

7.避免使用CSS表達式

分類: css

用CSS表達式動態設置CSS屬性，是一種強大又危險的方式。從IE5開始支持，但 從IE8起就不推薦使用了 。例如，可以用CSS表達式把背景顏色設置成按小時交替的：

上面的代碼中， expression 方法可以接受一個JavaScript表達式。CSS屬性會被設置成表達式的計算結果。 expression 方法會被其它瀏覽器忽略，所以只有想辦法實現跨瀏覽器的與IE一致的用戶體驗才有用。

表達式最大的問題是它們經常被重復計算，比我們想象的次數還要多。不僅僅是頁面渲染和調整大小的時候，在頁面被滾動，甚至用戶在頁面上移動鼠標時都會重新計算表達式。給CSS表達式添加一個計數器就可以追蹤它重新計算的時間和頻率，而在頁面上動動鼠標就可以引發10000多次重新計算。

減少CSS表達式重新計算的一種方式就是用一次性表達式，即在表達式第一次計算后就把樣式屬性設置成一個明確的值，換掉表達式。如果必須要在頁面的整個生命周期中動態設置樣式屬性，可以用事件處理器來代替CSS表達式。如果必須使用CSS表達式，要記得它們可能會被重復計算上千次，從而影響整個頁面的性能。

8.把JavaScript和CSS放到外面

分類: javascript, css

很多性能原則都是關于如何管理外部組件的，然而，在這些顧慮出現之前你應該問一個更基礎的問題：應該把JavaScript和CSS放到外部文件中還是直接寫在頁面里？

實際上，用外部文件可以讓頁面更快，因為JavaScript和CSS文件會被緩存在瀏覽器。HTML文檔中的行內JavaScript和CSS在每次請求該HTML文檔的時候都會重新下載。這樣做減少了所需的HTTP請求數，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS在外部文件中，并且已經被瀏覽器緩存起來了，那么我們就成功地把HTML文檔變小了，而且還沒有增加HTTP請求數。

關鍵因素是，外部文件被緩存的頻率和頁面被請求數量之間的關系。盡管這個因素很難量化，但我們還是可以用各種各樣的指標來衡量。如果用戶的每個會話中都有多次頁面訪問，那么相同的腳本和樣式表就可以被多個頁面復用，緩存的外部文件就會帶來巨大的好處。

很多站點在度量中都處于中等水平，對這些站點來說，一般最好的解決方案就是把JavaScript和CSS部署為外部文件。唯一的例外是主頁上行內方式優先，例如 Yahoo!的首頁 和 My Yahoo! 。在每個會話中訪問量比較少的主頁會發現行內JavaScript和CSS能讓終端用戶的響應時間更快。

對典型的站點來說，首頁是眾多訪問量的開始，有很多技術可以對減少HTTP請求起到杠桿作用，就像用外部文件緩存的好處一樣。這樣的一種技術就是在首頁用行內JavaScript和CSS，但在頁面載入完成之后動態加載外部文件，這樣后續的頁面所需的外部文件就已經被放到瀏覽器的緩存里了。

9.減少DNS查找

分類: 內容

域名系統建立了主機名和IP地址間的映射，就像電話簿上人名和號碼的映射一樣。當你在瀏覽器輸入www.yahoo.com的時候，瀏覽器就會聯系DNS解析器返回服務器的IP地址。DNS是有成本的，它需要20到120毫秒去查找給定主機名的IP地址。在DNS查找完成之前，瀏覽器無法從主機名下載任何東西。

DNS查找被緩存起來更高效，由用戶的ISP（網絡服務提供商）或者本地網絡存在一個特殊的緩存服務器上，但還可以緩存在個人用戶的計算機上。DNS信息被保存在操作系統的DNS cache(微軟Windows上的”DNS客戶端服務”)里。大多數瀏覽器有獨立于操作系統的自己的cache。只要瀏覽器在自己的cache里還保留著這條記錄，它就不會向操作系統查詢DNS。

IE默認緩存DNS查找30分鐘，寫在 DnsCacheTimeout 注冊表設置中。Firefox緩存1分鐘，可以用 network.dnsCacheExpiration 配置項設置。(Fasterfox把緩存時間改成了1小時 P.S. Fasterfox是FF的一個提速插件)

如果客戶端的DNS cache是空的（包括瀏覽器的和操作系統的），DNS查找數等于頁面上不同的主機名數，包括頁面URL，圖片，腳本文件，樣式表，Flash對象等等組件中的主機名，減少不同的主機名就可以減少DNS查找。

減少不同主機名的數量同時也減少了頁面能夠并行下載的組件數量，避免DNS查找削減了響應時間，而減少并行下載數量卻增加了響應時間。我的原則是把組件分散在2到4個主機名下，這是同時減少DNS查找和允許高并發下載的折中方案。

10.壓縮JavaScript和CSS

分類: javascript, css

壓縮具體來說就是從代碼中去除不必要的字符以減少大小，從而提升加載速度。代碼最小化就是去掉所有注釋和不必要的空白字符（空格，換行和tab）。在JavaScript中這樣做能夠提高響應性能，因為要下載的文件變小了。兩個最常用的JavaScript代碼壓縮工具是 JSMin 和 YUI Compressor ，YUI compressor還可以壓縮CSS。

混淆是一種可選的源碼優化措施，要比壓縮更復雜，所以混淆過程也更容易產生bug。在對美國前十的網站調查中，壓縮可以縮小21%，而混淆能縮小25%。雖然混淆的縮小程度更高，但比壓縮風險更大。

除了壓縮外部腳本和樣式，行內的 <script> 和 <style> 塊也可以壓縮。即使啟用了gzip模塊，先進行壓縮也能夠縮小5%或者更多的大小。JavaScript和CSS的用處越來越多，所以壓縮代碼會有不錯的效果。

11.避免重定向

分類: 內容

重定向用301和302狀態碼，下面是一個有301狀態碼的HTTP頭：

HTTP/1.1 301 Moved Permanently

Location:

Content-Type: text/html

瀏覽器會自動跳轉到 Location 域指明的URL。重定向需要的所有信息都在HTTP頭部，而響應體一般是空的。其實額外的HTTP頭，比如 Expires 和 Cache-Control 也表示重定向。除此之外還有別的跳轉方式：refresh元標簽和JavaScript，但如果你必須得做重定向，最好用標準的3xxHTTP狀態碼，主要是為了讓返回按鈕能正常使用。

牢記重定向會拖慢用戶體驗，在用戶和HTML文檔之間插入重定向會延遲頁面上的所有東西，頁面無法渲染，組件也無法開始下載，直到HTML文檔被送達瀏覽器。

有一種常見的極其浪費資源的重定向，而且web開發人員一般都意識不到這一點，就是URL尾部缺少一個斜線的時候。例如，跳轉到 會返回一個重定向到 的301響應（注意添在尾部的斜線）。在Apache中可以用 Alias ， mod_rewrite 或者 DirectorySlash 指令來取消不必要的重定向。

重定向最常見的用途是把舊站點連接到新的站點，還可以連接同一站點的不同部分，針對用戶的不同情況（瀏覽器類型，用戶帳號類型等等）做一些處理。用重定向來連接兩個網站是最簡單的，只需要少量的額外代碼。雖然在這些時候使用重定向減少了開發人員的開發復雜度，但降低了用戶體驗。一種替代方案是用 Alias 和 mod_rewrite ，前提是兩個代碼路徑都在相同的服務器上。如果是因為域名變化而使用了重定向，就可以創建一條CNAME（創建一個指向另一個域名的DNS記錄作為別名）結合 Alias 或者 mod_rewrite 指令。

12.去除重復腳本

分類: javascript

頁面含有重復的腳本文件會影響性能，這可能和你想象的不一樣。在對美國前10大web站點的評審中，發現只有2個站點含有重復腳本。兩個主要原因增加了在單一頁面中出現重復腳本的幾率：團隊大小和腳本數量。在這種情況下，重復腳本會創建不必要的HTTP請求，執行無用的JavaScript代碼，而影響頁面性能。

IE會產生不必要的HTTP請求，而Firefox不會。在IE中，如果一個不可緩存的外部腳本被頁面引入了兩次，它會在頁面加載時產生兩個HTTP請求。即使腳本是可緩存的，在用戶重新加載頁面時也會產生額外的HTTP請求。

除了產生沒有意義的HTTP請求之外，多次對腳本求值也會浪費時間。因為無論腳本是否可緩存，在Firefox和IE中都會執行冗余的JavaScript代碼。

避免不小心把相同腳本引入兩次的一種方法就是在模版系統中實現腳本管理模塊。典型的腳本引入方法就是在HTML頁面中用SCRIPT標簽：

<script type="text/javascript" src="menu_1.0.17.js?1.1.11"></script>

PHP中一個可選方案是創建一個叫 insertScript 的函數：

<?php insertScript("menu.js?1.1.11") ?>

除了防止相同腳本被多次引入，這個函數還可以解決腳本相關的其它問題，比如依賴性檢查和給腳本文件名添加版本號來支持“永久”有效期HTTP頭。

13.配置ETags

分類: 服務器

實體標簽（ETags），是服務器和瀏覽器用來決定瀏覽器緩存中組件與源服務器中的組件是否匹配的一種機制（“實體”也就是組件：圖片，腳本，樣式表等等）。添加ETags可以提供一種實體驗證機制，比最后修改日期更加靈活。一個ETag是一個字符串，作為一個組件某一具體版本的唯一標識符。唯一的格式約束是字符串必須用引號括起來，源服務器用相應頭中的 ETag 來指定組件的ETag：

HTTP/1.1 200 OK

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

ETag: "10c24bc-4ab-457e1c1f"

Content-Length: 12195

然后，如果瀏覽器必須驗證一個組件，它用 If-None-Match 請求頭來把ETag傳回源服務器。如果ETags匹配成功，會返回一個304狀態碼，這樣就減少了12195個字節的響應體。

GET /i/yahoo.gif HTTP/1.1

Host: us.yimg.com

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

If-None-Match: "10c24bc-4ab-457e1c1f"

HTTP/1.1 304 Not Modified

ETags存在的問題是它們是由特定服務器構造的，所以如果瀏覽器從一個服務器獲取最初的組件，然后想驗證另一個服務器上的相同組件，ETags是無法匹配成功的，而用一群服務器處理請求在web站點中又非常普遍。默認情況下，Apache和IIS會在ETag中嵌入數據，以大大降低在多服務器站點上有效性測試成功的幾率。

Apache 1.3和2.x中ETag的格式是 inode-size-timestamp 。就算給定的文件可能在多個服務器的相同目錄下，而且文件大小、訪問權限、時間戳等等全部相同，它的i節點（P.S. inode，UNIX中的索引文件）在不同服務器中也不一樣。

IIS5.0和6.0也都存在類似的問題。IIS中ETags的格式是 Filetimestamp:ChangeNumber ， ChangeNumber 是一個用來追蹤IIS配置變更的計數器。 一個站點在不同的IIS服務器上的 ChangeNumber 是不可能相同的。

最終結果是Apache和IIS為完全相同的組件生成的ETags無法跨瀏覽器匹配，如果ETags不匹配，用戶就無法收到為又小又快的304響應設計的ETags。反而，他們將收到一個攜帶著組件所有數據的200正常響應。如果站點部署在單一服務器上，就根本不存在這個問題。但如果站點部署在多個服務器上，而且打算用Apache或者IIS的默認ETags配置，用戶將看到緩慢的頁面，服務器負載更高，還會消耗更大的帶寬，并且代理也無法有效緩存頁面內容。即使組件有“永久” Expires HTTP頭，用戶點擊重新加載或者刷新的時候，仍然會發出條件GET請求。

如果不想用ETags提供的靈活的驗證模型，最好把所有的Etag全都去掉，可以用基于組件的時間戳的 Last-Modified HTTP頭驗證，而且去掉ETag可以減少HTTP響應頭以及后續請求的大小。 Microsoft Support article 里寫了怎樣移除ETags。在Apache中，可以簡單地通過在Apache配置文件中添上如下代碼來實現：

FileETag none

14.讓Ajax可緩存

分類: 內容

Ajax的一個好處是可以給用戶提供即時反饋，因為它能夠從后臺服務器異步請求信息。然而，用了Ajax就無法保證用戶在等待異步JavaScript和XML響應返回期間不會非常無聊。在很多應用程序中，用戶能夠一直等待取決于如何使用Ajax。例如，在基于web的電子郵件客戶端中，用戶為了尋找符合他們搜索標準的郵件消息，將會保持對Ajax請求返回結果的關注。重要的是，要記得“異步”并不意味著“即時”。

要提高性能，優化這些Ajax響應至關重要。最重要的提高Ajax性能的方法就是讓響應變得可緩存，就像在 添上Expires或者Cache-Control HTTP頭 中討論的一樣。下面適用于Ajax的其它規則：

Gzip組件

減少DNS查找

壓縮JavaScript

避免重定向

配置ETags

我們一起看看例子，一個Web 2.0的電子郵件客戶端用了Ajax來下載用戶的通訊錄，以便實現自動完成功能。如果用戶從上一次使用之后再沒有修改過她的通訊錄，而且Ajax響應是可緩存的，有尚未過期的Expires或者Cache-Control HTTP頭，那么之前的通訊錄就可以從緩存中讀出。必須通知瀏覽器，應該繼續使用之前緩存的通訊錄響應，還是去請求一個新的。可以通過給通訊錄的Ajax URL里添加一個表明用戶通訊錄最后修改時間的時間戳來實現，例如 &t=1190241612 。如果通訊錄從上一次下載之后再沒有被修改過，時間戳不變，通訊錄就將從瀏覽器緩存中直接讀出，從而避免一次額外的HTTP往返消耗。如果用戶已經修改了通訊錄，時間戳也可以確保新的URL不會匹配緩存的響應，瀏覽器將請求新的通訊錄條目。

即使Ajax響應是動態創建的，而且可能只適用于單用戶，它們也可以被緩存，而這樣會讓你的Web 2.0應用更快。

15.盡早清空緩沖區

分類: 服務器

當用戶請求一個頁面時，服務器需要用大約200到500毫秒來組裝HTML頁面，在這期間，瀏覽器閑等著數據到達。PHP中有一個 flush() 函數，允許給瀏覽器發送一部分已經準備完畢的HTML響應，以便瀏覽器可以在后臺準備剩余部分的同時開始獲取組件，好處主要體現在很忙的后臺或者很“輕”的前端頁面上（P.S. 也就是說，響應時耗主要在后臺方面時最能體現優勢）。

比較理想的清空緩沖區的位置是HEAD后面，因為HTML的HEAD部分通常更容易生成，并且允許引入任何CSS和JavaScript文件，這樣就可以讓瀏覽器在后臺還在處理的時候就開始并行獲取組件。

例如：

... <!-- css, js -->
 </head>
 <?php flush(); ?>
 <body>
 ... <!-- content -->

Yahoo!搜索 開創了這項技術，而且真實用戶測試研究也證明了使用這種技術的諸多好處。

16.對Ajax用GET請求

分類: 服務器

Yahoo!郵箱 團隊發現使用 XMLHttpRequest 時，瀏覽器的POST請求是通過一個兩步的過程來實現的：先發送HTTP頭，在發送數據。所以最好用GET請求，它只需要發送一個TCP報文（除非cookie特別多）。IE的URL長度最大值是2K，所以如果要發送的數據超過2K就無法使用GET了。

POST請求的一個有趣的副作用是實際上沒有發送任何數據，就像GET請求一樣。正如 HTTP說明文檔 中描述的，GET請求是用來檢索信息的。所以它的語義只是用GET請求來請求數據，而不是用來發送需要存儲到服務器的數據。

17.延遲加載組件

分類: 內容

可以湊近看看頁面并問自己：什么才是一開始渲染頁面所必須的？其余內容都可以等會兒。

JavaScript是分隔onload事件之前和之后的一個理想選擇。例如，如果有JavaScript代碼和支持拖放以及動畫的庫，這些都可以先等會兒，因為拖放元素是在頁面最初渲染之后的。其它可以延遲加載的部分包括隱藏內容（在某個交互動作之后才出現的內容）和折疊的圖片。

工具可幫你減輕工作量： YUI Image Loader 可以延遲加載折疊的圖片，還有 YUI Get utility 是一種引入JS和CSS的簡單方法。 Yahoo!主頁 就是一個例子，可以打開Firebug的網絡面板仔細看看。

最好讓性能目標符合其它web開發最佳實踐，比如“漸進增強”。如果客戶端支持JavaScript，可以提高用戶體驗，但必須確保頁面在不支持JavaScript時也能正常工作。所以，在確定頁面運行正常之后，可以用一些延遲加載腳本增強它，以支持一些拖放和動畫之類的華麗效果。

18.預加載組件

分類: 內容

預加載可能看起來和延遲加載是相反的，但它其實有不同的目標。通過預加載組件可以充分利用瀏覽器空閑的時間來請求將來會用到的組件（圖片，樣式和腳本）。用戶訪問下一頁的時候，大部分組件都已經在緩存里了，所以在用戶看來頁面會加載得更快。

實際應用中有以下幾種預加載的類型：

無條件 預加載——盡快開始加載，獲取一些額外的組件。google.com就是一個sprite圖片預加載的好例子，這個 var cpro_id = "u6292429";

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com