雅虎網站頁面性能優化的34條黃金守則

會阻止頁面加載
沒有語意
十、不要出現404錯誤
     HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。
     有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分看成JavaScript代碼來執行。

十一、使用內容分發網絡
     用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不一樣地域位置的服務器上能夠加快下載速度。可是首先咱們應該作些什麼呢？
     按地域佈置網站內容的第一步並非要嘗試從新架構你的網站讓他們在分發服務器上正常運行。根據應用的需求來改變網站結構，這可能會包括一些比較複雜的任務，如在服務器間同步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是一個只須要相對簡單地修改代碼實現顯著改善網站訪問速度的方法。

十二、爲文件頭指定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文件頭，增長了緩存在瀏覽器中內容的數量，而且能夠在用戶接下來的請求中再次使用這些內容，這甚至都不須要經過用戶發送一個字節的請求。

1三、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壓縮全部可能的文件類型是減小文件體積增長用戶體驗的簡單方法。

1四、配置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

1五、儘早刷新輸出緩衝
     當用戶請求一個頁面時，不管如何都會花費200到500毫秒用於後臺組織HTML文件。在這期間，瀏覽器會一直空閒等待數據返回。在PHP中，你可使用flush()方法，它容許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會能夠下載文件中的內容（腳本等）然後臺同時處理剩餘的HTML頁面。這樣作的效果會在後臺煩惱或者前臺較空閒時更加明顯。
     輸出緩衝應用最好的一個地方就是緊跟在<head />以後，由於HTML的頭部分容易生成並且頭部每每包含CSS和JavaScript文件，這樣瀏覽器就能夠在後臺編譯剩餘HTML的同時並行下載它們。 例子：

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

爲了證實使用這項技術的好處，Yahoo!搜索率先研究並完成了用戶測試。

1六、使用GET來完成AJAX請求
     Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，而後才發送數據。所以使用GET最爲恰當，由於它只需發送一個TCP包（除非你有不少cookie）。IE中URL的最大長度爲2K，所以若是你要發送一個超過2K的數據時就不能使用GET了。
     一個有趣的不一樣就是POST並不像GET那樣實際發送數據。根據HTTP規範，GET意味着「獲取」數據，所以當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端保存數據時使用POST。

1七、把樣式表置於頂部
     在研究Yahoo!的性能表現時，咱們發現把樣式表放到文檔的<head />內部彷佛會加快頁面的下載速度。這是由於把樣式表放到<head />內會使頁面有步驟的加載顯示。
     注重性能的前端服務器每每但願頁面有秩序地加載。同時，咱們也但願瀏覽器把已經接收到內容儘量顯示出來。這對於擁有較多內容的頁面和網速較慢的用戶來講特別重要。向用戶返回可視化的反饋，好比進程指針，已經有了較好的研究並造成了正式文檔。在咱們的研究中HTML頁面就是進程指針。當瀏覽器有序地加載文件頭、導航欄、頂部的logo等對於等待頁面加載的用戶來講均可以做爲可視化的反饋。這從總體上改善了用戶體驗。
     把樣式表放在文檔底部的問題是在包括Internet Explorer在內的不少瀏覽器中這會停止內容的有序呈現。瀏覽器停止呈現是爲了不樣式改變引發的頁面元素重繪。用戶不得不面對一個空白頁面。
     HTML規範清楚指出樣式表要放包含在頁面的<head />區域內：「和<a />不一樣，<link />只能出如今文檔的<head />區域內，儘管它能夠屢次使用它」。不管是引發白屏仍是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文檔<head />內加載你的樣式表。

1八、避免使用CSS表達式（Expression）
     CSS表達式是動態設置CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支持CSS表達式。下面的例子中，使用CSS表達式能夠實現隔一個小時切換一次背景顏色：
     background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，expression中使用了JavaScript表達式。CSS屬性根據JavaScript表達式的計算結果來設置。expression方法在其它瀏覽器中不起做用，所以在跨瀏覽器的設計中單獨針對Internet Explorer設置時會比較有用。
     表達式的問題就在於它的計算頻率要比咱們想象的多。不只僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標時都會要從新計算一次。給CSS表達式增長一個計數器能夠跟蹤表達式的計算頻率。在頁面中隨便移動鼠標均可以輕鬆達到10000次以上的計算量。
     一個減小CSS表達式計算次數的方法就是使用一次性的表達式，它在第一次運行時將結果賦給指定的樣式屬性，並用這個屬性來代替CSS表達式。若是樣式屬性必須在頁面週期內動態地改變，使用事件句柄來代替CSS表達式是一個可行辦法。若是必須使用CSS表達式，必定要記住它們要計算成千上萬次而且可能會對你頁面的性能產生影響。

