標籤：web開發效能最佳化---介面篇 效能最佳化 介面最佳化
1、盡量採用div+css布局
DIV+CSS相比較與表格布局的優勢：
a.代碼精簡
使用DIV+CSS布局，頁面代碼精簡，這一點對XHTML有所瞭解的都知道。代碼精簡所帶來的直接好處有兩點：一是提高蜘蛛爬行效率，能在最短的時間內爬完整個頁面，這樣對收錄品質有一定好處;二是由於能高效的爬行，就會受到蜘蛛喜歡，這樣對收錄數量有一定好處。
b.減少因嵌套多而影響蜘蛛爬行的問題
使用一般的Table表格架構，為了達到一定的視覺效果，不得不套用多個表格。如果嵌套的表格中是核心內容，spider爬行時跳過了這一段沒有抓取到頁面的核心，這個頁面就成了相似頁面。網站中過多的相似頁面會影響排名及網域名稱信任度。而DIV+CSS布局基本上不會存在這樣的問題，從技術角度來說，XHTML在控制樣式時也不需要過多的嵌套。
c.方便修改與維護
由於使用了DIV+CSS製作方法，在修改頁面的時候更加容易省時。根據地區內容標記，到CSS裡找到相應的ID，使得修改頁面的時候更加方便，也不會破壞頁面其他部分的配置樣式。
d. 使頁面載入得更快
由於將大部分頁面代碼寫在了CSS當中，使得頁面體積容量變得更小。相對於表格嵌套的方式，DIV+CSS將頁面獨立成更多的地區，在開啟頁面的時候，逐層載入。而不像表格嵌套，那樣將整個頁面圈在一個大表格裡，使得載入速度很慢。
2、img標籤合理使用
a、限制圖片大小 20-100k即可，盡量不影響展現的時候去最小化
b、title、alt屬性寫完整
c、不要為了在HTML 中設定長寬而使用比實際需要大的圖片。如果你需要：
<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />
那麼你的圖片（mycat.jpg ）就應該是100×100 像素而不是把一個500×500 像素的圖片縮小使用。
3、少用js特效展示，避免瞎用js特效，影響載入
主要還是Js調用，直接頁面中使用JavaScript語句，還是很佔網頁體積的,不要全部把js堆積在頁面；比如當你增加一個事件控制代碼時在500 和5000 個DOM 元素中迴圈效果肯定是不一樣的。
4、js、css動態壓縮
web系統中免不了要使用大量的javascript和css檔案，如開源的javascript架構prototype、jquery、extjs-core等等，這些js架構，少都有幾百K，我曾經做過不少項目，都用了
大量的js。特別是extjs，功能實在是強大，卻也是體積最大的一個js架構。使用中稍不留神很容易導致你的系統反映緩慢。為了提高js、css檔案的下載速度，從而提高頁面的響應速度，減小檔案的大小才是終極之道。
我之前寫到的文章：js、css動態壓縮頁面代碼 可以根據此方法進行代碼動態壓縮。
5、避免使用死連結
6、為檔案頭指定Expires 或Cache-Control
這條規則包括兩方面的內容：
對於靜態內容：設定檔案頭到期時間Expires 的值為“Never expire” （永不到期）
對於動態內容：使用恰當的Cache-Control 檔案頭來協助瀏覽器進行有條件的請求
7、產生靜態頁面
8、二級網站網域名稱，圖片網域名稱
9、圖片延時載入
我之前寫到的文章：jquery.lazyload.js實現圖片懶載入 可以根據此方法進行圖片局部延時載入。
10、可快取的AJAX
11、根據網域名稱劃分頁面內容
把頁面內容劃分成若干部分可以使你最大限度地實現平行下載。由於DNS 尋找帶來的影響你首先要確保你使用的網域名稱數量在2 個到4 個之間。例如，你可以把用到的HTML 內容和動態內容放在www.example.org上，而把頁面各種組件（圖片、指令碼、CSS) 分別存放在statics1.example.org 和statics.example.org 上。
12、使iframe 的數量最小
<iframe> 優點：解決載入緩慢的第三方內容標和廣告等的載入問題 ；Security sandbox ；並行載入指令碼 。
<iframe> 的缺點：即時內容為空白，載入也需要時間；會阻止頁面載入 ；沒有語意 。
13、把樣式表置於頂部
在研究Yahoo! 的效能表現時，我們發現把樣式表放到文檔的<head /> 內部似乎會加快頁面的下載速度。這是因為把樣式表放到<head /> 內會使頁面有步驟的載入顯示。
14、使用外部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 ，但是在頁面下載完成後動態下載外部檔案，在子頁面中使用到這些檔案時，它們已經緩衝到瀏覽器了。
15、避免使用濾鏡
IE 專屬屬性AlphaImageLoader 用於修正7.0 以下版本中顯示PNG 圖片的半透明效果。這個濾鏡的問題在於瀏覽器載入圖片時它會終止內容的呈現並且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了記憶體開支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader 的最好方法就是使用PNG8 格式來代替，這種格式能在IE 中很好地工作。如果你確實需要使用AlphaImageLoader ，請使用底線_filter 又使之對IE7 以上版本的使用者無效。
16、把指令碼置於頁面底部
指令碼帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議，瀏覽器每個主機名稱的並行下載內容不超過兩個。如果你的圖片放在多個主機名稱上，你可以在每個並行下載中同時下載2 個以上的檔案。但是當下載指令碼 時，瀏覽器就不會同時下載其它檔案了，即便是主機名稱不相同。
在某些情況下把指令碼移到頁面底部可能不太容易。比如說，如果指令碼中使用了document.write 來插入頁面內容，它就不能被往下移動了。這裡可能還會有範圍的問題。很多情況下，都會遇到這方面的問題。
一個經常用到的替代方法就是使用延遲指令碼。DEFER 屬性工作表明指令碼中沒有包含document.write ，它告訴瀏覽器繼續顯示。不幸的 是，Firefox 並不支援DEFER 屬性。在Internet Explorer 中，指令碼可能會被延遲但效果也不會像我們所期望的那樣。如果指令碼可以被延遲，那麼它就可以移到頁面的底部。這會讓你的頁面載入的快一點。
17、減小Cookie 體積
18、對於頁面內容使用無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 。
19、favicon.ico 要小而且可緩衝
favicon.ico 是位於伺服器根目錄下的一個圖片檔案。它是必定存在的，因為即使你不關心它是否有用，瀏覽器也會對它發出請求，因此最好不要返回一個404 Not Found 的響應
。由於是在同一台伺服器上，它每被請求一次coockie 就會被發送一次。這個圖片檔案還會影響下載順序，例如在IE 中當你在 onload 中請求額外的檔案時，favicon 會在這些額
外內容被載入前下載。
20、保持單個內容小於25K
這條限制主要是因為iPhone 不能緩衝大於25K 的檔案。注意這裡指的是解壓縮後的大小。由於單純gizp 壓縮可能達不要求，因此精簡檔案就顯得十分重要。
本文為個人經驗和實際工作經曆總結整理，寫得不到之處請給出寶貴意見，謝謝。
web開發效能最佳化---介面篇
