[轉載]雅虎35條優化黃金守則（二）
13、Gzip壓縮文件内容
網絡傳輸中(zhōng)的HTTP請求和應答時間可以通過前端機制得到顯著改善。的确，終端用戶的帶寬、互聯網提供者、與對等交換點的靠近程度等都不是網站開(kāi)發者所能 決定的。但是還有其他因素影響着響應時間。通過減小(xiǎo)HTTP響應的大(dà)小(xiǎo)可以節省HTTP響應時間。
從HTTP/1.1開(kāi)始，web客戶端都默認支持HTTP請求中(zhōng)有Accept-Encoding文件頭的壓縮格式：
Accept-Encoding: gzip, deflate
如果web服務器在請求的文件頭中(zhōng)檢測到上面的代碼，就會以客戶端列出的方式壓縮響應内容。Web服務器把壓縮方式通過響應文件頭中(zhōng)的Content- Encoding來返回給浏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項目開(kāi)發并通過RFC 1952來标準化的。另外(wài)僅有的一(yī)個壓縮格式是deflate，但是它的使用範圍有限效果也稍稍遜色。
Gzip大(dà)概可以減少70%的響應規模。目前大(dà)約有90%通過浏覽器傳輸的互聯網交換支持gzip格式。如果你使用的是Apache，gzip模塊配置和 你的版本有關：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
浏覽器和代理都會存在這樣的問題：浏覽器期望收到的和實際接收到的内容會存在不匹配的現象。幸好，這種特殊情況随着舊(jiù)式浏覽器使用量的減少在減少。 Apache模塊會通過自動添加适當的Vary響應文件頭來避免這種狀況的出現。
服務器根據文件類型來選擇需要進行gzip壓縮的文件，但是這過于限制了可壓縮的文件。大(dà)多數web服務器會壓縮HTML文檔。對腳本和樣式表進行壓縮同 樣也是值得做的事情，但是很多web服務器都沒有這個功能。實際上，壓縮任何一(yī)個文本類型的響應，包括XML和JSON，都值得的。圖像和PDF文件由于 已經壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些文件的話(huà)不但會浪費(fèi)CPU資(zī)源還會增加文件的大(dà)小(xiǎo)。
Gzip壓縮所有可能的文件類型是減少文件體(tǐ)積增加用戶體(tǐ)驗的簡單方法。
14、配置ETag
Entity tags（ETags）（實體(tǐ)标簽）是web服務器和浏覽器用于判斷浏覽器緩存中(zhōng)的内容和服務器中(zhōng)的原始内容是否匹配的一(yī)種機制（“實體(tǐ)”就是所說的“内 容”，包括圖片、腳本、樣式表等）。增加ETag爲實體(tǐ)的驗證提供了一(yī)個比使用“last-modified date（上次編輯時間）”更加靈活的機制。Etag是一(yī)個識别内容版本号的唯一(yī)字符串。唯一(yī)的格式限制就是它必須包含在雙引号内。原始服務器通過含有 ETag文件頭的響應指定頁面内容的ETag。
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195
稍後，如果浏覽器要驗證一(yī)個文件，它會使用If-None-Match文件頭來把ETag傳回給原始服務器。在這個例子中(zhōng)，如果ETag匹配，就會返回一(yī) 個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的問題在于，它是根據可以辨别網站所在的服務器的具有唯一(yī)性的屬性來生(shēng)成的。當浏覽器從一(yī)台服務器上獲得頁面内容後到另外(wài)一(yī)台服務器上進行驗證時 ETag就會不匹配，這種情況對于使用服務器組和處理請求的網站來說是非常常見的。默認情況下(xià)，Apache和IIS都會把數據嵌入ETag中(zhōng)，這會顯著 減少多服務器間的文件驗證沖突。
Apache 1.3和2.x中(zhōng)的ETag格式爲inode-size-timestamp。即使某個文件在不同的服務器上會處于相同的目錄下(xià)，文件大(dà)小(xiǎo)、權限、時間戳 等都完全相同，但是在不同服務器上他們的内碼也是不同的。
IIS 5.0和IIS 6.0處理ETag的機制相似。IIS中(zhōng)的ETag格式爲Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤 IIS配置的改變。網站所用的不同IIS服務器間ChangeNumber也不相同。不同的服務器上的Apache和IIS即使對于完全相同的内容産生(shēng)的 ETag在也不相同，用戶并不會接收到一(yī)個小(xiǎo)而快的304響應；相反他們會接收一(yī)個正常的200響應并下(xià)載全部内容。如果你的網站隻放(fàng)在一(yī)台服務器上，就 不會存在這個問題。但是如果你的網站是架設在多個服務器上，并且使用Apache和 IIS産生(shēng)默認的ETag配置，你的用戶獲得頁面就會相對慢(màn)一(yī)點，服務器會傳輸更多的内容，占用更多的帶寬，代理也不會有效地緩存你的網站内容。即使你的 内容擁有Expires文件頭，無論用戶什麽時候點擊“刷新”或者“重載”按鈕都會發送相應的GET請求。
如果你沒有使用ETag提供的靈活的驗證模式，那麽幹脆把所有的ETag都去(qù)掉會更好。Last-Modified文件頭驗證是基于内容的時間戳的。去(qù)掉 ETag文件頭會減少響應和下(xià)次請求中(zhōng)文件的大(dà)小(xiǎo)。微軟的這篇支持文稿講述了如何去(qù)掉ETag。在Apache中(zhōng)，隻需要在配置文件中(zhōng)簡單添加下(xià)面一(yī)行代 碼就可以了：
FileETag none
15、盡早刷新輸出緩沖
當用戶請求一(yī)個頁面時，無論如何都會花費(fèi)200到500毫秒用于後台組織HTML文件。在這期間，浏覽器會一(yī)直空閑等待數據返回。在PHP中(zhōng)，你可以使用 flush()方法，它允許你把已經編譯的好的部分(fēn)HTML響應文件先發送給浏覽器，這時浏覽器就會可以下(xià)載文件中(zhōng)的内容（腳本等）而後台同時處理剩餘的 HTML頁面。這樣做的效果會在後台煩惱或者前台較空閑時更加明顯。
輸出緩沖應用最好的一(yī)個地方就是緊跟在<head />之後，因爲HTML的頭部分(fēn)容易生(shēng)成而且頭部往往包含CSS和JavaScript文件，這樣浏覽器就可以在後台編譯剩餘HTML的同時并行下(xià) 載它們。 例子：
... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
爲了證明使用這項技術的好處，Yahoo!搜索率先研究并完成了用戶測試。
16、使用GET來完成AJAX請求
Yahoo!Mail團隊發現，當使用XMLHttpRequest時，浏覽器中(zhōng)的POST方法是一(yī)個“兩步走”的過程：首先發送文件頭，然後才發送數 據。因此使用GET最爲恰當，因爲它隻需發送一(yī)個TCP包（除非你有很多cookie）。IE中(zhōng)URL的最大(dà)長度爲2K，因此如果你要發送一(yī)個超過2K的 數據時就不能使用GET了。
一(yī)個有趣的不同就是POST并不像GET那樣實際發送數據。根據HTTP規範，GET意味着“獲取”數據，因此當你僅僅獲取數據時使用GET更加有意義 （從語意上講也是如此），相反，發送并在服務端保存數據時使用POST。
除此之外(wài)，JavaScript和CSS也是我(wǒ)(wǒ)們頁面中(zhōng)經常用到的内容，對它們的優化也提高網站性能的重要方面：
35、避免空的圖像來源
一(yī)個src屬性爲空串的圖像有兩種情況：
1． 直接的HTML
<img src="static/picture/bd59e836ly1gbwc0bod42j20u00u0n16.jpg">
2． JavaScript
var img = new Image();
img.src = "";
這兩種情況都會引起同樣的效果：浏覽器會再次向你的服務器發出請求。
- Internet Explorer 将向這個頁面所在的目錄發出一(yī)個請求
- Safari and Chrome 将發出對這個頁面的一(yī)個請求。
- Firefox 3 和更早的版本所采取的動作和Safari and Chrome一(yī)樣，但是 3.5版本 addressed this issue[bug 444931] and no longer sends a request.
-
Opera 不進行任何操作。
這個行爲爲何是不好的？
1、 發送大(dà)量突然的請求将使你的服務器宕機（Cripple your servers），尤其是每天有數百萬訪問量的頁面。
2、 産生(shēng)一(yī)個從未浏覽過的頁面将浪費(fèi)服務器的計算周期（computing cycles）
3、 損壞用戶數據。如果你在請求中(zhōng)追蹤狀态（以cookie或是其他的方式），你可能會損壞數據。即使這個圖像請求并沒有返回一(yī)個圖像，所有的頭被浏覽器讀取并接受，包括所有cookie。While the rest of the response is thrown away, the damage may already be done.
引起這種行爲的根源在于浏覽器中(zhōng)URI的解析方式。這種行爲定義在RFC 3986 - Uniform Resource Identifiers.當一(yī)個空串作爲一(yī)個URI時，它被認爲一(yī)個相對URI（relative URI）并通過定義在section 5.2中(zhōng)的算法被解析。這個特例，一(yī)個空串，列在section 5.4當中(zhōng)。Firefox, Safari, and Chrome都是依據這一(yī)規格來解析空串，而Internet Explorer則不正确的解析這個串，符合更早的一(yī)個規範，RFC 2396 - Uniform Resource Identifiers (this was obsoleted by RFC 3986).所以技術上，浏覽器都在做它們被期望所做的事情來解析relative URIs，問題是在這個範圍，空串不是故意造成的。
HTML5 adds to the description of the file:///C:/Users/Prayer/AppData/Local/Temp/msohtmlclip1/01/clip_image001.giftag's src attribute to instruct browsers not to make an additional request in section 4.8.2:
The src attribute must be present, and must contain a valid URL referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. If the base URI of the element is the same as the document's address, then the src attribute's value must not be the empty string.
非常希望浏覽器在将來不會有這樣的問題。不幸的是，沒有爲<script src="static/picture/bd59e836ly1gbwc0bod42j20u00u0n16.jpg"> and <link href="news-170.html">的條款。或許仍需要時間來做出調整以保證浏覽器不會意外(wài)的實現這一(yī)行爲。
這一(yī)規則是受雅虎JavaScript導師Nicolas C. Zakas啓發。更新信息請參見Empty image src can destroy your site..
三、CSS部分(fēn)
- 把樣式表置于頂部
- 避免使用CSS表達式（Expression）
- 用<link>代替@import
-
避免使用濾鏡
17、把樣式表置于頂部
在研究Yahoo!的性能表現時，我(wǒ)(wǒ)們發現把樣式表放(fàng)到文檔的<head />内部似乎會加快頁面的下(xià)載速度。這是因爲把樣式表放(fàng)到<head />内會使頁面有步驟的加載顯示。
注重性能的前端服務器往往希望頁面有秩序地加載。同時，我(wǒ)(wǒ)們也希望浏覽器把已經接收到内容盡可能顯示出來。這對于擁有較多内容的頁面和網速較慢(màn)的用戶來說 特别重要。向用戶返回可視化的反饋，比如進程指針，已經有了較好的研究并形成了正式文檔。在我(wǒ)(wǒ)們的研究中(zhōng)HTML頁面就是進程指針。當浏覽器有序地加載文 件頭、導航欄、頂部的logo等對于等待頁面加載的用戶來說都可以作爲可視化的反饋。這從整體(tǐ)上改善了用戶體(tǐ)驗。
把樣式表放(fàng)在文檔底部的問題是在包括Internet Explorer在内的很多浏覽器中(zhōng)這會中(zhōng)止内容的有序呈現。浏覽器中(zhōng)止呈現是爲了避免樣式改變引起的頁面元素重繪。用戶不得不面對一(yī)個空白(bái)頁面。
HTML規範清楚指出樣式表要放(fàng)包含在頁面的<head />區域内：“和<a />不同，<link />隻能出現在文檔的<head />區域内，盡管它可以多次使用它”。無論是引起白(bái)屏還是出現沒有樣式化的内容都不值得去(qù)嘗試。最好的方案就是按照HTML規範在文 檔<head />内加載你的樣式表。
18、避免使用CSS表達式（Expression）
CSS表達式是動态設置CSS屬性的強大(dà)（但危險）方法。Internet Explorer從第5個版本開(kāi)始支持CSS表達式。下(xià)面的例子中(zhōng)，使用CSS表達式可以實現隔一(yī)個小(xiǎo)時切換一(yī)次背景顔色：
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，expression中(zhōng)使用了JavaScript表達式。CSS屬性根據JavaScript表達式的計算結果來設置。expression 方法在其它浏覽器中(zhōng)不起作用，因此在跨浏覽器的設計中(zhōng)單獨針對Internet Explorer設置時會比較有用。
表達式的問題就在于它的計算頻(pín)率要比我(wǒ)(wǒ)們想象的多。不僅僅是在頁面顯示和縮放(fàng)時，就是在頁面滾動、乃至移動鼠标時都會要重新計算一(yī)次。給CSS表達式增加 一(yī)個計數器可以跟蹤表達式的計算頻(pín)率。在頁面中(zhōng)随便移動鼠标都可以輕松達到10000次以上的計算量。
一(yī)個減少CSS表達式計算次數的方法就是使用一(yī)次性的表達式，它在第一(yī)次運行時将結果賦給指定的樣式屬性，并用這個屬性來代替CSS表達式。如果樣式屬性 必須在頁面周期内動态地改變，使用事件句柄來代替CSS表達式是一(yī)個可行辦法。如果必須使用CSS表達式，一(yī)定要記住它們要計算成千上萬次并且可能會對你 頁面的性能産生(shēng)影響。
19、用<link>代替@import
前面的最佳實現中(zhōng)提到CSS應該放(fàng)置在頂端以利于有序加載呈現。
在IE中(zhōng)，頁面底部@import和使用<link>作用是一(yī)樣的，因此最好不要使用它。
20、避免使用濾鏡
IE獨有屬性AlphaImageLoader用于修正7.0以下(xià)版本中(zhōng)顯示PNG圖片的半透明效果。這個濾鏡的問題在于浏覽器加載圖片時它會終止内容的 呈現并且凍結浏覽器。在每一(yī)個元素（不僅僅是圖片）它都會運算一(yī)次，增加了内存開(kāi)支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中(zhōng)很好地工(gōng)作。如果你确實需要使用 AlphaImageLoader，請使用下(xià)劃線_filter又(yòu)使之對IE7以上版本的用戶無效。
四、 JavaScript部分(fēn)
- 把腳本置于頁面底部
- 使用外(wài)部JavaScript和CSS
- 削減JavaScript和CSS
- 剔除重複腳本
- 減少DOM訪問
-
開(kāi)發智能事件處理程序
21、把腳本置于頁面底部
腳本帶來的問題就是它阻止了頁面的平行下(xià)載。HTTP/1.1 規範建議，浏覽器每個主機名的并行下(xià)載内容不超過兩個。如果你的圖片放(fàng)在多個主機名上，你可以在每個并行下(xià)載中(zhōng)同時下(xià)載2個以上的文件。但是當下(xià)載腳本 時，浏覽器就不會同時下(xià)載其它文件了，即便是主機名不相同。
在某些情況下(xià)把腳本移到頁面底部可能不太容易。比如說，如果腳本中(zhōng)使用了document.write來插入頁面内容，它就不能被往下(xià)移動了。這裏可能還 會有作用域的問題。很多情況下(xià)，都會遇到這方面的問題。
一(yī)個經常用到的替代方法就是使用延遲腳本。DEFER屬性表明腳本中(zhōng)沒有包含document.write，它告訴浏覽器繼續顯示。不幸的 是，Firefox并不支持DEFER屬性。在Internet Explorer中(zhōng)，腳本可能會被延遲但效果也不會像我(wǒ)(wǒ)們所期望的那樣。如果腳本可以被延遲，那麽它就可以移到頁面的底部。這會讓你的頁面加載的快一(yī)點。
22、使用外(wài)部JavaScript和CSS
很多性能規則都是關于如何處理外(wài)部文件的。但是，在你采取這些措施前你可能會問到一(yī)個更基本的問題：JavaScript和CSS是應該放(fàng)在外(wài)部文件中(zhōng)呢 還是把它們放(fàng)在頁面本身之内呢？
在實際應用中(zhōng)使用外(wài)部文件可以提高頁面速度，因爲JavaScript和CSS文件都能在浏覽器中(zhōng)産生(shēng)緩存。内置在HTML文檔中(zhōng)的JavaScript 和CSS則會在每次請求中(zhōng)随HTML文檔重新下(xià)載。這雖然減少了HTTP請求的次數，卻增加了HTML文檔的大(dà)小(xiǎo)。從另一(yī)方面來說，如果外(wài)部文件中(zhōng)的 JavaScript和CSS被浏覽器緩存，在沒有增加HTTP請求次數的同時可以減少HTML文檔的大(dà)小(xiǎo)。
關鍵問題是，外(wài)部JavaScript和CSS文件緩存的頻(pín)率和請求HTML文檔的次數有關。雖然有一(yī)定的難度，但是仍然有一(yī)些指标可以一(yī)測量它。如果一(yī) 個會話(huà)中(zhōng)用戶會浏覽你網站中(zhōng)的多個頁面，并且這些頁面中(zhōng)會重複使用相同的腳本和樣式表，緩存外(wài)部文件就會帶來更大(dà)的益處。
許多網站沒有功能建立這些指标。對于這些網站來說，最好的堅決方法就是把JavaScript和CSS作爲外(wài)部文件引用。比較适合使用内置代碼的例外(wài)就是 網站的主頁，如Yahoo!主頁和My Yahoo!。主頁在一(yī)次會話(huà)中(zhōng)擁有較少（可能隻有一(yī)次）的浏覽量，你可以發現内置JavaScript和CSS對于終端用戶來說會加快響應時 間。
對于擁有較大(dà)浏覽量的首頁來說，有一(yī)種技術可以平衡内置代碼帶來的HTTP請求減少與通過使用外(wài)部文件進行緩存帶來的好處。其中(zhōng)一(yī)個就是在首頁中(zhōng)内置 JavaScript和CSS，但是在頁面下(xià)載完成後動态下(xià)載外(wài)部文件，在子頁面中(zhōng)使用到這些文件時，它們已經緩存到浏覽器了。
23、削減JavaScript和CSS
精簡是指從去(qù)除代碼不必要的字符減少文件大(dà)小(xiǎo)從而節省下(xià)載時間。消減代碼時，所有的注釋、不需要的空白(bái)字符（空格、換行、tab縮進）等都要去(qù)掉。在 JavaScript中(zhōng)，由于需要下(xià)載的文件體(tǐ)積變小(xiǎo)了從而節省了響應時間。精簡JavaScript中(zhōng)目前用到的最廣泛的兩個工(gōng)具是JSMin和YUI Compressor。YUI Compressor還可用于精簡CSS。
混淆是另外(wài)一(yī)種可用于源代碼優化的方法。這種方法要比精簡複雜(zá)一(yī)些并且在混淆的過程更易産生(shēng)問題。在對美國前10大(dà)網站的調查中(zhōng)發現，精簡也可以縮小(xiǎo)原來 代碼體(tǐ)積的21%，而混淆可以達到25%。盡管混淆法可以更好地縮減代碼，但是對于JavaScript來說精簡的風險更小(xiǎo)。
除消減外(wài)部的腳本和樣式表文件外(wài)，<script>和<style>代碼塊也可以并且應該進行消減。即使你用Gzip壓縮過腳本 和樣式表，精簡這些文件仍然可以節省5%以上的空間。由于JavaScript和CSS的功能和體(tǐ)積的增加，消減代碼将會獲得益處。
24、剔除重複腳本
在同一(yī)個頁面中(zhōng)重複引用JavaScript文件會影響頁面的性能。你可能會認爲這種情況并不多見。對于美國前10大(dà)網站的調查顯示其中(zhōng)有兩家存在重複引 用腳本的情況。有兩種主要因素導緻一(yī)個腳本被重複引用的奇怪現象發生(shēng)：團隊規模和腳本數量。如果真的存在這種情況，重複腳本會引起不必要的HTTP請求和 無用的JavaScript運算，這降低了網站性能。
在Internet Explorer中(zhōng)會産生(shēng)不必要的HTTP請求，而在Firefox卻不會。在Internet Explorer中(zhōng)，如果一(yī)個腳本被引用兩次而且它又(yòu)不可緩存，它就會在頁面加載過程中(zhōng)産生(shēng)兩次HTTP請求。即時腳本可以緩存，當用戶重載頁面時也會産 生(shēng)額外(wài)的HTTP請求。
除增加額外(wài)的HTTP請求外(wài)，多次運算腳本也會浪費(fèi)時間。在Internet Explorer和Firefox中(zhōng)不管腳本是否可緩存，它們都存在重複運算JavaScript的問題。
一(yī)個避免偶爾發生(shēng)的兩次引用同一(yī)腳本的方法是在模闆中(zhōng)使用腳本管理模塊引用腳本。在HTML頁面中(zhōng)使用<script />标簽引用腳本的最常見方法就是：
<script type="text/javascript" src="menu_1.0.17.js"></script>
在PHP中(zhōng)可以通過創建名爲insertScript的方法來替代：
<?php insertScript("menu.js") ?>
爲了防止多次重複引用腳本，這個方法中(zhōng)還應該使用其它機制來處理腳本，如檢查所屬目錄和爲腳本文件名中(zhōng)增加版本号以用于Expire文件頭等。
25、減少DOM訪問
使用JavaScript訪問DOM元素比較慢(màn)，因此爲了獲得更多的應該頁面，應該做到：
緩存已經訪問過的有關元素
線下(xià)更新完節點之後再将它們添加到文檔樹(shù)中(zhōng)
避免使用JavaScript來修改頁面布局
有關此方面的更多信息請查看Julien Lecomte在YUI專題中(zhōng)的文章“高性能Ajax應該程序”。
26、開(kāi)發智能事件處理程序
有時候我(wǒ)(wǒ)們會感覺到頁面反應遲鈍，這是因爲DOM樹(shù)元素中(zhōng)附加了過多的事件句柄并且些事件句病被頻(pín)繁地觸發。這就是爲什麽說使用event delegation（事件代理）是一(yī)種好方法了。如果你在一(yī)個div中(zhōng)有10個按鈕，你隻需要在div上附加一(yī)次事件句柄就可以了，而不用去(qù)爲每一(yī)個按 鈕增加一(yī)個句柄。事件冒泡時你可以捕捉到事件并判斷出是哪個事件發出的。
你同樣也不用爲了操作DOM樹(shù)而等待onload事件的發生(shēng)。你需要做的就是等待樹(shù)結構中(zhōng)你要訪問的元素出現。你也不用等待所有圖像都加載完畢。
你可能會希望用DOMContentLoaded事件來代替 事件應用程序中(zhōng)的onAvailable方法。
有關此方面的更多信息請查看Julien Lecomte在YUI專題中(zhōng)的文章“高性能Ajax應該程序”。
圖片和Coockie也是我(wǒ)(wǒ)們網站中(zhōng)幾乎不可缺少組成部分(fēn)，此外(wài)随着移動設備的流行，對于移動應用的優化也十分(fēn)重要。這主要包括：
五、Coockie部分(fēn)
- 減小(xiǎo)Cookie體(tǐ)積
-
對于頁面内容使用無coockie域名
27、減小(xiǎo)Cookie體(tǐ)積
HTTP coockie可以用于權限驗證和個性化身份等多種用途。coockie内的有關信息是通過HTTP文件頭來在web服務器和浏覽器之間進行交流的。因此 保持coockie盡可能的小(xiǎo)以減少用戶的響應時間十分(fēn)重要。
有關更多信息可以查看Tenni Theurer和Patty Chi的文章“When the Cookie Crumbles”。這們研究中(zhōng)主要包括：
去(qù)除不必要的coockie
使coockie體(tǐ)積盡量小(xiǎo)以減少對用戶響應的影響
注意在适應級别的域名上設置coockie以便使子域名不受影響
設置合理的過期時間。較早地Expire時間和不要過早去(qù)清除coockie，都會改善用戶的響應時間。
28、對于頁面内容使用無coockie域名
當浏覽器在請求中(zhōng)同時請求一(yī)張靜态的圖片和發送coockie時，服務器對于這些coockie不會做任何地使用。因此他們隻是因爲某些負面因素而創建的 網絡傳輸。所有你應該确定對于靜态内容的請求是無coockie的請求。創建一(yī)個子域名并用他來存放(fàng)所有靜态内容。
如果你的域名是http://www.example.org/ ，你可以在static.example.org上存在靜态内容。但是，如果你不是在http://www.example.org/ 上而是在頂級域名example.org設置了coockie，那麽所有對于static.example.org的請求都包含coockie。在這種情 況下(xià)，你可以再重新購買一(yī)個新的域名來存在靜态内容，并且要保持這個域名是無coockie的。Yahoo!使用的是ymig.com，YouTube使 用的是ytimg.com，Amazon使用的是images-anazon.com等等。
使用無coockie域名存在靜态内容的另外(wài)一(yī)個好處就是一(yī)些代理（服務器）可能會拒絕對coockie的内容請求進行緩存。一(yī)個相關的建議就是，如果你 想确定應該使用example.org還是http://www.example.org/ 作爲你的一(yī)主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到*.example.org（*是泛域名解析，代表 了所有子域名譯者dudo注）外(wài)沒有其它選擇，因此出于性能方面的考慮最好是使用帶有www的子域名并且在它上面設置coockie。
六、Image 部分(fēn)
- 優化圖像
- 優化CSS Spirite
- 不要在HTML中(zhōng)縮放(fàng)圖像
-
favicon.ico要小(xiǎo)而且可緩存
29、優化圖像
設計人員(yuán)完成對頁面的設計之後，不要急于将它們上傳到web服務器，這裏還需要做幾件事：
你可以檢查一(yī)下(xià)你的GIF圖片中(zhōng)圖像顔色的數量是否和調色闆規格一(yī)緻。 使用imagemagick中(zhōng)下(xià)面的命令行很容易檢查：
identify -verbose image.gif
如果你發現圖片中(zhōng)隻用到了4種顔色，而在調色闆的中(zhōng)顯示的256色的顔色槽，那麽這張圖片就還有壓縮的空間。
嘗試把GIF格式轉換成PNG格式，看看是否節省空間。大(dà)多數情況下(xià)是可以壓縮的。由于浏覽器支持有限，設計者們往往不太樂意使用PNG格式的圖片，不過 這都是過去(qù)的事情了。現在隻有一(yī)個問題就是在真彩PNG格式中(zhōng)的alpha通道半透明問題，不過同樣的，GIF也不是真彩格式也不支持半透明。因此GIF 能做到的，PNG（PNG8）同樣也能做到（除了動畫）。下(xià)面這條簡單的命令可以 安全地把GIF格式轉換爲PNG格式：
convert image.gif image.png
“我(wǒ)(wǒ)們要說的是：給PNG一(yī)個施展身手的機會吧！”
在所有的PNG圖片上運行pngcrush（或者其它PNG優化工(gōng)具）。例如：
pngcrush image.png -rem alla -reduce -brute result.png
在所有的JPEG圖片上運行jpegtran。這個工(gōng)具可以對圖片中(zhōng)的出現的鋸齒等做無損操作，同時它還可以用于優化和清除圖片中(zhōng)的注釋以及其它無用信息 （如EXIF信息）：
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
30、優化CSS Spirite
在Spirite中(zhōng)水平排列你的圖片，垂直排列會稍稍增加文件大(dà)小(xiǎo)；
Spirite中(zhōng)把顔色較近的組合在一(yī)起可以降低顔色數，理想狀況是低于256色以便适用PNG8格式；
便于移動，不要在Spirite的圖像中(zhōng)間留有較大(dà)空隙。這雖然不大(dà)會增加文件大(dà)小(xiǎo)但對于用戶代理來說它需要更少的内存來把圖片解壓爲像素地圖。 100x100的圖片爲1萬像素，而1000x1000就是100萬像素。
31、不要在HTML中(zhōng)縮放(fàng)圖像
不要爲了在HTML中(zhōng)設置長寬而使用比實際需要大(dà)的圖片。如果你需要：
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那麽你的圖片（mycat.jpg）就應該是100x100像素而不是把一(yī)個500x500像素的圖片縮小(xiǎo)使用。
32、favicon.ico要小(xiǎo)而且可緩存
favicon.ico是位于服務器根目錄下(xià)的一(yī)個圖片文件。它是必定存在的，因爲即使你不關心它是否有用，浏覽器也會對它發出請求，因此最好不要返回一(yī) 個404 Not Found的響應。由于是在同一(yī)台服務器上，它每被請求一(yī)次coockie就會被發送一(yī)次。這個圖片文件還會影響下(xià)載順序，例如在IE中(zhōng)當你在 onload中(zhōng)請求額外(wài)的文件時，favicon會在這些額外(wài)内容被加載前下(xià)載。
因此，爲了減少favicon.ico帶來的弊端，要做到：
文件盡量地小(xiǎo)，最好小(xiǎo)于1K
在适當的時候（也就是你不要打算再換favicon.ico的時候，因爲更換新文件時不能對它進行重命名）爲它設置Expires文件頭。你可以很安全地 把Expires文件頭設置爲未來的幾個月。你可以通過核對當前favicon.ico的上次編輯時間來作出判斷。
Imagemagick可以幫你創建小(xiǎo)巧的favicon。
七、 Mobile部分(fēn)
- 保持單個内容小(xiǎo)于25K
-
打包組件成複合文本
33、保持單個内容小(xiǎo)于25K
這條限制主要是因爲iPhone不能緩存大(dà)于25K的文件。注意這裏指的是解壓縮後的大(dà)小(xiǎo)。由于單純gizp壓縮可能達不要求，因此精簡文件就顯得十分(fēn)重 要。
查看更多信息，請參閱Wayne Shea和Tenni Theurer的文件“Performance Research, Part 5: iPhone Cacheability - Making it Stick”。
34、避免空的圖像來源