1九、使用外部JavaScript和CSS
     不少性能規則都是關於如何處理外部文件的。可是，在你採起這些措施前你可能會問到一個更基本的問題：JavaScript和CSS是應該放在外部文件中呢仍是把它們放在頁面自己以內呢？
     在實際應用中使用外部文件能夠提升頁面速度，由於JavaScript和CSS文件都能在瀏覽器中產生緩存。內置在HTML文檔中的JavaScript和CSS則會在每次請求中隨HTML文檔從新下載。這雖然減小了HTTP請求的次數，卻增長了HTML文檔的大小。從另外一方面來講，若是外部文件中的JavaScript和CSS被瀏覽器緩存，在沒有增長HTTP請求次數的同時能夠減小HTML文檔的大小。
     關鍵問題是，外部JavaScript和CSS文件緩存的頻率和請求HTML文檔的次數有關。雖然有必定的難度，可是仍然有一些指標能夠一測量它。若是一個會話中用戶會瀏覽你網站中的多個頁面，而且這些頁面中會重複使用相同的腳本和樣式表，緩存外部文件就會帶來更大的益處。
     許多網站沒有功能創建這些指標。對於這些網站來講，最好的堅定方法就是把JavaScript和CSS做爲外部文件引用。比較適合使用內置代碼的例外就是網站的主頁，如Yahoo!主頁和My Yahoo!。主頁在一次會話中擁有較少（可能只有一次）的瀏覽量，你能夠發現內置JavaScript和CSS對於終端用戶來講會加快響應時 間。
     對於擁有較大瀏覽量的首頁來講，有一種技術能夠平衡內置代碼帶來的HTTP請求減小與經過使用外部文件進行緩存帶來的好處。其中一個就是在首頁中內置JavaScript和CSS，可是在頁面下載完成後動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。

20、削減JavaScript和CSS
     精簡是指從去除代碼沒必要要的字符減小文件大小從而節省下載時間。消減代碼時，全部的註釋、不須要的空白字符（空格、換行、tab縮進）等都要去掉。在JavaScript中，因爲須要下載的文件體積變小了從而節省了響應時間。精簡JavaScript中目前用到的最普遍的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用於精簡CSS。
     混淆是另一種可用於源代碼優化的方法。這種方法要比精簡複雜一些而且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也能夠縮小原來代碼體積的21%，而混淆能夠達到25%。儘管混淆法能夠更好地縮減代碼，可是對於JavaScript來講精簡的風險更小。
     除消減外部的腳本和樣式表文件外，<script>和<style>代碼塊也能夠而且應該進行消減。即便你用Gzip壓縮過腳本和樣式表，精簡這些文件仍然能夠節省5%以上的空間。因爲JavaScript和CSS的功能和體積的增長，消減代碼將會得到益處。

2一、用<link>代替@import
     前面的最佳實現中提到CSS應該放置在頂端以利於有序加載呈現。
     在IE中，頁面底部@import和使用<link>做用是同樣的，所以最好不要使用它。

2二、避免使用濾鏡
     IE獨有屬性AlphaImageLoader用於修正7.0如下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器加載圖片時它會終止內容的呈現而且凍結瀏覽器。在每個元素（不只僅是圖片）它都會運算一次，增長了內存開支，所以它的問題是多方面的。
     徹底避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工做。若是你確實須要使用AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。

2三、把腳本置於頁面底部
     腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議，瀏覽器每一個主機名的並行下載內容不超過兩個。若是你的圖片放在多個主機名上，你能夠在每一個並行下載中同時下載2個以上的文件。可是當下載腳本時，瀏覽器就不會同時下載其它文件了，即使是主機名不相同。
     在某些狀況下把腳本移到頁面底部可能不太容易。好比說，若是腳本中使用了document.write來插入頁面內容，它就不能被往下移動了。這裏可能還會有做用域的問題。不少狀況下，都會遇到這方面的問題。
     一個常常用到的替代方法就是使用延遲腳本。DEFER屬性代表腳本中沒有包含document.write，它告訴瀏覽器繼續顯示。不幸的是，Firefox並不支持DEFER屬性。在Internet Explorer中，腳本可能會被延遲但效果也不會像咱們所指望的那樣。若是腳本能夠被延遲，那麼它就能夠移到頁面的底部。這會讓你的頁面加載的快一點。

