Web開發性能優化---UI界面篇

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! 的性能表現時,我們發現把樣式表放到文檔的 內部似乎會加快頁面的下載速度。這是因爲把樣式表放到 內會使頁面有步驟的加載顯示。

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 壓縮可能達不要求,因此精簡文件就顯得十分重要。

發佈了43 篇原創文章 · 獲贊 4 · 訪問量 2萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章