整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
覽器有幾個進程
從瀏覽器進程的角度來看：
網絡七層模型：
http協議發展歷史：
流程梳理：
瀏覽器接受資源后怎么處理呢？（渲染流程）
HTML自上而下進行解析，遇到header里引用外部樣式，不會立即去加載CSS樣式，而是繼續解析HTML，HTML解析完成后，再去解析CSS，等待CSS解析完成后，進行渲染。（CSS不會阻塞HTML解析）
樣式放在底部，而不是head里可能會導致重繪回流。因為樣式不放在head里，放在下面的話，瀏覽器渲染DOM并不會等待CSS加載解析完成后才觸發，而是在在解析HTML的時候會先繪制一次，解析到CSS以后，又再次繪制。
JS的執行會阻塞DOM解析，同時阻塞DOM渲染。JS要等待上面的CSS加載完畢，保證頁面js可以操作樣式。
lt;h2 id="title1">什么是HTML</h2>
HTML其實是HyperText Markup Language的縮寫, 超文本標記語言
<h2 id="title2">HTML的作用</h2>
1.首先利用記事本保存了一個標題和兩段描述, 然后修改純文本文件的擴展名為.html, 然后再利用瀏覽器打開
鄭伊健 鄭伊健，1967年10月4日出生于中國香港，籍貫廣東恩平，香港影視演員、流行男歌手。1988年參加新秀歌唱大賽加入無線電視，因拍攝“陽光檸檬茶”廣告而入行，拜羅文為師。[1] 1991年加盟BMG唱片公司以歌手身份出道。1995年開始，憑借在《古惑仔》系列電影中飾演陳浩南一角走紅。1996年憑借《古惑仔》主題曲《友情歲月》獲得十大中文金曲獎。1996年至1997年連續兩次獲得”臺灣十大偶像”獎。
2.打開之后發現顯示的格式不對, 不對的原因是因為在純文本文件中所有文字都是同級別的, 瀏覽器不知道哪些文字代表什么意思. 也就是瀏覽器不知道哪些文字是標題, 哪些文字是段落...., 所以導致了顯示的格式不正確
正是因為如此, 所以HTML應用而生. HTML就只有一個作用, 它是專門用來描述文本的語義的. 也就是說我們可以利用HTML來告訴瀏覽器哪些是標題, 哪些是段落.
這些用于描述其它文本語義的文本, 我們稱之為標簽. 并且這些用于描述文本語義的標簽將來在瀏覽器中是不會被顯示出來的
所以正是因為HTML的這些標簽是專門用來描述其它文本語義的, 并且在瀏覽器中不會被顯示出來, 所以我們稱這些文本為"超文本", 而這些文本又叫做標簽, 所以HTML被稱之為"超文本標記語言"
<h1>鄭伊健</h1><p>鄭伊健，1967年10月4日出生于中國香港，籍貫廣東恩平，香港影視演員、流行男歌手。1988年參加新秀歌唱大賽加入無線電視，因拍攝“陽光檸檬茶”廣告而入行，拜羅文為師。[1] </p><p>1991年加盟BMG唱片公司以歌手身份出道。1995年開始，憑借在《古惑仔》系列電影中飾演陳浩南一角走紅。1996年憑借《古惑仔》主題曲《友情歲月》獲得十大中文金曲獎。1996年至1997年連續兩次獲得”臺灣十大偶像”獎。</p>
注意事項:
雖然我們利用H1標簽描述一段文本之后, 這段文本在瀏覽器中顯示出來會被放大和加粗, 看上去我們是利用HTML的標簽修改了被描述的那段文本的樣式. 但是一定要記住, HTML只有一個作用, 它是專門用來給文本添加語義的, 而不是用來修改文本的樣式的
H1標簽它的作用是什么?
錯誤: H1標簽可以用來修改文字的大小, 并且還可以將文字加粗
正確: H1標簽的作用是用來告訴瀏覽器, 哪些文字是標題. 也就是H1標簽是專門用于給指定的文字添加標題語義的
<h2 id="title3">HTML發展史</h2>
<h3 id="title4">IETF簡介</h3>
IETF是英文Internet Engineering Task Force的縮寫, 翻譯過來就是"互聯網工程任務組"
IETF負責定義并管理因特網技術的所有方面。包括用于數據傳輸的IP協議、讓域名與IP地址匹配的域名系統（DNS）、用于發送郵件的簡單郵件傳輸協議（SMTP）等
<h3 id="title5">W3C簡介</h3>
W3C是英文World Wide Web Consortium的縮寫， 翻譯過來就是W3C理事會或萬維網聯盟, W3C是全球互聯網最具權威的技術標準化組織.
W3C于1994年10月在麻省理工學院計算機科學實驗室成立。創建者是萬維網的發明者Tim Berners-Lee
W3C負責web方面標準的制定，像HTML、XHTML、CSS、XML的標準就是由W3C來定制的。
Tim Berners-Lee（蒂姆·伯納斯-李），萬維網之父、html設計者、w3c創始人
百度百科
<h2 id="title7">網頁的固定格式</h2>
1.編寫網頁和寫信一樣都有一套規范和要求, 這套規范和要求中規定了寫信的固定格式
2.寫信基本結構
敬愛的江哥: 您好! 正文正文正文正文正文正文正文正文正文正文正文正文 正文正文正文正文正文正文正文正文正文正文正文正文 此致 敬禮! 你的朋友 伊健 2066年6月6日
3.編寫網頁的步驟:
3.1.新建一個文本文檔
3.2.利用記事本打開
3.3.編寫THML代碼
3.4.保存并且修改純文本文檔的擴展名為.html
3.5.利用瀏覽器打開編寫好的文件
4.網頁基本結構:
<html> <head> <title></title> </head> <body> </body></html>
5.通過觀察我們發現, HTML基本結構中所有的標簽都是成對出現的, 這些成對出現的標簽中有一個帶/有一個不帶/, 那么這些不帶/的標簽我們稱之為開始標簽, 這些帶/的我們稱之為結束標簽
<h3 id="title8">html標簽</h3>
作用:
用于告訴瀏覽器這是一個網頁, 也就是說告訴瀏覽器我是一個HTML文檔
注意點:
其它所有的標簽都必須寫在html標簽里面, 也就是寫在html開始標簽和結束標簽中間
<h3 id="title9">head標簽</h3>
作用:
指定網站的標題 / 指定網站的小圖片
添加網站的SEO相關的信息(指定網站的關鍵字/指定網站的描述信息)
外掛一些外部的css/js文件
添加一些瀏覽器適配相關的內容
用于給網站添加一些配置信息
例如:
注意點:
一般情況下, 寫在head標簽內部的內容都不會顯示給用戶查看, 也就是說一般情況下寫在head標簽內部的內容我們都看不到
<h3 id="title12">title標簽</h3>
作用:
專門用于指定網站的標題, 并且這個指定的標題將來還會作為用戶保存網站的默認標題
注意點:
title標簽必須寫在head標簽里面
<h3 id="title10">body標簽</h3>
作用:
專門用于定義HTML文檔中需要顯示給用戶查看的內容(文字/圖片/音頻/視頻)
注意點:
雖然說有時候你可能將內容寫到了別的地方在網頁中也能看到, 但是千萬不要這么干, 一定要將需要顯示的內容寫在body中
一對html標簽中(一個html開始標簽和一個html結束標簽)只能有一對body標簽
Q群：162542073
<h2 id="title11">head內部標簽</h2>
<h3 id="title13">meta標簽</h3>
1.為什么會有亂碼現象?
因為我們在編寫網頁的時候沒有指定字符集
2.如何解決亂碼現象?
在head標簽中添加<meta charset="GBK" />, 指定字符集
3.什么是字符集
字符集就是字符的集合, 也就是很多字符堆在一起. 其實字符集很像我們古代的"活字印刷術", 在活字印刷術中就是將很多刻有漢字的小章放到一個盒子中, 然后需要印刷文字的時候再去盒子中取這個小章出來用, 正是因為如此, 所以導致了亂碼問題
假設北方人和南方人都擁有裝滿小章的盒子, 但是南方人和北方人在盒子中存儲小章的順序不太一樣, 那么這個時候如果北方人和南方人都需要去取"李"字, 在南方人記憶中李字在第6個盒子的第6行的第6列中(666), 在北方人的記憶中李字在第8個盒子的第8行的第8列中(888). 那么此時如果讓一個南方人去北方人的盒子中取"李"字的小章, 必然找不到,, 所以就導致了亂碼問題
這個地方北方人的存儲小章的盒子和南方人存儲小章的盒子就對應網頁中指定的字符集, 在網頁中我們常見的字符集有兩個GBK/UTF-8, GBK就對應北方人存儲的盒子, UTF-8就對應南方人存儲的盒子
所以在網頁中指定字符集的意義就在于告訴瀏覽器我用的是哪個盒子, 你應該如何去查找才能找到對應的正確的內容
4.GBK(GB2312)和UTF-8區別
提交比較大
體積比較小
GBK(GB2312)里面存儲的字符比較少, 僅僅存儲了漢字和一些常用外文
UTF-8里面存儲的世界上所有的文字
5.那么在企業開發中我們應該使用GBK(GB2312)還是UTF-8呢?
如果你的網站僅僅包含中文, 那么推薦使用GB2312, 因為它的體積更小, 訪問速度更快
如果你的網站除了中文以外, 還包含了一些其它國家的語言 , 那么推薦使用UTF-8
懶人推薦: 不管三七二十一, 一律寫UTF-8即可
6.注意點:
在HTML文件中指定的字符集必須和保存這個文件的字符集一致, 否則還是會出現亂碼
所以僅僅指定字符集不一定能解決亂碼問題, 還需要保存文件的時候, 文件的保存格式必須和指定的字符集一致才能保證沒有亂碼問題
<h2 id="title14">HTML標簽</h2>
<h3 id="title15">HTML標簽分類</h3>
單標簽
只有開始標簽沒有結束標簽, 也就是由一個<>組成的
<meta charset="UTF-8" />
雙標簽
有開始標簽和結束標簽, 也就是由一個<>和一個</>組成的
<html></html>
<h3 id="title16">HTML標簽關系分類</h3>
并列關系(兄弟/平級)
<head></head><body></body>
嵌套關系(父子/上下級)
<head> <meta charset="UTF-8" /> <title>百度一下,你就知道123</title></head>
<h2 id="title17">DTD文檔聲明</h2>
什么是DTD文檔聲明?
由于HTML有很多個版本的規范, 每個版本的規范之間又有一定的差異. 所以為了讓瀏覽器能夠正確的編譯/解析/渲染我們的網頁, 我們需要在HTML文件的第一行告訴瀏覽器, 我們當前這個網頁是用哪一個版本的HTML規范來編寫的. 瀏覽器只要知道了我們是用哪一個版本的規范來編寫之后, 它就能夠正確的編譯/解析/渲染我們的網頁
DTD文檔聲明格式:
<!DOCTYPE html>
注意事項:
不寫也能運行
H5網頁里面用H4也能運行
<!DOCTYPE>聲明必須是 HTML 文檔的第一行，位于 <html> 標簽之前
<!DOCTYPE> 聲明不是 HTML 標簽
<!DOCTYPE> 聲明沒有結束標簽
<!DOCTYPE> 聲明對大小寫不敏感
這個聲明瀏覽器會看, 但是并不是完全依賴于這個聲明, 瀏覽器有一套自己的默認的處理機制
HTML5之前有2大種規范, 每種規范中又有3小種規范
| 大規范 | 小規范 |
|---|---|
| HTML | Strict (嚴格的) |
| HTML | Transitional(過度的,普通的,寬松的) |
| HTML | Frameset(帶有框架的頁面) |
| XHTML | Strict (嚴格的) |
| XHTML | Transitional(過度的,普通的,寬松的) |
| XHTML | Frameset(帶有框架的頁面) |
HTML的DTD文檔聲明和XHTML的DTD文檔聲明有何區別?
XHTML本身規定比如標簽必須小寫、必須嚴格閉合、必須使用引號引起屬性等等, 而HTML會更加松散沒有這么嚴格
Strict表示嚴格的, 這種模式里面的要求更為嚴格.這種嚴格主要體現在有一些標簽不能使用
例如font標簽/u標簽等
font標簽可以修改一個文本的字號、顏色、字體,但這和HTML的本質有沖突,因為HTML只能負責語義,不能負責樣式,而font標簽是用于修改樣式的,所以在Strict中是不能使用font標簽
u標簽可以給一個文本加上下劃線,但這和HTML的本質有沖突,因為HTML只能負責語義,不能負責樣式,而u標簽是用于添加下劃線是樣式.所以在Strict中是不能使用u標簽
Transitional表示普通的, 這種模式是沒有一些別的要求
例如可以使用font標簽、u標簽等
但是在企業開發中不會使用這些標簽,因為這違背了HTML的本質, 而是將這些標簽作為css的鉤子使用
Frameset表示框架, 在框架的頁面使用
后面學到框架/NodeJS 再做詳細了解
常見的DOCTYPE有如下幾種
HTML4.01:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">XHTML 1.0<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">HTML5: <!DOCTYPE html>
有這么多規范我們學習過程中到底使用哪一種比較合適呢?
www.baidu.com (B)
www.taobao.com (A)
www.qq.com (T)
www.sohu.com(大奇葩)
無論是HTML還是XHTML,過去企業級開發中用的比較多的大部分都是Transitional類型的文檔聲明
但是HTML5的時代已經到來,以上6中規范僅僅作為了解, 以后都用HTML5類型的文檔聲明, HTML5向下兼容(求此刻WC3心里陰影面積)
目前國內一線網站都更新到了HTML5的文檔聲明, 所以后續授課也是全程使用HTML5的文檔聲明
<h2 id="title18">HTML和XHTML、HTML5區別</h2>
在HTML的早期發展中，大部分標準都是所謂的retro-spec，即先有實現后有標準。在這種情況下，HTML標準不是很規范，瀏覽器也對HTML頁面中的錯誤相當寬容。這反過來又導致了HTML開發者寫出了大量含有錯誤的HTML頁面
html語言本身有一些缺陷（例如： 內容和形式不能分離；標簽單一；數據不能復用等等），隨著xml的興起人們希望xml來彌補html的不足，但是目前有成千上萬的網頁都是用html編寫的，所以完全使用xml來替代html還為時過早，于是W3C在2000年推出了xhtml1.0， 建立xhtml的目的就是實現從html向xml的過度
為了規范HTML，W3C結合XML制定了XHTML 1.0標準，這個標準沒有增加任何新的標簽，只是按照XML的要求來規范HTML，并定義了一個新的MIME type application/xhtml+xml。W3C的初衷是要求瀏覽器對這個MIME type實行強錯誤檢查，如果頁面有HTML錯誤，就要顯示錯誤信息。但是由于已有的web頁面中已經有了大量的錯誤，很多開發者拒絕使用新的MIME type。W3C不得已，在XHTML 1.0的標準之后增加了一個附錄C，允許開發者使用XHTML語法來寫頁面，同時使用舊的MIME type，application/html，來分發頁面
W3C隨后在XHTML 1.1中取消了附錄C，即使用XHTML 1.1標準的頁面必須用新的MIME type來分發。于是這個標準并沒有很多人采用
有了XHTML的教訓，W3C在制定下一代HTML標準時（HTML5），就將向后兼容作為了一個很重要的原則。HTML5確實引入了許多新的特性，但是它最重要的一個特性是，不會break已有的網頁。你可以將任何已有的網頁的第一行改成<!DOCTYPE html>，它就成也一個HTML5頁面，并且可以照樣在瀏覽器里正常的展示。
簡而言之
HTML語法非常寬松容錯性強;
XHTML更為嚴格,它要求標簽必須小寫、必須嚴格閉合、標簽中的屬性必須使用引號引起等等;
HTML5是HTML的下一個版本所以除了非常寬松容錯性強以外,還增加許多新的特性
<h2 id="title19">.htm 和 .html擴展名區別</h2>
DOS操作系統（win95或win98）下只能支持長度為3的后綴名，所以是htm
但在windows后綴長度可以大于3位，所以windows下無所謂htm與html，html是為長文件的格式命名的
所以htm是為了兼容過去的DOS命名格式存在的
更多內容微信訂閱號：網頁設計輕松學
終端用戶響應的時間中，有80%用于下載各項內容，這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。通過減少頁面中的元素可以減少HTTP請求的次數，這是提高網頁速度的關鍵步驟。
減少頁面組件的方法其實就是簡化頁面設計。那么有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這里有幾條減少HTTP請求次數同時又可能保持頁面內容豐富的技術。
1、合并文件：合并文件是通過把所有的腳本放到一個文件中來減少HTTP請求的方法，例如可以簡單地把所有的CSS文件都放入一個樣式表中。當腳本 或者樣式表在不同頁面中使用時需要做不同的修改，這可能會相對比較麻煩，但即便如此也要把這個方法作為改善頁面性能的重要一步；
2、CSS Sprites：CSS Sprites是減少圖像請求的有效方法。把所有的背景圖像都放到一個圖片文件中，然后通過CSS的background-image和background-position屬性來顯示圖片的不同部分;
3、圖片地圖：圖片地圖是把多張圖片整合到一張圖片中。雖然文件的總體大小不會改變，但是可以減少HTTP請求次數。圖片地圖只有在圖片的所有組成 部分在頁面中是緊挨在 一起的時候才能使用，如導航欄。確定圖片的坐標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具有可讀性，因此不推薦這種方法；
4、內聯圖像：內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中，這可能會增加頁面的大小。把內聯圖像放到樣式表（可緩存）中可以減少HTTP請求同時又避免增加頁面文件的大小，但是內聯圖像現在還沒有得到主流瀏覽器的支持。
減少頁面的HTTP請求次數是你優化網站性能首先要做的一步，這是改進首次訪問用戶等待時間的最重要的方法。如同Tenni Theurer的博文《Browser Cahe Usage – Exposed》中所說，HTTP請求在無緩存情況下占去了40%到60%的響應時間。改善HTTP請求，會讓那些初次訪問你網站的人獲得更加快速的體驗。
域名系統（DNS）提供了域名和IP的對應關系，就像電話本中人名和他們的電話號碼的關系一樣。當你在瀏覽器地址欄中輸入 www.52maomao.info時，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 查找次數和保持較高程度并行下載兩者之間的權衡了。
跳轉是使用301和302代碼實現的。下面是一個響應代碼為301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://52maomao.info/demo
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記錄）來替代。
Ajax經常被提及的一個好處就是由于其從后臺服務器傳輸信息的異步性而為用戶帶來的反饋的即時性。但是，使用Ajax并不能保證用戶不會在等待異步的javascript和XML響應上花費時間。
在很多應用中，用戶是否需要等待響應取決于Ajax如何來使用。例如，在一個基于Web的Email客戶端中，用戶必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，“異步”并不意味著“即時”，這很重要。
為了提高性能，優化Ajax響應是很重要的。提高Ajxa性能的措施中最重要的方法就是使響應具有可緩存性，具體的討論可以查看《Add an Expires or a Cache-Control Header》。其它的幾條規則也同樣適用于Ajax：
1、gizp壓縮文件；
2、減少DNS查找次數；
3、精簡JavaScript；
4、避免跳轉；
5、配置ETags。
讓我們來看一個例子：一個Web2.0的Email客戶端會使用Ajax來自動完成對用戶地址薄的下載。如果用戶在上次使用過Email web應用程序后沒有對地址薄作任何的修改，而且Ajax響應通過Expire或者Cacke-Control頭來實現緩存，那么就可以直接從上一次的緩 存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄還是發送一個新的請求。這可以通過為讀取地址薄的Ajax URL增加一個含有上次編輯時間的時間戳來實現，例如，&t=11900241612等。如果地址薄在上次下載后沒有被編輯過，時間戳就不變，則 從瀏覽器的緩存中加載從而減少了一次HTTP請求過程。如果用戶修改過地址薄，時間戳就會用來確定新的URL和緩存響應并不匹配，瀏覽器就會重要請求更新 地址薄。
即使你的Ajxa響應是動態生成的，哪怕它只適用于一個用戶，那么它也應該被緩存起來，這樣做可以使你的Web2.0應用程序更加快捷。
你可以仔細看一下你的網頁，問問自己“哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構可以稍后再加載？
把整個過程按照onload事件分隔成兩部分，JavaScript是一個理想的選擇。例如，如果你有用于實現拖放和動畫的JavaScript， 那么它 就以等待稍后加載，因為頁面上的拖放元素是在初始化呈現之后才發生的。其它的例如隱藏部分的內容（用戶操作之后才顯現的內容）和處于折疊部分的圖像也可以 推遲加載
工具可以節省你的工作量：YUI Image Loader可以幫你推遲加載折疊部分的圖片，YUI Get utility是包含js和CSS的便捷方法，比如你可以打開Firebug的Net選項卡看一下Yahoo的首頁。
當性能目標和其它網站開發實踐一致時就會相得益彰。這種情況下，通過程序提高網站性能的方法告訴我們，在支持JavaScript的情況下，可以先 去除用戶體驗，不過這要保證你的網站在沒有JavaScript也可以正常運行。在確定頁面運行正常后，再加載腳本來實現如拖放和動畫等更加花哨的效果。
預加載和后加載看起來似乎恰恰相反，但實際上預加載是為了實現另外一種目標。預加載是在瀏覽器空閑時請求將來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，因此可以大大改善訪問速度。
下面提供了幾種預加載方法：
無條件加載：觸發onload事件時，直接加載額外的頁面內容。以Google.com為例，你可以看一下它的spirit image圖像是怎樣在onload中加載的。這個spirit image圖像在google.com主頁中是不需要的，但是卻可以在搜索結果頁面中用到它。
有條件加載：根據用戶的操作來有根據地判斷用戶下面可能去往的頁面并相應的預加載頁面內容。在search.yahoo.com中你可以看到如何在你輸入內容時加載額外的頁面內容。
有預期的加載：載入重新設計過的頁面時使用預加載。這種情況經常出現在頁面經過重新設計后用戶抱怨“新的頁面看起來很酷，但是卻比以前慢”。問題可 能出在用戶對于你的舊站點建立了完整的緩存，而對于新站點卻沒有任何緩存內容。因此你可以在訪問新站之前就加載一部內容來避免這種結果的出現。在你的舊站 中利用瀏覽器的空余時間加載新站中用到的圖像的和腳本來提高訪問速度。
一個復雜的頁面意味著需要下載更多數據，同時也意味著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標簽）。
把頁面內容劃分成若干部分可以使你最大限度地實現平行下載。由于DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如，你可以 把用到的HTML內容和動態內容放在www.52maomao.info上，而把頁面各種組件（圖片、腳本、CSS)分別存放在 statics1.52maomao.info和statics.52maomao.info上。
ifrmae元素可以在父文檔中插入一個新的HTML文檔。了解iframe的工作理然后才能更加有效地使用它，這一點很重要。
<iframe>優點：
1、解決加載緩慢的第三方內容如圖標和廣告等的加載問題；
2、Security sandbox；
3、并行加載腳本。
<iframe>的缺點：
1、即時內容為空，加載也需要時間；
2、會阻止頁面加載；
3、沒有語意。
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的值為“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文件頭，增加了緩存在瀏覽器中內容的 數量，并且可以在用戶接下來的請求中再次使用這些內容，這甚至都不需要通過用戶發送一個字節的請求。
網絡傳輸中的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壓縮所有可能的文件類型是減少文件體積增加用戶體驗的簡單方法。
更多詳細的GZIP壓縮信息請參考我的另外兩篇文章：《GZIP頁面壓縮原理》和《WEB性能優化之GZIP壓縮》
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: love.52maomao.info
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。
當用戶請求一個頁面時，無論如何都會花費200到500毫秒用于后臺組織HTML文件。在這期間，瀏覽器會一直空閑等待數據返回。在PHP中，你可 以使用flush()方法，它允許你把已經編譯得好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會可以下載文件中的內容（腳本等）而后臺同時處理 剩余的 HTML頁面。這樣做的效果會在后臺煩惱或者前臺較空閑時更加明顯。
輸出緩沖應用最好的一個地方就是緊跟在<head />之后，因為HTML的頭部分容易生成而且頭部往往包含CSS和JavaScript文件，這樣瀏覽器就可以在后臺編譯剩余HTML的同時并行下載它們。 例子：
… <!– css, js –>
</head>
<body>
… <!– content –>
當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然后才發送數據。因此使用 GET最為恰當，因為它只需發送一個TCP包（除非你有很多cookie）。IE中URL的最大長度為2K，因此如果你要發送一個超過2K的數據時就不能 使用GET了。
一個有趣的不同就是POST并不像GET那樣實際發送數據。根據HTTP規范，GET意味著“獲取”數據，因此當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送并在服務端保存數據時使用POST。
在研究性能表現時，我們發現把樣式表放到文檔的<head />內部似乎會加快頁面的下載速度。這是因為把樣式表放到<head />內會使頁面有步驟的加載顯示。
注重性能的前端服務器往往希望頁面有秩序地加載。同時，我們也希望瀏覽器把已經接收到內容盡可能顯示出來。這對于擁有較多內容的頁面和網速較慢的用戶來說 特別重要。向用戶返回可視化的反饋，比如進程指針，已經有了較好的研究并形成了正式文檔。在我們的研究中HTML頁面就是進程指針。當瀏覽器有序地加載文 件頭、導航欄、頂部的logo等對于等待頁面加載的用戶來說都可以作為可視化的反饋。這從整體上改善了用戶體驗。
把樣式表放在文檔底部的問題是在包括Internet Explorer在內的很多瀏覽器中這會終止內容的有序呈現。瀏覽器中止呈現是為了避免樣式改變引起的頁面元素重繪，用戶不得不面對一個空白頁面。
HTML規范清楚指出樣式表要放包含在頁面的<head />區域內：“和<a />不同，<link />只能出現在文檔的<head />區域內，盡管它可以多次使用它”。無論是引起白屏還是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規范在文 檔<head />內加載你的樣式表。
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表達式，一定要記住它們要計算成千上萬次并且可能 會對你頁面的性能產生影響。
很多性能規則都是關于如何處理外部文件的。但是，在你采取這些措施前你可能會問到一個更基本的問題：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，但是在頁面下載完成后動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。
精簡是指從去除代碼不必要的字符減少文件大小從而節省下載時間。消減代碼時，所有的注釋、不需要的空白字符（空格、換行、tab縮進）等都要去掉。 在 JavaScript中，由于需要下載的文件體積變小了從而節省了響應時間。精簡JavaScript中目前用到的最廣泛的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用于精簡CSS。
混淆是另外一種可用于源代碼優化的方法。這種方法要比精簡復雜一些并且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也可以縮 小原來代碼體積的21%，而混淆可以達到25%。盡管混淆法可以更好地縮減代碼，但是對于JavaScript來說精簡的風險更小。
除消減外部的腳本和樣式表文件外，<script>和<style>代碼塊也可以并且應該進行消減。即使你用Gzip壓縮 過腳本和樣式表，精簡這些文件仍然可以節省5%以上的空間。由于JavaScript和CSS的功能和體積的增加，消減代碼將會獲得益處。
前面的最佳實現中提到CSS應該放置在頂端以利于有序加載呈現。
在IE中，頁面底部@import和使用<link>作用是一樣的，因此最好不要使用它。
IE獨有屬性AlphaImageLoader用于修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在于瀏覽器加載圖片時它會終止內容的呈現并且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了內存開支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用 AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規范建議，瀏覽器每個主機名的并行下載內容不超過兩個。如果你的圖片放在多個主機名上，你可以在每個并行下載中同時下載2個以上的文件。但是當下載腳本 時，瀏覽器就不會同時下載其它文件了，即便是主機名不相同。
在某些情況下把腳本移到頁面底部可能不太容易。比如說，如果腳本中使用了document.write來插入頁面內容，它就不能被往下移動了。這里可能還會有作用域的問題。很多情況下，都會遇到這方面的問題。
一個經常用到的替代方法就是使用延遲腳本。DEFER屬性表明腳本中沒有包含document.write，它告訴瀏覽器繼續顯示。不幸的 是，Firefox并不支持DEFER屬性。在Internet Explorer中，腳本可能會被延遲但效果也不會像我們所期望的那樣。如果腳本可以被延遲，那么它就可以移到頁面的底部，這會讓你的頁面加載的快一點。
在同一個頁面中重復引用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的方法來替代：
為了防止多次重復引用腳本，這個方法中還應該使用其它機制來處理腳本，如檢查所屬目錄和為腳本文件名中增加版本號以用于Expire文件頭等。
使用JavaScript訪問DOM元素比較慢，因此為了獲得更多的應該頁面，應該做到：
1、緩存已經訪問過的有關元素；
2、線下更新完節點之后再將它們添加到文檔樹中；
3、避免使用JavaScript來修改頁面布局。
有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章《高性能Ajax程序》。
有時候我們會感覺到頁面反應遲鈍，這是因為DOM樹元素中附加了過多的事件句柄并且些事件句病被頻繁地觸發。這就是為什么說使用event delegation（事件代理）是一種好方法了。如果你在一個div中有10個按鈕，你只需要在div上附加一次事件句柄就可以了，而不用去為每一個按 鈕增加一個句柄。事件冒泡時你可以捕捉到事件并判斷出是哪個事件發出的。
你同樣也不用為了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有圖像都加載完畢。
你可能會希望用DOMContentLoaded事件來代替事件應用程序中的onAvailable方法。
HTTP coockie可以用于權限驗證和個性化身份等多種用途。coockie內的有關信息是通過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。因此保持coockie盡可能的小以減少用戶的響應時間十分重要。
有關更多信息可以查看Tenni Theurer和Patty Chi的文章《When the Cookie Crumbles》。這們研究中主要包括：
1、去除不必要的coockie；
2、使coockie體積盡量小以減少對用戶響應的影響；
3、注意在適應級別的域名上設置coockie以便使子域名不受影響。
設置合理的過期時間，較早的Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。
當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對于這些coockie不會做任何地使用。因此他們只是因為某些負面因素而創建的 網絡傳輸。所有你應該確定對于靜態內容的請求是無coockie的請求。創建一個子域名并用他來存放所有靜態內容。
如果你的域名是www.52maomao.info，你可以在static.52maomao.info上存在靜態內容。但是，如果你不是在 www.52maomao.info 上而是在頂級域名52maomao.info設置了coockie，那么所有對于static.52maomao.info的請求都包含coockie。 在這種情 況下，你可以再重新購買一個新的域名來存在靜態內容，并且要保持這個域名是有coockie的。Yahoo!使用的是ymig.com，YouTube使 用的是ytimg.com，Amazon使用的是images-anazon.com等等。
使用無coockie域名存在靜態內容的另外一個好處就是一些代理（服務器）可能會拒絕對coockie的內容請求進行緩存。一個相關的建議就是， 如果你想確定應該使用52maomao.info還是www.52maomao.info 作為你的一主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到*.example.org（*是泛域名解析，代表 了所有子域名）外沒有其它選擇，因此出于性能方面的考慮最好是使用帶有www的子域名并且在它上面設置coockie。
設計人員完成對頁面的設計之后，不要急于將它們上傳到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
在Spirite中水平排列你的圖片，垂直排列會稍稍增加文件大小；
Spirite 中把顏色較近的組合在一起可以降低顏色數，理想狀況是低于256色以便適用PNG8格式；
便于移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增加文件大小但對于用戶代理來說它需要更少的內存來把圖片解壓為像素地圖。100×100的圖片為1萬像素，而 1000×1000就是100萬像素。
不要為了在HTML中設置長寬而使用比實際需要大的圖片。如果你需要：
<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />
那么你的圖片（mycat.jpg）就應該是100×100像素而不是把一個500×500像素的圖片縮小使用。
favicon.ico是位于服務器根目錄下的一個圖片文件。它是必定存在的，因為即使你不關心它是否有用，瀏覽器也會對它發出請求，因此最好不要 返回一 個404 Not Found的響應。由于是在同一臺服務器上，它每被請求一次coockie就會被發送一次。這個圖片文件還會影響下載順序，例如在IE中當你在 onload中請求額外的文件時，favicon會在這些額外內容被加載前下載。
因此，為了減少favicon.ico帶來的弊端，要做到：文件盡量地小，最好小于1K。
在適當的時候（也就是你不要打算再換 favicon.ico的時候，因為更換新文件時不能對它進行重命名）為它設置Expires文件頭。你可以很安全地把Expires文件頭設置為未來的幾個月。你可以通過核對當前favicon.ico的上次編輯時間來作出判斷。
Imagemagick可以幫你創建小巧的favicon。
這條限制主要是因為iPhone不能緩存大于25K的文件。注意這里指的是解壓縮后的大小。由于單純gizp壓縮可能達不要求，因此精簡文件就顯得十分重要。
查看更多信息，請參閱Wayne Shea和Tenni Theurer的文件《Performance Research, Part 5: iPhone Cacheability – Making it Stick》。
把頁面內容打包成復合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要確定用戶代理是否支持（iPhone就不支持）。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