2四、剔除重複腳本
     在同一個頁面中重複引用JavaScript文件會影響頁面的性能。你可能會認爲這種狀況並很少見。對於美國前10大網站的調查顯示其中有兩家存在重複引用腳本的狀況。有兩種主要因素致使一個腳本被重複引用的奇怪現象發生：團隊規模和腳本數量。若是真的存在這種狀況，重複腳本會引發沒必要要的HTTP請求和無用的JavaScript運算，這下降了網站性能。
     在Internet Explorer中會產生沒必要要的HTTP請求，而在Firefox卻不會。在Internet Explorer中，若是一個腳本被引用兩次並且它又不可緩存，它就會在頁面加載過程當中產生兩次HTTP請求。即時腳本能夠緩存，當用戶重載頁面時也會產生額外的HTTP請求。
     除增長額外的HTTP請求外，屢次運算腳本也會浪費時間。在Internet Explorer和Firefox中無論腳本是否可緩存，它們都存在重複運算JavaScript的問題。
     一個避免偶爾發生的兩次引用同一腳本的方法是在模板中使用腳本管理模塊引用腳本。在HTML頁面中使用<script />標籤引用腳本的最多見方法就是：
     <script type="text/javascript" src="menu_1.0.17.js"></script>
在PHP中能夠經過建立名爲insertScript的方法來替代：
     <?php insertScript("menu.js") ?>
爲了防止屢次重複引用腳本，這個方法中還應該使用其它機制來處理腳本，如檢查所屬目錄和爲腳本文件名中增長版本號以用於Expire文件頭等。

2五、減小DOM訪問
     使用JavaScript訪問DOM元素比較慢，所以爲了得到更多的應該頁面，應該作到：
緩存已經訪問過的有關元素
線下更新完節點以後再將它們添加到文檔樹中
避免使用JavaScript來修改頁面佈局
     有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章「高性能Ajax應該程序」。

2六、開發智能事件處理程序
     有時候咱們會感受到頁面反應遲鈍，這是由於DOM樹元素中附加了過多的事件句柄而且些事件句病被頻繁地觸發。這就是爲何說使用event delegation（事件代理）是一種好方法了。若是你在一個div中有10個按鈕，你只須要在div上附加一次事件句柄就能夠了，而不用去爲每個按鈕增長一個句柄。事件冒泡時你能夠捕捉到事件並判斷出是哪一個事件發出的。
     你一樣也不用爲了操做DOM樹而等待onload事件的發生。你須要作的就是等待樹結構中你要訪問的元素出現。你也不用等待全部圖像都加載完畢。
     你可能會但願用DOMContentLoaded事件來代替onload，可是在全部瀏覽器都支持它以前你可以使用YUI 事件應用程序中的onAvailable方法。

2七、減少Cookie體積
     HTTP coockie能夠用於權限驗證和個性化身份等多種用途。coockie內的有關信息是經過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。所以保持coockie儘量的小以減小用戶的響應時間十分重要。
有關更多信息能夠查看Tenni Theurer和Patty Chi的文章「When the Cookie Crumbles」。這們研究中主要包括：

去除沒必要要的coockie
使coockie體積儘可能小以減小對用戶響應的影響
注意在適應級別的域名上設置coockie以便使子域名不受影響
設置合理的過時時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。
2八、對於頁面內容使用無coockie域名
     當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對於這些coockie不會作任何地使用。所以他們只是由於某些負面因素而建立的網絡傳輸。全部你應該肯定對於靜態內容的請求是無coockie的請求。建立一個子域名並用他來存放全部靜態內容。
     若是你的域名是www.example.org，你能夠在static.example.org上存在靜態內容。可是，若是你不是在www.example.org上而是在頂級域名example.org設置了coockie，那麼全部對於static.example.org的請求都包含coockie。在這種狀況下，你能夠再從新購買一個新的域名來存在靜態內容，而且要保持這個域名是無coockie的。Yahoo!使用的是ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
     使用無coockie域名存在靜態內容的另一個好處就是一些代理（服務器）可能會拒絕對coockie的內容請求進行緩存。一個相關的建議就是，若是你想肯定應該使用example.org仍是www.example.org做爲你的一主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到*.example.org（*是泛域名解析，表明了全部子域名譯者dudo注）外沒有其它選擇，所以出於性能方面的考慮最好是使用帶有www的子域名而且在它上面設置coockie。

