Yahoo!的Exceptional Performance團隊爲改善Web性能帶來最佳實踐。他們爲此進行了一系列的實驗、開發了各種工具、寫了大量的文章和博客並在各種會議上參與探討。最佳實踐的核心就是旨在提高網站性能。
Excetional Performance團隊總結出了一系列可以提高網站速度的方法。可以分爲7大類34條。包括內容、服務器、cookie、CSS、JavaScript、圖片、移動應用等七部分。
其中內容部分一共十條建議：
一、內容部分
儘量減少HTTP請求
減少DNS查找
避免跳轉
緩存Ajxa
推遲加載
提前加載
減少DOM元素數量
用域名劃分頁面內容
減小iframe的大小
避免404錯誤
1、儘量減少HTTP請求次數
終端用戶響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。通過減少頁面中的元素可以減少HTTP請求的次數。這是提高網頁速度的關鍵步驟。
減少頁面組件的方法其實就是簡化頁面設計。那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這裏有幾條減少HTTP請求次數同時又可能保持頁面內容豐富的技術。
合併文件是通過把所有的腳本放到一個文件中來減少HTTP請求的方法，如可以簡單地把所有的CSS文件都放入一個樣式表中。當腳本或者樣式表在不同頁面中使用時需要做不同的修改，這可能會相對麻煩點，但即便如此也要把這個方法作爲改善頁面性能的重要一步。
CSS Sprites是減少圖像請求的有效方法。把所有的背景圖像都放到一個圖片文件中，然後通過CSS的background-image和background-position屬性來顯示圖片的不同部分；
圖片地圖是把多張圖片整合到一張圖片中。雖然文件的總體大小不會改變，但是可以減少HTTP請求次數。圖片地圖只有在圖片的所有組成部分在頁面中是緊挨在一起的時候才能使用，如導航欄。確定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具有可讀性，因此不推薦這種方法；
內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中。這可能會增加頁面的大小。把內聯圖像放到樣式表（可緩存）中可以減少HTTP請求同時又避免增加頁面文件的大小。但是內聯圖像現在還沒有得到主流瀏覽器的支持。
減少頁面的HTTP請求次數是你首先要做的一步。這是改進首次訪問用戶等待時間的最重要的方法。如同Tenni Theurer的他的博客Browser Cahe Usage - Exposed!中所說，HTTP請求在無緩存情況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人獲得更加快速的體驗吧！
2、減少DNS查找次數
域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係一樣。當你在瀏覽器地址欄中輸入www.kuqin.com 時，DNS解析服務器就會返回這個域名對應的IP地址。DNS解析的過程同樣也是需要時間的。一般情況下返回給定域名對應的IP地址會花費20到120毫秒的時間。而且在這個過程中瀏覽器什麼都不會做直到DNS查找完畢。
緩存DNS查找可以改善頁面性能。這種緩存需要一個特定的緩存服務器，這種服務器一般屬於用戶的ISP提供商或者本地局域網控制，但是它同樣會在用戶使用的計算機上產生緩存。DNS信息會保留在操作系統的DNS緩存中（微軟Windows系統中DNS Client Service）。大多數瀏覽器有獨立於操作系統以外的自己的緩存。由於瀏覽器有自己的緩存記錄，因此在一次請求中它不會受到操作系統的影響。
Internet Explorer默認情況下對DNS查找記錄的緩存時間爲30分鐘，它在註冊表中的鍵值爲DnsCacheTimeout。Firefox對DNS的查找記錄緩存時間爲1分鐘，它在配置文件中的選項爲network.dnsCacheExpiration（Fasterfox把這個選項改爲了1小時）。
當客戶端中的DNS緩存都爲空時（瀏覽器和操作系統都爲空），DNS查找的次數和頁面中主機名的數量相同。這其中包括頁面中URL、圖片、腳本文件、樣式表、Flash對象等包含的主機名。減少主機名的數量可以減少DNS查找次數。
減少主機名的數量還可以減少頁面中並行下載的數量。減少DNS查找次數可以節省響應時間，但是減少並行下載卻會增加響應時間。我的指導原則是把這些頁面中的內容分割成至少兩部分但不超過四部分。這種結果就是在減少DNS查找次數和保持較高程度並行下載兩者之間的權衡了。
3、避免跳轉
跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html
瀏覽器會把用戶指向到Location中指定的URL。頭文件中的所有信息在一次跳轉中都是必需的，內容部分可以爲空。不管他們的名稱，301和302響應都不會被緩存除非增加一個額外的頭選項，如Expires或者Cache-Control來指定它緩存。<meat />元素的刷新標籤和JavaScript也可以實現URL的跳轉，但是如果你必須要跳轉的時候，最好的方法就是使用標準的3XXHTTP狀態代碼，這主要是爲了確保“後退”按鈕可以正確地使用。
但是要記住跳轉會降低用戶體驗。在用戶和HTML文檔中間增加一個跳轉，會拖延頁面中所有元素的顯示，因爲在HTML文件被加載前任何文件（圖像、Flash等）都不會被下載。
有一種經常被網頁開發者忽略卻往往十分浪費響應時間的跳轉現象。這種現象發生在當URL本該有斜槓（/）卻被忽略掉時。例如，當我們要訪問http://astrology.yahoo.com/astrology 時，實際上返回的是一個包含301代碼的跳轉，它指向的是http://astrology.yahoo.com/astrology/ （注意末尾的斜槓）。在Apache服務器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。
連接新網站和舊網站是跳轉功能經常被用到的另一種情況。這種情況下往往要連接網站的不同內容然後根據用戶的不同類型（如瀏覽器類型、用戶賬號所屬類型）來進行跳轉。使用跳轉來實現兩個網站的切換十分簡單，需要的代碼量也不多。儘管使用這種方法對於開發者來說可以降低複雜程度，但是它同樣降低用戶體驗。一個可替代方法就是如果兩者在同一臺服務器上時使用Alias和mod_rewrite和實現。如果是因爲域名的不同而採用跳轉，那麼可以通過使用Alias或者mod_rewirte建立CNAME（保存一個域名和另外一個域名之間關係的DNS記錄）來替代。
4、可緩存的AJAX
Ajax經常被提及的一個好處就是由於其從後臺服務器傳輸信息的異步性而爲用戶帶來的反饋的即時性。但是，使用Ajax並不能保證用戶不會在等待異步的JavaScript和XML響應上花費時間。在很多應用中，用戶是否需要等待響應取決於Ajax如何來使用。例如，在一個基於Web的Email客戶端中，用戶必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，“異步”並不異味着“即時”，這很重要。
爲了提高性能，優化Ajax響應是很重要的。提高Ajxa性能的措施中最重要的方法就是使響應具有可緩存性，具體的討論可以查看Add an Expires or a Cache-Control Header。其它的幾條規則也同樣適用於Ajax：
Gizp壓縮文件
減少DNS查找次數
精簡JavaScript
避免跳轉
配置ETags
讓我們來看一個例子：一個Web2.0的Email客戶端會使用Ajax來自動完成對用戶地址薄的下載。如果用戶在上次使用過Email web應用程序後沒有對地址薄作任何的修改，而且Ajax響應通過Expire或者Cacke-Control頭來實現緩存，那麼就可以直接從上一次的緩存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄還是發送一個新的請求。這可以通過爲讀取地址薄的Ajax URL增加一個含有上次編輯時間的時間戳來實現，例如，&t=11900241612等。如果地址薄在上次下載後沒有被編輯過，時間戳就不變，則從瀏覽器的緩存中加載從而減少了一次HTTP請求過程。如果用戶修改過地址薄，時間戳就會用來確定新的URL和緩存響應並不匹配，瀏覽器就會重要請求更新地址薄。
即使你的Ajxa響應是動態生成的，哪怕它只適用於一個用戶，那麼它也應該被緩存起來。這樣做可以使你的Web2.0應用程序更加快捷。
5、推遲加載內容
你可以仔細看一下你的網頁，問問自己“哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構可以稍後再加載？
把整個過程按照onload事件分隔成兩部分，JavaScript是一個理想的選擇。例如，如果你有用於實現拖放和動畫的JavaScript，那麼它就以等待稍後加載，因爲頁面上的拖放元素是在初始化呈現之後才發生的。其它的例如隱藏部分的內容（用戶操作之後才顯現的內容）和處於摺疊部分的圖像也可以推遲加載
工具可以節省你的工作量：YUI Image Loader可以幫你推遲加載摺疊部分的圖片，YUI Get utility是包含JS和 CSS的便捷方法。比如你可以打開Firebug的Net選項卡看一下Yahoo的首頁。
當性能目標和其它網站開發實踐一致時就會相得益彰。這種情況下，通過程序提高網站性能的方法告訴我們，在支持JavaScript的情況下，可以先去除用戶體驗，不過這要保證你的網站在沒有JavaScript也可以正常運行。在確定頁面運行正常後，再加載腳本來實現如拖放和動畫等更加花哨的效果。
6、預加載
預加載和後加載看起來似乎恰恰相反，但實際上預加載是爲了實現另外一種目標。預加載是在瀏覽器空閒時請求將來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，因此可以大大改善訪問速度。
下面提供了幾種預加載方法：
無條件加載：觸發onload事件時，直接加載額外的頁面內容。以Google.com爲例，你可以看一下它的spirit image圖像是怎樣在onload中加載的。這個spirit image圖像在google.com主頁中是不需要的，但是卻可以在搜索結果頁面中用到它。
有條件加載：根據用戶的操作來有根據地判斷用戶下面可能去往的頁面並相應的預加載頁面內容。在search.yahoo.com中你可以看到如何在你輸入內容時加載額外的頁面內容。
有預期的加載：載入重新設計過的頁面時使用預加載。這種情況經常出現在頁面經過重新設計後用戶抱怨“新的頁面看起來很酷，但是卻比以前慢”。問題可能出在用戶對於你的舊站點建立了完整的緩存，而對於新站點卻沒有任何緩存內容。因此你可以在訪問新站之前就加載一部內容來避免這種結果的出現。在你的舊站中利用瀏覽器的空餘時間加載新站中用到的圖像的和腳本來提高訪問速度。
7、減少DOM元素數量
一個複雜的頁面意味着需要下載更多數據，同時也意味着JavaScript遍歷DOM的效率越慢。比如當你增加一個事件句柄時在500和5000個DOM元素中循環效果肯定是不一樣的。
大量的DOM元素的存在意味着頁面中有可以不用移除內容只需要替換元素標籤就可以精簡的部分。你在頁面佈局中使用表格了嗎？你有沒有僅僅爲了佈局而引入更多的<div>元素呢？也許會存在一個適合或者在語意是更貼切的標籤可以供你使用。
YUI CSS utilities可以給你的佈局帶來巨大幫助：grids.css可以幫你實現整體佈局，font.css和reset.css可以幫助你移除瀏覽器默認格式。它提供了一個重新審視你頁面中標籤的機會，比如只有在語意上有意義時才使用<div>，而不是因爲它具有換行效果才使用它。
DOM元素數量很容易計算出來，只需要在Firebug的控制檯內輸入：
document.getElementsByTagName("*").length
那麼多少個DOM元素算是多呢？這可以對照有很好標記使用的類似頁面。比如Yahoo!主頁是一個內容非常多的頁面，但是它只使用了700個元素（HTML標籤）。
8、根據域名劃分頁面內容
把頁面內容劃分成若干部分可以使你最大限度地實現平行下載。由於DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如，你可以把用到的HTML內容和動態內容放在www.example.org上，而把頁面各種組件（圖片、腳本、CSS)分別存放在statics1.example.org和statics.example.org上。
你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane找到更多相關信息。
9、使iframe的數量最小
ifrmae元素可以在父文檔中插入一個新的HTML文檔。瞭解iframe的工作理然後才能更加有效地使用它，這一點很重要。
<iframe>優點：
解決加載緩慢的第三方內容如圖標和廣告等的加載問題
Security sandbox
並行加載腳本
<iframe>的缺點：
即時內容爲空，加載也需要時間
會阻止頁面加載
沒有語意
10、不要出現404錯誤
HTTP請求時間消耗是很大的，因此使用HTTP請求來獲得一個沒有用處的響應（例如404沒有找到頁面）是完全沒有必要的，它只會降低用戶體驗而不會有一點好處。
有些站點把404錯誤響應頁面改爲“你是不是要找***”，這雖然改進了用戶體驗但是同樣也會浪費服務器資源（如數據庫等）。最糟糕的情況是指向外部JavaScript的鏈接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當作JavaScript代碼來執行。
源文檔 <http://www.kuqin.com/webpagedesign/20080513/8446.html>
在本系列的第一節中，講了提高網站性能中網站“內容”有關的10條原則。除了在網站在內容上的改進外，在網站服務器端上也有需要注意和改進的地方，它們包括：
使用內容分發網絡
爲文件頭指定Expires或Cache-Control
Gzip壓縮文件內容
配置ETag
儘早刷新輸出緩衝
使用GET來完成AJAX請求
11、使用內容分發網絡
用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不同地域位置的服務器上可以加快下載速度。但是首先我們應該做些什麼呢？
按地域佈置網站內容的第一步並不是要嘗試重新架構你的網站讓他們在分發服務器上正常運行。根據應用的需求來改變網站結構，這可能會包括一些比較複雜的任務，如在服務器間同步Session狀態和合並數據庫更新等。要想縮短用戶和內容服務器的距離，這些架構步驟可能是不可避免的。
要記住，在終端用戶的響應時間中有80%到90%的響應時間用於下載圖像、樣式表、腳本、Flash等頁面內容。這就是網站性能黃金守則。和重新設計你的應用程序架構這樣比較困難的任務相比，首先來分佈靜態內容會更好一點。這不僅會縮短響應時間，而且對於內容分發網絡來說它更容易實現。
內容分發網絡（Content Delivery Network，CDN）是由一系列分散到各個不同地理位置上的Web服務器組成的，它提高了網站內容的傳輸速度。用於向用戶傳輸內容的服務器主要是根據和用戶在網絡上的靠近程度來指定的。例如，擁有最少網絡跳數（network hops）和響應速度最快的服務器會被選定。
一些大型的網絡公司擁有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks這樣的CDN服務成本卻非常高。對於剛剛起步的企業和個人網站來說，可能沒有使用CDN的成本預算，但是隨着目標用戶羣的不斷擴大和更加全球化，CDN就是實現快速響應所必需的了。以Yahoo來說，他們轉移到CDN上的網站程序靜態內容節省了終端用戶20%以上的響應時間。使用CDN是一個只需要相對簡單地修改代碼實現顯著改善網站訪問速度的方法。
12、爲文件頭指定Expires或Cache-Control
這條守則包括兩方面的內容：
對於靜態內容：設置文件頭過期時間Expires的值爲“Never expire”（永不過期）
對於動態內容：使用恰當的Cache-Control文件頭來幫助瀏覽器進行有條件的請求
網頁內容設計現在越來越豐富，這就意味着頁面中要包含更多的腳本、樣式表、圖片和Flash。第一次訪問你頁面的用戶就意味着進行多次的HTTP請求，但是通過使用Expires文件頭就可以使這樣內容具有緩存性。它避免了接下來的頁面訪問中不必要的HTTP請求。Expires文件頭經常用於圖像文件，但是應該在所有的內容都使用他，包括腳本、樣式表和Flash等。
瀏覽器（和代理）使用緩存來減少HTTP請求的大小和次數以加快頁面訪問速度。Web服務器在HTTP響應中使用Expires文件頭來告訴客戶端內容需要緩存多長時間。下面這個例子是一個較長時間的Expires文件頭，它告訴瀏覽器這個響應直到2010年4月15日才過期。
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你使用的是Apache服務器，可以使用ExpiresDefault來設定相對當前日期的過期時間。下面這個例子是使用ExpiresDefault來設定請求時間後10年過期的文件頭：
ExpiresDefault "access plus 10 years"
要切記，如果使用了Expires文件頭，當頁面內容改變時就必須改變內容的文件名。依Yahoo!來說我們經常使用這樣的步驟：在內容的文件名中加上版本號，如yahoo_2.0.6.js。
使用Expires文件頭只有會在用戶已經訪問過你的網站後纔會起作用。當用戶首次訪問你的網站時這對減少HTTP請求次數來說是無效的，因爲瀏覽器的緩存是空的。因此這種方法對於你網站性能的改進情況要依據他們“預緩存”存在時對你頁面的點擊頻率（“預緩存”中已經包含了頁面中的所有內容）。Yahoo!建立了一套測量方法，我們發現所有的頁面瀏覽量中有75~85%都有“預緩存”。通過使用Expires文件頭，增加了緩存在瀏覽器中內容的數量，並且可以在用戶接下來的請求中再次使用這些內容，這甚至都不需要通過用戶發送一個字節的請求。
13、Gzip壓縮文件內容
網絡傳輸中的HTTP請求和應答時間可以通過前端機制得到顯著改善。的確，終端用戶的帶寬、互聯網提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。但是還有其他因素影響着響應時間。通過減小HTTP響應的大小可以節省HTTP響應時間。
從HTTP/1.1開始，web客戶端都默認支持HTTP請求中有Accept-Encoding文件頭的壓縮格式：
Accept-Encoding: gzip, deflate
如果web服務器在請求的文件頭中檢測到上面的代碼，就會以客戶端列出的方式壓縮響應內容。Web服務器把壓縮方式通過響應文件頭中的Content-Encoding來返回給瀏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項目開發並通過RFC 1952來標準化的。另外僅有的一個壓縮格式是deflate，但是它的使用範圍有限效果也稍稍遜色。
Gzip大概可以減少70%的響應規模。目前大約有90%通過瀏覽器傳輸的互聯網交換支持gzip格式。如果你使用的是Apache，gzip模塊配置和你的版本有關：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
瀏覽器和代理都會存在這樣的問題：瀏覽器期望收到的和實際接收到的內容會存在不匹配的現象。幸好，這種特殊情況隨着舊式瀏覽器使用量的減少在減少。Apache模塊會通過自動添加適當的Vary響應文件頭來避免這種狀況的出現。
服務器根據文件類型來選擇需要進行gzip壓縮的文件，但是這過於限制了可壓縮的文件。大多數web服務器會壓縮HTML文檔。對腳本和樣式表進行壓縮同樣也是值得做的事情，但是很多web服務器都沒有這個功能。實際上，壓縮任何一個文本類型的響應，包括XML和JSON，都值得的。圖像和PDF文件由於已經壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些文件的話不但會浪費CPU資源還會增加文件的大小。
Gzip壓縮所有可能的文件類型是減少文件體積增加用戶體驗的簡單方法。
14、配置ETag
Entity tags（ETags）（實體標籤）是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制（“實體”就是所說的“內容”，包括圖片、腳本、樣式表等）。增加ETag爲實體的驗證提供了一個比使用“last-modified date（上次編輯時間）”更加靈活的機制。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傳回給原始服務器。在這個例子中，如果ETag匹配，就會返回一個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
ETag的問題在於，它是根據可以辨別網站所在的服務器的具有唯一性的屬性來生成的。當瀏覽器從一臺服務器上獲得頁面內容後到另外一臺服務器上進行驗證時ETag就會不匹配，這種情況對於使用服務器組和處理請求的網站來說是非常常見的。默認情況下，Apache和IIS都會把數據嵌入ETag中，這會顯著減少多服務器間的文件驗證衝突。
Apache 1.3和2.x中的ETag格式爲inode-size-timestamp。即使某個文件在不同的服務器上會處於相同的目錄下，文件大小、權限、時間戳等都完全相同，但是在不同服務器上他們的內碼也是不同的。
IIS 5.0和IIS 6.0處理ETag的機制相似。IIS中的ETag格式爲Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤IIS配置的改變。網站所用的不同IIS服務器間ChangeNumber也不相同。 不同的服務器上的Apache和IIS即使對於完全相同的內容產生的ETag在也不相同，用戶並不會接收到一個小而快的304響應；相反他們會接收一個正常的200響應並下載全部內容。如果你的網站只放在一臺服務器上，就不會存在這個問題。但是如果你的網站是架設在多個服務器上，並且使用Apache和IIS產生默認的ETag配置，你的用戶獲得頁面就會相對慢一點，服務器會傳輸更多的內容，佔用更多的帶寬，代理也不會有效地緩存你的網站內容。即使你的內容擁有Expires文件頭，無論用戶什麼時候點擊“刷新”或者“重載”按鈕都會發送相應的GET請求。
如果你沒有使用ETag提供的靈活的驗證模式，那麼幹脆把所有的ETag都去掉會更好。Last-Modified文件頭驗證是基於內容的時間戳的。去掉ETag文件頭會減少響應和下次請求中文件的大小。微軟的這篇支持文稿講述瞭如何去掉ETag。在Apache中，只需要在配置文件中簡單添加下面一行代碼就可以了：
FileETag none
15、儘早刷新輸出緩衝
當用戶請求一個頁面時，無論如何都會花費200到500毫秒用於後臺組織HTML文件。在這期間，瀏覽器會一直空閒等待數據返回。在PHP中，你可以使用flush()方法，它允許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會可以下載文件中的內容（腳本等）而後臺同時處理剩餘的HTML頁面。這樣做的效果會在後臺煩惱或者前臺較空閒時更加明顯。
輸出緩衝應用最好的一個地方就是緊跟在<head />之後，因爲HTML的頭部分容易生成而且頭部往往包含CSS和JavaScript文件，這樣瀏覽器就可以在後臺編譯剩餘HTML的同時並行下載它們。 例子：
... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
爲了證明使用這項技術的好處，Yahoo!搜索率先研究並完成了用戶測試。
16、使用GET來完成AJAX請求
Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然後才發送數據。因此使用GET最爲恰當，因爲它只需發送一個TCP包（除非你有很多cookie）。IE中URL的最大長度爲2K，因此如果你要發送一個超過2K的數據時就不能使用GET了。
一個有趣的不同就是POST並不像GET那樣實際發送數據。根據HTTP規範，GET意味着“獲取”數據，因此當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端保存數據時使用POST。