2九、優化圖像
     設計人員完成對頁面的設計以後，不要急於將它們上傳到web服務器，這裏還須要作幾件事：

你能夠檢查一下你的GIF圖片中圖像顏色的數量是否和調色板規格一致。 使用imagemagick中下面的命令行很容易檢查：
identify -verbose image.gif
若是你發現圖片中只用到了4種顏色，而在調色板的中顯示的256色的顏色槽，那麼這張圖片就還有壓縮的空間。
嘗試把GIF格式轉換成PNG格式，看看是否節省空間。大多數狀況下是能夠壓縮的。因爲瀏覽器支持有限，設計者們每每不太樂意使用PNG格式的圖片，不過這都是過去的事情了。如今只有一個問題就是在真彩PNG格式中的alpha通道半透明問題，不過一樣的，GIF也不是真彩格式也不支持半透明。所以GIF能作到的，PNG（PNG8）一樣也能作到（除了動畫）。下面這條簡單的命令能夠安全地把GIF格式轉換爲PNG格式：
convert image.gif image.png
「咱們要說的是：給PNG一個施展身手的機會吧！」
在全部的PNG圖片上運行pngcrush（或者其它PNG優化工具）。例如：
pngcrush image.png -rem alla -reduce -brute result.png
在全部的JPEG圖片上運行jpegtran。這個工具能夠對圖片中的出現的鋸齒等作無損操做，同時它還能夠用於優化和清除圖片中的註釋以及其它無用信息（如EXIF信息）：
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
30、優化CSS Spirite

在Spirite中水平排列你的圖片，垂直排列會稍稍增長文件大小；
Spirite中把顏色較近的組合在一塊兒能夠下降顏色數，理想情況是低於256色以便適用PNG8格式；
便於移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增長文件大小但對於用戶代理來講它須要更少的內存來把圖片解壓爲像素地圖。100x100的圖片爲1萬像素，而1000x1000就是100萬像素。

3一、不要在HTML中縮放圖像
     不要爲了在HTML中設置長寬而使用比實際須要大的圖片。若是你須要：
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那麼你的圖片（mycat.jpg）就應該是100x100像素而不是把一個500x500像素的圖片縮小使用。

3二、favicon.ico要小並且可緩存
     favicon.ico是位於服務器根目錄下的一個圖片文件。它是一定存在的，由於即便你不關心它是否有用，瀏覽器也會對它發出請求，所以最好不要返回一個404 Not Found的響應。因爲是在同一臺服務器上，它每被請求一次coockie就會被髮送一次。這個圖片文件還會影響下載順序，例如在IE中當你在onload中請求額外的文件時，favicon會在這些額外內容被加載前下載。
     所以，爲了減小favicon.ico帶來的弊端，要作到：

文件儘可能地小，最好小於1K
在適當的時候（也就是你不要打算再換favicon.ico的時候，由於更換新文件時不能對它進行重命名）爲它設置Expires文件頭。你能夠很安全地把Expires文件頭設置爲將來的幾個月。你能夠經過覈對當前favicon.ico的上次編輯時間來做出判斷。
Imagemagick能夠幫你建立小巧的favicon。

3三、保持單個內容小於25K
     這條限制主要是由於iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。因爲單純gizp壓縮可能達不要求，所以精簡文件就顯得十分重要。
     查看更多信息，請參閱Wayne Shea和Tenni Theurer的文件「Performance Research, Part 5: iPhone Cacheability - Making it Stick」。

3四、打包組件成複合文本
     把頁面內容打包成複合文本就如同帶有多附件的Email，它可以使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要肯定用戶代理是否支持（iPhone就不支持）。

 

 

感謝馮·諾依曼先生.是他整出了世界上的第一臺計算機,才使得咱們這些後人鳥槍換炮,由「剪刀加糨糊」的「學術土匪」晉級爲「鼠標加剪貼板」的「學術海盜」.
感謝負責答辯的老師.在我也不明白所寫爲什麼物的狀況下,他們只問了我兩個問題——都知道寫的什麼嗎？知道；參考文獻都看了麼？看了.以後便讓我經過了答辯.他們是如此和善可親的老師,他們是如此善解人意的老師,他們是如此平易近人而又偉大的老師.

轉：http://www.cnblogs.com/li0803/archive/2009/09/20/1570581.html