網站開發標準V1.0

頁面設計

尺寸規範

1、電腦頁面標準按1024*768尺寸製作，推薦尺寸爲1002*610px。移動端頁面因款式不同需要進行多款設備適配。

Iphone-iphone3GS:320px*480px

iphone4-iphone4S:640px*960px

iphone5-iphone5s:640px*1136px

Andriod版本主流的手機設計尺寸：460px*800px

2、電腦頁面長度原則上不超過3屏，寬度不超過1屏 

3、banner高度不要超過150px

4、每個非首頁靜態頁面含圖片字節不超過300K，全尺寸banner第一個場景控制在200k以內二個場景在300K，三個場景在400K以此類推。

5、移動端頁面2g網絡下不超過150K、3G不超過300K、wifi情況下不超過500K。

 

導航規範

1、導航要簡單、清晰，建議不超過3層的鏈接

2、用於導航的文字要簡明扼要，字數限制在一行以內

3、首頁，各欄目一級頁面之間互鏈，各欄目一級和本欄目二級頁面之間互鏈

4、超過三級頁面，在頁面頂部設置導航條，標明位置

5、突出最近更新的信息，可以加上更新時間或New標識

6、連續性頁面應加入上一頁，下一頁按鈕

7、超過一屏的內容，在底部應有go top按鈕

8、超過三屏的內容，應在頭部設提綱，直接鏈接到文內錨點

鏈接規範

1、新聞、信息類通常用新開窗口方式打開。

2、頂部導航、底部導航通常採取在本頁打開，特殊欄目和功能可新開窗口。

3、鏈接帶下劃線爲鏈接通常的默認風格，頂部導航或特殊位置爲了觀賞性可用樣式表取消下劃線。

4、鏈接的顏色可配合主題顏色風格改變，通常爲藍色、暗藍色、黑色，但激活後的鏈接顏色、鼠標移動其上時的鏈接顏色要同本身顏色進行區分。

字體規範

1、爲了保證不同瀏覽器上字號保持一致，字號建議用點數pt和像素px來定義，pt一般使用中文宋體的9pt和11pt，px一般使用中文宋體12px 和14.7px 這是經過優化的字號，黑體字或者宋體字加粗時，一般選用11pt和14.7px 的字號比較合適。

2、大小爲9pt時，行距爲120%；信息類最終頁面採用彈出方式，標題及正文字體規定爲11pt，行距爲140%。所有頁面字體大小建議不要超過11pt。

3、考慮字體大小的兼容性，避免使用size=2的方式定義，儘量使用pt或px並用css定義

4、文字顏色與頁面配色協調，不使用與背景色相近的顏色。

5、非圖像設計的字體一律採用windows標準宋體。（如果做特殊效果需做成圖）要

加粗文字用Bold,不要用Strong。

6、頁面文本不使用下劃線方式，也儘量少採用粗體顯示。

CSS書寫規範

1、所有的CSS的儘量採用外部調用

<LINK href="style/style.css" rel="stylesheet"type="text/css">

2、代碼較長的首頁和重要欄目首頁可直接內嵌CSS，避免調用時間太長，使頁面未及時調用CSS風格而顯得凌亂。

3、書寫時復位義的最先，僞類其次，自定義最後（其中a:linka:visited a:hover a:actived 要按照順序寫）便於自己和他人閱讀。

JS調用規範

所有的javascript腳本儘量採取外部調用

<SCRIPT LANGUAGE="JavaScript"SRC="script/xxxxx.js"></SCRIPT>

錯誤信息規範

所有程序出錯頁面、找不到的頁面不要使用默認的出錯提示，要設計爲帶網站標識和說明的個性化的出錯提示頁面。

所有頁面必須均需經過瀏覽器兼容測試，通常須支持主流瀏覽器IE、Firefox。

標籤頁

網站信息多時可以採用標籤頁來進行分類，但標籤頁中儘量少用圖片

圖片的分類及命名規則

1、名稱分爲頭尾兩兩部分，用下劃線隔開。

2、頭部分表示此圖片的大類性質，例如廣告、標誌、菜單、按鈕等等。

3、一般來說:

放置在頁面頂部的廣告、裝飾圖案等長方形的圖片我們取名：banner

標誌性的圖片我們取名爲：logo

在頁面上位置不固定並且帶有鏈接的小圖片我們取名爲button

在頁面上某一個位置連續出現，性質相同的鏈接欄目的圖片我們取名：menu

裝飾用的照片我們取名：pic

不帶鏈接表示標題的圖片我們取名：title

依照此原則類推。

4、尾部分用來表示圖片的具體含義，如果有類似圖片就用數字區別。

5、下面是幾個樣例，大家應該能夠一眼看明白圖片的意義：

banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.giftitle_news.gif

logo_police.gif,title_top01.gif, title_top02.gif

6、小的圖標一定做成透明的。

目錄結構規範

目錄建立的原則：以最少的層次提供最清晰簡便的訪問結構。

1、目錄命名的規範（參照名稱約定）

2、根目錄一般只存放index.html以及其他必須的系統文件

3、每個主要欄目建立一個相應的獨立目錄

4、images用於存放各頁面都要使用的圖片

5、所有JS腳本存放在根目錄下的js目錄

6、所有CSS文件存放在根目錄下css目錄

7、每個語言版本存放於獨立的目錄。例如：簡體中文gb，英文en

8、所有flash, avi, ram,quicktime 等多媒體文件建議存放在根目錄下的media目錄

9、頁面下載、解釋時間在56k鏈接速度下不能超過40秒（欄目首頁、表單頁）或20秒（一般頁面）。

易用性設計

　　按鈕名稱應該易懂，用詞準確，屏棄沒楞兩可的字眼，要與同一界面上的其他按鈕易於區分，能望文知意最好。理想的情況是用戶不用查閱幫助就能知道該界面的功能並進行相關的正確操作。

易用性細則：

1):完成相同或相近功能的按鈕用Frame框起來，常用按鈕要支持快捷方式。

2):完成同一功能或任務的元素放在集中位置，減少鼠標移動的距離。

3):按功能將界面劃分區域塊，用Frame框括起來,並要有功能說明或標題。

4):界面要支持鍵盤自動瀏覽按鈕功能，即按Tab鍵、回車鍵的自動切換功能。

5):界面上首先要輸入的和重要信息的控件在Tab順序中應當靠前,位置也應放在窗口上較醒目的位置。

6):同一界面上的控件數最好不要超過10個，多於10個時可以考慮使用分頁界面顯示。

7):分頁界面要支持在頁面間的快捷切換，常用組合快捷鍵Ctrl+Tab

8):默認按鈕要支持Enter及選操作，即按Enter後自動執行默認按鈕對應操作。

9):可寫控件檢測到非法輸入後應給出說明並能自動獲得焦點。

10):Tab鍵的順序與控件排列順序要一致，目前流行總體從上到下，同時行間從左到右的方式。

11):複選框和選項框按選擇機率的高底而先後排列。

12):複選框和選項框要有默認選項，並支持Tab選擇。

13):選項數相同時多用選項框而不用下拉列表框。

14):界面空間較小時使用下拉框而不用選項框。

15):選項數較少時使用選項框，相反使用下拉列表框。

16):專業性強的軟件要使用相關的專業術語，通用性界面則提倡使用通用性詞語。

規範性設計

通常界面設計都按Windows界面的規範來設計，可以說：界面遵循規範化的程度越高，則易用性相應的就越好。小型軟件一般不提供工具廂。

規範性細則：

1):常用菜單要有命令快捷方式。

2):完成相同或相近功能的菜單用橫線隔開放在同一位置。

3):菜單前的圖標能直觀的代表要完成的操作。

4):菜單深度一般要求最多控制在三層以內。

5):工具欄要求可以根據用戶的要求自己選擇定製。

6):相同或相近功能的工具欄放在一起。

7):工具欄中的每一個按鈕要有及時提示信息。

8):一條工具欄的長度最長不能超出屏幕寬度。

9): 工具欄的圖標能直觀的代表要完成的操作。

10):系統常用的工具欄設置默認放置位置。

11):工具欄太多時可以考慮使用工具箱。

12):工具箱要具有可增減性，由用戶自己根據需求定製。

13):工具箱的默認總寬度不要超過屏幕寬度的1/5。

14): 狀態條要能顯示用戶切實需要的信息，常用的有：

目前的操作、系統狀態、用戶位置、用戶信息、提示信息、錯誤信息等，如果某一操作需要的時間較長，還應該顯示進度條和進程提示。

15)：滾動條的長度要根據顯示信息的長度或寬度能及時變換，以利於用戶瞭解顯示信息的位置和百分比。

16)：狀態條的高度以放置五好字爲宜，滾動條的寬度比狀態條的略窄。

17)：菜單和工具條要有清楚的界限;菜單要求凸出顯示，這樣在移走工具條時仍有立體感。

18)：菜單和狀態條中通常使用5號字體。工具條一般比菜單要寬，但不要寬的太多，否則看起來很不協調。

19): 右鍵快捷菜單採用與菜單相同的準則。

幫助設計

系統應該提供詳盡而可靠的幫助文檔，在用戶使用產生迷惑時可以自己尋求解決方法。

幫助設施細則：

1)：幫助文檔中的性能介紹與說明要與系統性能配套一致。(我們的系統幫助文檔都是系統的祖先時期的說明，讓人困惑)。

2)：打包新系統時，對作了修改的地方在幫助文檔中要做相應的修改。

3)：操作時要提供及時調用系統幫助的功能。常用F1。

4)：在界面上調用幫助時應該能夠及時定位到與該操作相對的幫助位置。也就是說幫助要有即時針對性。

5)：最好提供目前流行的聯機幫助格式或HTML幫助格式。

6)：用戶可以用關鍵詞在幫助索引中搜索所要的幫助，當然也應該提供幫助主題詞。

7)：如果沒有提供書面的幫助文檔的話，最好有打印幫助的功能。

8)：在幫助中應該提供我們的技術支持方式，一旦用戶難以自己解決可以方便的尋求新的幫助方式。

合理性設計

屏幕對角線相交的位置是用戶直視的地方，正上方四分之一處爲易吸引用戶注意力的位置，在放置窗體時要注意利用這兩個位置。

合理性細則：

1)：父窗體或主窗體的中心位置應該在對角線焦點附近。

2)：子窗體位置應該在主窗體的左上角或正中。

3)：多個子窗體彈出時應該依次向右下方偏移，以顯示窗體出標題爲宜。

4)：重要的命令按鈕與使用較頻繁的按鈕要放在界面上注目的位置。

5)：錯誤使用容易引起界面退出或關閉的按鈕不應該放在易點擊的位置。橫排開頭或最後與豎排最後爲易點位置。

6)：與正在進行的操作無關的按鈕應該加以屏蔽(Windows中用灰色顯示，沒法使用該按鈕)。

7)：對可能造成數據無法恢復的操作必須提供確認信息,給用戶放棄選擇的機會。

8)：非法的輸入或操作應有足夠的提示說明。

9): 對運行過程中出現問題而引起錯誤的地方要有提示，讓用戶明白錯誤出處，避免形成無限期的等待。

10): 提示、警告、或錯誤說明應該清楚、明瞭、恰當。

美觀與協調性設計

界面應該大小適合美學觀點，感覺協調舒適，能在有效的範圍內吸引用戶的注意力。

美觀與協調性細則：

1): 長寬接近黃金點比例，切忌長寬比例失調、或寬度超過長度。

2): 佈局要合理,不宜過於密集，也不能過於空曠，合理的利用空間。

3): 按鈕大小基本相近，忌用太長的名稱，免得佔用過多的界面位置。

4): 按鈕的大小要與界面的大小和空間要協調。

5): 避免空曠的界面上放置很大的按鈕。

6)：放置完控件後界面不應有很大的空缺位置。

7): 字體的大小要與界面的大小比例協調, 通常使用的字體中宋體9-12較爲美觀，很少使用超過12號的字體。

8): 前景與背景色搭配合理協調，反差不宜太大，最好少用深色，如大紅、大綠等。常用色考慮使用Windows界面色調。

9): 如果使用其他顏色，主色調要柔和，具有親和力與磁力，堅決杜絕刺目的顏色。

10): 大型系統常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。

11): 界面風格要保持一致，字的大小、顏色、字體要相同，除非是需要藝術處理或有特殊要求的地方。

12): 如果窗體支持最小化和最大化或放大時，窗體上的控件也要隨着窗體而縮放；切忌只放大窗體而忽略控件的縮放。

13)：對於含有按鈕的界面一般不應該支持縮放，即右上角只有關閉功能。

14): 通常父窗體支持縮放時，子窗體沒有必要縮放。

15)：如果能給用戶提供自定義界面風格則更好，由用戶自己選擇顏色、字體等。

菜單位置設計

菜單是界面上最重要的元素，菜單位置按照按功能來組織。

菜單測試細則：

1): 菜單通常採用“常用--主要--次要--工具--幫助”的位置排列，符合流行的Windows風格。

2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。

3): 下拉菜單要根據菜單選項的含義進行分組，並且按照一定的規則進行排列，用橫線隔開。

4): 一組菜單的使用有先後要求或有嚮導作用時，應該按先後次序排列。

5): 沒有順序要求的菜單項按使用頻率和重要性排列，常用的放在開頭， 不常用的靠後放置；重要的放在開頭，次要的放在後邊。

6): 如果菜單選項較多，應該採用加長菜單的長度而減少深度的原則排列。

7): 菜單深度一般要求最多控制在三層以內。

8): 對常用的菜單要有快捷命令方式，組合原則見8。

9): 對與進行的操作無關的菜單要用屏蔽的方式加以處理，如果採用動態加載方式——即只有需要的菜單才顯示——最好。

10): 菜單前的圖標不宜太大，與字高保持一直最好。

11): 主菜單的寬度要接近，字數不應多於四個，每個菜單的字數能相同最好。

12): 主菜單數目不應太多，最好爲單排佈置。

13):菜單條是否顯示在合適的語境中？

14):應用程序的菜單條是否顯示系統相關的特性（如時鐘顯示）？

15):下拉式操作能正確工作嗎？

16):菜單、調色板和工具條是否工作正確？

17):是否適當地列出了所有的菜單功能和下拉式子功能？

18):是否可能通過鼠標訪問所有的菜單功能？

19):相同功能按鈕的圖標和文字是否一致？

20):是否能夠用其他的文本命令激活每個菜單功能？

21):菜單功能是否隨當前的窗口操作加亮或變灰？

22):菜單功能是否正確執行？

23):菜單功能的名字是否具有自解釋性？

24):菜單項是否有幫助，是否語境相關？

25):在整個交互式語境中，是否可以識別鼠標操作？

26):如果要求多次點擊鼠標，是否能夠在語境正確識別？

27):如果鼠標有多個按鈕，是否能夠在語境中正確識別？

28):光標、處理指示器和識別指針是否隨操作恰當地改變？ 

獨特性設計

此標準適用於應用軟件的設計，對網站設計方面只提供借鑑與參考。

如果一味的遵循業界的界面標準，則會喪失自己的個性.在框架符合以上規範的情況下，設計具有自己獨特風格的界面尤爲重要。尤其在商業軟件流通中有着很好的遷移默化的廣告效用。

測試細則：

1):　安裝界面上應有單位介紹或產品介紹，並有自己的圖標。

2):　主界面，最好是大多數界面上要有公司圖標。

3):　登錄界面上要有本產品的標誌，同時包含公司圖標。

4):　幫助菜單的“關於”中應有版權和產品信息。

5):　公司的系列產品要保持一直的界面風格，如背景色、字體、菜單排列方式、圖標、安裝過程、按鈕用語等應該大體一致。

8：快捷方式的組合

在菜單及按鈕中使用快捷鍵可以讓喜歡使用鍵盤的用戶操作得更快一些在西文Windows及其應用軟件中快捷鍵的使用大多是一致的。

菜單中：

1):面向事務的組合有:

Ctrl-D 刪除 ；Ctrl-F 尋找 ；Ctrl –H替換；Ctrl-I 插入 ；Ctrl-N 新記錄 ；Ctrl-S 保存 Ctrl-O 打開。

2)：列表:

Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分頁窗口或反序瀏覽同一頁面控件；。

3):編輯:

Ctrl-A全選；Ctrl-C 拷貝；Ctrl-V 粘貼；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢復操作。

4)文件操作:

Ctrl-P 打印；Ctrl-W 關閉。

5):系統菜單

Alt-A文件；Alt-E編輯；Alt-T工具；Alt－W窗口；Alt－H幫助。

6):MS Windows保留鍵:

Ctrl-Esc 任務列表 ；Ctrl-F4 關閉窗口； Alt-F4 結束應用；Alt-Tab 下一應用 ；Enter 缺省按鈕/確認操作；Esc 取消按鈕/取消操作 ；Shift-F1 上下文相關幫助。

按鈕中：

可以根據系統需要而調節，以下只是常用的組合。

Alt-Y確定(是)；Alt-C取消；Alt-N 否；Alt-D刪除；Alt-Q退出；Alt-A添加；Alt-E編輯；Alt-B瀏覽；Alt-R讀；Alt-W寫。

這些快捷鍵也可以作爲開發中文應用軟件的標準,但亦可使用漢語拼音的開頭字母。

安全性考慮

在界面上通過下列方式來控制出錯機率，會大大減少系統因用戶人爲的錯誤引起的破壞。開發者應當儘量周全地考慮到各種可能發生的問題,使出錯的可能降至最小。如應用出現保護性錯誤而退出系統,這種錯誤最容易使用戶對軟件失去信心。因爲這意味着用戶要中斷思路,並費時費力地重新登錄,而且已進行的操作也會因沒有存盤而全部丟失。

安全性細則：

1)：最重要的是排除可能會使應用非正常中止的錯誤。

2)：應當注意儘可能避免用戶無意錄入無效的數據。

3)：採用相關控件限制用戶輸入值的種類。

4)：當用戶作出選擇的可能性只有兩個時,可以採用單選框。

5)：當選擇的可能再多一些時,可以採用複選框,每一種選擇都是有效的,用戶不可能輸入任何一種無效的選擇。

6)：當選項特別多時，可以採用列表框，下拉式列表框。

7)：在一個應用系統中,開發者應當避免用戶作出未經授權或沒有意義的操作。

8)：對可能引起致命錯誤或系統出錯的輸入字符或動作要加限制或屏蔽。

9):對可能發生嚴重後果的操作要有補救措施。通過補救措施用戶可以回到原來的正確狀態。

10):對一些特殊符號的輸入、與系統使用的符號相沖突的字符等進行判斷並阻止用戶輸入該字符。

11)：對錯誤操作最好支持可逆性處理，如取消系列操作。

12):在輸入有效性字符之前應該阻止用戶進行只有輸入之後纔可進行的操作。

13):對可能造成等待時間較長的操作應該提供取消功能。

14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/還有空格。

15)：與系統採用的保留字符衝突的要加以限制。

16)：在讀入用戶所輸入的信息時，根據需要選擇是否去掉前後空格。

17)：有些讀入數據庫的字段不支持中間有空格，但用戶切實需要輸入中間空格，這時要在程序中加以處理。

10:多窗口的應用與系統資源：

設計良好的軟件不僅要有完備的功能，而且要儘可能的佔用最底限度的資源。

1)：在多窗口系統中，有些界面要求必須保持在最頂層，避免用戶在打開多個窗口時，不停的切換甚至最小化其他窗口來顯示該窗口。

2)：在主界面載入完畢後自動卸出內存，讓出所佔用的WINDOWS系統資源。

3)：關閉所有窗體，系統退出後要釋放所佔的所有系統資源 ，除非是需要後臺運行的系統。

4)：儘量防止對系統的獨佔使用。

5)：窗口能否基於相關的輸入或菜單命令適當地打開？

6)：窗口能否改變大小、移動和滾動？

7)：窗口中的數據內容能否使用鼠標、功能鍵、方向箭頭和鍵盤訪問？

8)：當被覆蓋並重調用後，窗口能否正確地再生？

9)：需要時能否使用所有窗口相關的功能？

10)：所有窗口相關的功能是可操作的嗎？

11)：是否有相關的下拉式菜單、工具條、滾動條、對話框、按鈕、圖標和其他控制可爲窗口可用，並適當地顯示？

12)：顯示多個窗口時，窗口的名稱是否被適當地表示？

13)：活動窗口是否被適當地加亮？

14)：如果使用多任務，是否所有的窗口被實時更新？

15)：多次或不正確按鼠標是否會導致無法預料的副作用？

16)：窗口的聲音和顏色提示和窗口的操作順序是否符合需求？

17)：窗口是否正確地關閉？

頁面切割

頁面中的圖片要以GIF格式保存

1. 在排布表格之前，請大家一定要好好思考一個最佳的方案，表格的嵌套儘量控制在三層以內，並且應該儘量避免 <colspan> <rowspan> 兩個標記，經驗表明，這兩個標記會帶來許多麻煩。

2. 一個網頁要儘量避免用整個一張大表格，所有的內容都嵌套在這個大表格之內，因爲瀏覽器在解釋頁面的元素時，是以表格爲單位逐一顯示，如果一張網頁是嵌套在一個大表格之內，那麼很可能造成的後果就是，當瀏覽者敲入網址，他要先面對一片空白很長時間，然後所有的網頁內容同時出現。如果必須這樣做，請使用 <tbody>標記，以便能夠使這個大表格分塊顯示。

3. 排版中我們經常會遇到需要進行首行縮進的處理，不要使用 或者全角空格來達到效果，規範的做法是在樣式表中定義 p { text-indent: 2em; } 然後給每一段加上 <p> 標記，注意，一般情況下，請不要省略 </p> 結束標記 。

4. 原則上，我們禁止用 <imgwidth=? height=?> 來人爲干預圖片顯示的尺寸，而且建議 <img> 標籤中不要帶上width 和height 兩個屬性，這是因爲製作過程中，圖片往往需要反覆的修改，這樣可以避免人爲干預圖片顯示的尺寸，儘可能的發揮瀏覽器自身的功能；但是這樣的一個副作用是當網頁還未加載圖片時，不會留出圖片的站位大小，可能會造成網頁在加載過程中抖動（如果圖片是插在一個固定大小的表格裏的，不會有這個現象），尤其是當圖片的尺寸較大時，這種現象會很明顯，所以當預料到這種會明顯導致網頁抖動的情況會發生時，請大家務必在最後給 <img>附上 width 和 height 屬性。

5. 爲了最大程度的發揮瀏覽器自動排版的功能，在一段完整的文字中請儘量不要使用<br> 來人工干預分段。

6. 不同語種的文字之間應該有一個半角空格，但避頭的符號之前和避尾的符號之後除外漢字之間的標點要用全角標點，英文字母和數字周圍的括號應該使用半角括號。

7. 所有的字號都應該用樣式表來實現，禁止在頁面中出現<font size=?> 標記。

8. 請不要在網頁中連續出現多於一個的也儘量少使用全角空格（英文字符集下，全角空格會變成亂碼），空白應該儘量使用 text-indent, padding, margin, hspace, vspace 以及透明的gif 圖片來實現。

9. 中英文混排時，我們儘可能的將英文和數字定義爲verdana和arial 兩種字體。

10. 行距建議用百分比來定義，常用的兩個行距的值是line-height:120%/150%.

11. 網站中的路徑全部採用相對路徑，一般鏈接到某一目錄下的缺省文件的鏈接路徑不必寫全名，如我們不必這樣：<a href=”aboutus/index.htm”> 而應該這樣：<a href=”aboutus/”>

12. 嵌入圖形文本的使用較大的字體，建議不要在圖形中包括文本。

13.“網頁大小”定義爲網頁的所有文件大小的總和，包括HTML文件和所有的嵌入的對象。用戶喜歡快的而不是新奇的站點。對於解調器用戶，網頁大小保持在34K以下爲合適。

頁面切割中能少用圖片的儘量少用圖片，如下圖所示，效果圖中的表格右側是一個漸近的效果，其實在切割頁面時完成用表格來替代漸近效果，具體事例如下：

原圖：

放大後的圖片：

放大後發現圖片後面的漸變效果只是3個像數的不同顏色組成的，所以在切圖時，此部分不應該直接切成圖片，應該在表格後面加上3列，每列取不同的顏色值，每列的寬度爲1，即可實現上面的效果。

網頁顯示時是以Table到結束Table爲一個單元顯示的，所以在網頁切割中要考慮網站顯示的效果，多個表格可以連接在一起，儘量少用表格套表格的形式組織頁面。

原圖：

切割示意圖：

紅色是一個表格，蘭色是表格中的行，也就是<tr>，中間需要左右分離的就再套一個表格，一行，兩列即可，紅格中灰色部分的文字就需要再套一個表格居中，間區爲1，表格背景顏色做成深灰色，然後td的背景色是淺灰色即可，不要用圖片來代替，由於網頁中的顯示是以表格爲主，也就是加載到</table>時網頁才顯示出裏面的東西，所以一個表格中不要套太多的tr，除非tr中的信息都是文字，那樣可以多套一些，如上圖，如果涉及到的中有圖片，就少用tr，再建一個表格即可，根據頁面內容的統一性，掌握好表格的數量。

建議採用CSS+div形式，替代<table>標籤

理解CSS盒子模型

什麼是CSS的盒子模式呢？爲什麼叫它是盒子？先說說我們在網頁設計中常聽的屬性名：內容(content)、填充(padding)、邊框(border)、邊界(margin)，CSS盒子模式都具備這些屬性。

CSS盒子模式 這些屬性我們可以把它轉移到我們日常生活中的盒子（箱子）上來理解，日常生活中所見的盒子也具有這些屬性，所以叫它盒子模式。那麼內容就是盒子裏裝的東西；而填充就是怕盒子裏裝的東西（貴重的）損壞而添加的泡沫或者其它抗震的輔料；邊框就是盒子本身了；至於邊界則說明盒子擺放的時候的不能全部堆在一起，要留一定空隙保持通風，同時也爲了方便取出嘛。在網頁設計上，內容常指文字、圖片等元素，但是也可以是小盒子（DIV嵌套），與現實生活中盒子不同的是，現實生活中的東西一般不能大於盒子，否則盒子會被撐壞的，而CSS盒子具有彈性，裏面的東西大過盒子本身最多把它撐大，但它不會損壞的。填充只有寬度屬性，可以理解爲生活中盒子裏的抗震輔料厚度，而邊框有大小和顏色之分，我們又可以理解爲生活中所見盒子的厚度以及這個盒子是用什麼顏色材料做成的，邊界就是該盒子與其它東西要保留多大距離。在現實生活中，假設我們在一個廣場上，把不同大小和顏色的盒子，以一定的間隙和順序擺放好，最後從廣場上空往下看，看到的圖形和結構就類似我們要做的網頁版面設計了，如下圖。

由“盒子”堆出來的網頁版面

現在對CSS盒子模式理解多少了，如果還不夠透徹，繼續往下看，我會在後面舉例，並延用盒子的概念來解釋它轉變我們的思路

傳統的前臺網頁設計是這樣進行的：根據要求，先考慮好主色調，要用什麼類型的圖片，用什麼字體、顏色等等，然後再用Photoshop這類軟件自由的畫出來，最後再切成小圖，再不自由的通過設計HTML生成頁面，改用CSS排版後，我們要轉變這個思想，此時我們主要考慮的是頁面內容的語義和結構，因爲一個強CSS控制的網頁，等做好網頁後，你還可以輕鬆的調你想要的網頁風格，況且CSS排版的另外一個目的是讓代碼易讀，區塊分明，強化代碼重用，所以結構很重要。如果你想說我的網頁設計的很複雜，到後來能不能實現那樣的效果？我要告訴你的是，如果用CSS實現不了的效果，一般用表格也是很難實現的，因爲CSS的控制能力實在是太強大了，順便說一點的是用CSS排版有一個很實用的好處是，如果你是接單做網站的，如果你用了CSS排版網頁，做到後來客戶有什麼不滿意，特別是色調的話，那麼改起來就相當容易，甚至你還可以定製幾種風格的CSS文件供客戶選擇，又或者寫一個程序實現動態調用，讓網站具有動態改變風格的功能。

實現結構與表現分離

在真正開始佈局實踐之前，再來認識一件事——結構和表現相分離，這也用CSS佈局的特色所在，結構與表現分離後，代碼才簡潔，更新才方便，這不正是我們學習CSS的目的所在嗎？舉個例來說P是結構化標籤，有P標籤的地方表示這是一個段落區塊，margin是表現屬性，我要讓一個段落右縮進2字高，有些人會想到加空格，然後不斷地加空格，但現在可以給P標籤指定一個CSS樣式：P {text-indent: 2em;}，這樣結果body內容部分就如下，這沒有外加任何表現控制的標籤：

<p>加進天涯社區有一段時間了，但一直沒有時間寫點東西，今天寫了一篇有關CSS佈局的文章，併力求通過一種通俗的語言來說明知識點，還配以實例和圖片，相信對初學CSS佈局的人會帶來一定的幫助。</p>

如果還要對這個段落加上字體、字號、背景、行距等修飾，直接把對應的CSS加進P樣式裏就行了，不用像這樣來寫了：

<p><font color="#FF0000" face="宋體">段落內容</font></p>

這個是結構和表現混合一起寫的，如果很多段落有統一結構和表現的話，再這樣累加寫下去代碼就繁冗了。

再直接列一段代碼加深理解結構和表現相分離：

用CSS排版

<styletype="text/css">

<!--

#photoListimg{

height:80;

width:100;

margin:5pxauto;

}

-->

</style><divid="photoList">

<imgsrc="01.jpg"/>

<imgsrc="02.jpg"/>

<imgsrc="03.jpg"/>

<imgsrc="04.jpg"/>

<imgsrc="05.jpg"/>

</div>

不用CSS排版

<imgsrc="01.jpg"width="100"height="80"align="middle"/>

<imgsrc="02.jpg"width="100"height="80"align="middle"/>

<imgsrc="03.jpg"width="100"height="80"align="middle"/>

<imgsrc="04.jpg"width="100"height="80"align="middle"/>

<imgsrc="05。jpg"width="100"height="80"align="middle"/>

第一種方法是結構表現相分離，內容部分代碼簡單吧，如果還有更多的圖片列表的話，那麼第一種CSS佈局方法就更有優勢，我打個比喻你好理解：我在BODY向你介紹一個人，我只對你說他是一個人，至於他是一個什麼樣的人，有多高，是男是女，你去CSS那裏查下就知道。這樣我在BODY的工作就簡單了，也就是說BODY的代碼就簡單了。如果BODY有一個團隊人在那裏，我在CSS記錄一項就行了，這有點像Flash軟件裏的組件和實例的概念，不同的實例共享同一個組件，這樣動畫文件就不大了，把這種想法移到CSS網頁設計中，就是代碼不復雜，網頁文件體積小能較快被客戶端下載了。演示地址：用CSS排版減小網頁文件體積

像上面我做的那個版面，一共分爲四個區塊，每個區塊的框架是一樣的，這個框架就是用CSS寫出來的，樣式寫一次，就可以被無數次調用了(用class調用，而不是ID)，只要改變其中的文字內容就可以生成風格統一的衆多板塊了，它的樣式和結構代碼是（請不要直接複製生成網頁，把下面代碼分別粘貼到網頁中它們應在的位置）：

<styletype="text/css">

<!--

*

body{

font-size:12px;

margin:0pxauto;

height:auto;

width:805px;

}

.mainBox{

border:1pxdashed#0099CC;

margin:3px;

padding:0px;

float:left;

height:300px;

width:192px;

}

.mainBoxh5{

float:left;

height:20px;

width:179px;

color:#FFFFFF;

padding:6px3px3px10px;

background-color:#0099CC;

font-size:16px;

}

.mainBoxp{

line-height:1.5em;

text-indent:2em;

margin:35px5px5px5px;

}

-->

</style>

<divclass="mainBox">

<h5>前言</h5>

<p>正文內容</p>

</div>

<divclass="mainBox">

<h5>CSS盒子模式</h5>

<p>正文內容</p>

</div>

<divclass="mainBox">

<h5>轉變思想</h5>

<p>正文內容</p>

</div>

<divclass="mainBox">

<h5>熟悉步驟</h5>

<p>正文內容</p>

</div>

熟悉工作流程

在真正開始工作之前我們腦海中要形成這樣一種思想：表格是什麼我不知道，在內容部分我不能讓它再出現表現控制標籤，如：font、color、height、width、align等標籤不能再出現，（簡單說工作前先洗腦，忘掉以前的一慣做法，去接受和使用全新的方法），我不是單純的用DIV來實現排版的嵌套，DIV是塊級元素，而像P也是塊級元素，例如要分出幾個文字內容塊，不是一定要用DIV才叫DIV排版，不是“<div>文字塊一</div><div>文字塊二</div><div>文字塊三</div>”，而用“<p>文字塊一</p><p>文字塊二</p><p>文字塊三</p>”更合適。

用DIV+CSS設計思路是這樣的: 1.用div來定義語義結構；2.然後用CSS來美化網頁，如加入背景、線條邊框、對齊屬性等；3.最後在這個CSS定義的盒子內加上內容，如文字、圖片等（沒有表現屬性的標籤），下面大家跟我一起來做一個實例加深對這個步驟的理解。先看結果圖：

 

用div來定義語義結構

上面我們定義了四個盒子，按照我們想要的結果是，我們要讓這些盒子等寬，並從下到下整齊排列，然後在整個頁面中居中對齊，爲了方便控制，我們再把這四個盒子裝進一個更大的盒子，這個盒子就是BODY，這樣代碼就變成:

<body>

<divid="header"></div>

<divid="nav"></div>

<divid="content"></div>

<divid="footer"></div>

</body>

最外邊的大盒子（裝着小盒子的大盒子）我們要讓它在頁面居中，並復位義其寬度爲760像素，同時加上邊框，那麼它的樣式是：

body{

font-family:Arial,Helvetica,sans-serif;

font-size:12px;

margin:0pxauto;

height:auto;

width:760px;

border:1pxsolid#006633;

}

頁頭爲了簡單起見，我們這裏只要讓它整個區塊應用一幅背景圖就行了,並在其下邊界設計定一定間隙，目的是讓頁頭的圖像不要和下面要做的導航欄連在一起，這樣也是爲了美觀。其樣式代碼爲：

#header{

height:100px;

width:760px;

background-image:url(headPic.gif);

background-repeat:no-repeat;

margin:0px0px3px0px;

}

導航欄我做成像一個個小按鈕，鼠標移上去會改變按鈕背景色和字體色，那麼這些小小的按鈕我們又可以理解爲小盒子，如此一來這是一個盒子嵌套問題了，樣式代碼如下：

#nav{

height:25px;

width:760px;

font-size:14px;

list-style-type:none;

}

#navli{

float:left;

}

#navlia{

color:#000000;

text-decoration:none;

padding-top:4px;

display:block;

width:97px;

height:22px;

text-align:center;

background-color:#009966;

margin-left:2px;

}

#navlia:hover{

background-color:#006633;

color:#FFFFFF;

}

內容部分主要放入文章內容，有標題和段落，標題加粗，爲了規範化，我用H標籤，段落要自動實現首行縮進2個字,同時所有內容看起來要和外層大盒子邊框有一定距離，這裏用填充。內容區塊樣式代碼爲：

#content{

height:auto;

width:740px;

line-height:1.5em;

padding:10px;

}

#contentp{

text-indent:2em;

}

#contenth5{

font-size:16px;

margin:10px;

版權欄，給它加個背景，與頁頭相映，裏面文字要自動居中對齊，有多行內容時，行間距合適，這裏的鏈接樣式也可以單獨指定，我這裏就不做了。其樣式代碼如下：

#footer{

height:50px;

width:740px;

line-height:2em;

text-align:center;

background-color:#009966;

padding:10px;

}

最後回到樣式開頭大家會看到這樣的樣式代碼：

*{

margin:0px;

padding:0px;

}

這是用了通配符初始化各標籤邊界和填充，（因爲有部分標籤默認會有一定的邊界，如Form標籤）那麼接下來就不用對每個標籤再加以這樣的控制，這可以在一定程度上簡化代碼。最終完成全部樣式代碼是這樣的：

<styletype="text/css">

<!--

*{

margin:0px;

padding:0px;

}

body{

font-family:Arial,Helvetica,sans-serif;

font-size:12px;

margin:0pxauto;

height:auto;

width:760px;

border:1pxsolid#006633;

}

#header{

height:100px;

width:760px;

background-image:url(headPic.gif);

background-repeat:no-repeat;

margin:0px0px3px0px;

}

#nav{

height:25px;

width:760px;

font-size:14px;

list-style-type:none;

}

#navli{

float:left;

}

#navlia{

color:#000000;

text-decoration:none;

padding-top:4px;

display:block;

width:97px;

height:22px;

text-align:center;

background-color:#009966;

margin-left:2px;

}

#navlia:hover{

background-color:#006633;

color:#FFFFFF;

}

#content{

height:auto;

width:740px;

line-height:1.5em;

padding:10px;

}

#contentp{

text-indent:2em;

}

#contenth5{

font-size:16px;

margin:10px;

}

#footer{

height:50px;

width:740px;

line-height:2em;

text-align:center;

background-color:#009966;

padding:10px;

}

-->

</style>

結構代碼是這樣的：

<body>

<divid="header"></div>

<ulid="nav">

<li><ahref="#">首頁</a></li>

<li><ahref="#">文章</a></li>

<li><ahref="#">相冊</a></li>

<li><ahref="#">Blog</a></li>

<li><ahref="#">論壇</a></li>

<li><ahref="#">幫助</a></li>

</ul>

<divid="content">

<h5>前言</h5>

<p>第一段內容</p>

<h5>理解CSS盒子模式</h5>

<p>第二段內容</p>

</div>

<divid="footer">

<p>關於華升|廣告服務|華升招聘|客服中心|QQ留言|網站管理|會員登錄|購物車</p><p>Copyright©2006-2008TangGuohui.AllRightsReserved</p>

</div>

</body>

HTML規範

本編程規範適用於需要編寫HTML代碼的網頁程序開發人員。

HTML並不是一種編程語言，而是一種標記語言，它沒有任何真正的編程語言中的循環或是流程控制語句。然而，HTML代碼的格式和風格是非常重要的，因爲要經常對HTML代碼進行維護和修改，因此HTML代碼必須有很清晰的邏輯結構和佈局，而使其易懂和易於維護。

標記的書寫

HTML語言是不區分大小寫的，但一般來說，標記使用大寫書寫，如<P>, <HTML>, <TABLE>等；標記中的屬性一般使用小寫，如<A href=”a.html”>, <font size=”5”>等。

標記的換行規範

一般一個HTML代碼都會很長很複雜，因此不要把代碼寫得很密，這樣的可讀性非常差，HTML對回車和空格都不敏感，因此可以使用回車和空格，使代碼的格式和結構更清晰，這樣才能易於維護。很多標記一般來說要佔用一行，除了同一標記的關閉標記外，最好不出現兩個標記在同一行的情況。如：

<TABLE><TR><TD>text</TD></TR></TABLE>

應寫成：

<TABLE>
    <TR>
        <TD>text</TD>
    </TR>
</TABLE>

 

1  通常情況下，應該換行的標記有：

 <HTML></HTML>

 <BODY></BODY>

 <HEAD></HEAD>

 <FORM></FORM>

 當段落內容比較長時，<P></P>也應各佔一行

 各種列表標記

 表格的相關標記

 <BLOCKQUOTE>和</BLOCKQUOTE>

 <PRE>和</PRE>

 <CODE>和</CODE>

 

2  通常情況下，需要將開始和關閉標記放在一行的標記有：

 <B>和</B>

 <U>和</U>

 <I>和</I>

 各種標題標記，如<H1>…</H1>等

 <A>和</A>

標記的關閉規範

1、HTML文檔的正文都應在<BODY></BODY>標記中間，而<BODY>標記則應包含在<HTML>和</HTML>標記之間，如：

<HTML>
<BODY>
…………
</BODY>
</HTML>

 

2  對於需要關閉標記的標記，如<HTML>,<TITLE>, <BODY>, <TABLE>, <TR>, <TD>, <P>,<TEXTAREA>, <SELECT>, <FONT>, <OPTION>, <DIV>,<SPAN>等標記，都必須有相應的關閉標記出現，否則一方面使程序的可讀性差，更重要的是會引起頁面格式顯示混亂。正確地寫法應爲：

<BODY>
  <P>
    <FONT>……</FONT>
  </P>
</BODY>

 

3  不能出現標記交叉的情況，如：

<P><FONT>……</P></FONT>

標記的屬性值規範

對於標記中的屬性值，最好使用雙引號或單引號包圍，這樣的話不易出錯。如：

<INPUT type=text  value=Hello World! length=20>

 

本來是希望在文本框中顯示“Hello world!”，但是由於沒有加上引號，則只會在文本框中顯示“Hello”，因此，正確地寫法爲：

<INPUT type="text" value="Hello World!"  length="20">

標記的縮進規範

1 最高一級的父標記採用左對齊頂格方式書寫。

2 下一級標記採用左對齊後，縮進2個空格的方式書寫。再下一級則以此類推。

3 同一級標記的首字符上下應對齊。

例如：

<P>
<TABLE>
    <TR>
        <TD> … … … </TD>
        <TD> … … … </TD>
    </TR>
    <TR>
        <TD>
            <TABLE>
              … … … 
            </TABLE>
        </TD>
        <TD> … … </TD>
    </TR>
</TABLE>

註釋

在任何代碼中都應該有做註釋的好習慣，在一個複雜的HTML代碼中，友好的註釋是非常有用的，特別是在有很多嵌套的表格中，和模板中套入的內容管理標籤等，都要用註釋來進行描述，以便其他人對模板進行操作時清楚的知道各標籤的內容。HTML中使用<!--…… -->來做註釋。如：

<TABLE>
    <TR>   <!-- ROW 1-->
        <TD>      <!-- COL 1-->
         …… ……
        </TD>
        <TD>      <!-- COL 2-->
         …… ……
        </TD>
    </TR>
    <TR>   <!-- ROW 2-->
        <TD>      <!-- COL 1-->
         …… ……
        </TD>
        <TD>      <!-- COL 2-->
         …… ……
        </TD>
    </TR>
</TABLE>

代碼嵌套、優化

儘量減少HTTP請求次數

　　終端用戶響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。通過減少頁面中的元素可以減少HTTP請求的次數。這是提高網頁速度的關鍵步驟。

　　減少頁面組件的方法其實就是簡化頁面設計。那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這裏有幾條減少HTTP請求次數同時又可能保持頁面內容豐富的技術。

　　合併文件是通過把所有的腳本放到一個文件中來減少HTTP請求的方法，如可以簡單地把所有的CSS文件都放入一個樣式表中。當腳本或者樣式表在不同頁面中使用時需要做不同的修改，這可能會相對麻煩點，但即便如此也要把這個方法作爲改善頁面性能的重要一步。

　　CSS Sprites是減少圖像請求的有效方法。把所有的背景圖像都放到一個圖片文件中，然後通過CSS的background-image和background-position屬性來顯示圖片的不同部分；

　　圖片地圖是把多張圖片整合到一張圖片中。雖然文件的總體大小不會改變，但是可以減少HTTP請求次數。圖片地圖只有在圖片的所有組成部分在頁面中是緊挨在一起的時候才能使用，如導航欄。確定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具有可讀性，因此不推薦這種方法；

　　內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中。這可能會增加頁面的大小。把內聯圖像放到樣式表（可緩存）中可以減少HTTP請求同時又避免增加頁面文件的大小。但是內聯圖像現在還沒有得到主流瀏覽器的支持。

　　減少頁面的HTTP請求次數是你首先要做的一步。這是改進首次訪問用戶等待時間的最重要的方法。如同Tenni Theurer的他的博客BrowserCahe Usage - Exposed!中所說，HTTP請求在無緩存情況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人獲得更加快速的體驗吧！

減少DNS查找次數

　　域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係一樣。當你在瀏覽器地址欄中輸入http://www.dudo.org/時，DNS解析服務器就會返回這個域名對應的IP地址。DNS解析的過程同樣也是需要時間的。一般情況下返回給定域名對應的IP地址會花費20到120毫秒的時間。而且在這個過程中瀏覽器什麼都不會做直到DNS查找完畢。

　　緩存DNS查找可以改善頁面性能。這種緩存需要一個特定的緩存服務器，這種服務器一般屬於用戶的ISP提供商或者本地局域網控制，但是它同樣會在用戶使用的計算機上產生緩存。DNS信息會保留在操作系統的DNS緩存中（微軟Windows系統中DNS ClientService）。大多數瀏覽器有獨立於操作系統以外的自己的緩存。由於瀏覽器有自己的緩存記錄，因此在一次請求中它不會受到操作系統的影響。

　　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 MovedPermanently

　　Location:http://example.com/newuri

　　Content-Type:text/html

　　瀏覽器會把用戶指向到Location中指定的URL。頭文件中的所有信息在一次跳轉中都是必需的，內容部分可以爲空。不管他們的名稱，301和302響應都不會被緩存除非增加一個額外的頭選項，如Expires或者Cache-Control來指定它緩存。<meat />元素的刷新標籤和Javascrīpt也可以實現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經常被提及的一個好處就是由於其從後臺服務器傳輸信息的異步性而爲用戶帶來的反饋的即時性。但是，使用Ajax並不能保證用戶不會在等待異步的Javascrīpt和XML響應上花費時間。在很多應用中，用戶是否需要等待響應取決於Ajax如何來使用。例如，在一個基於Web的Email客戶端中，用戶必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，“異步”並不異味着“即時”，這很重要。

　　爲了提高性能，優化Ajax響應是很重要的。提高Ajxa性能的措施中最重要的方法就是使響應具有可緩存性，具體的討論可以查看Add an Expires or a Cache-Control Header。其它的幾條規則也同樣適用於Ajax：

　　Gizp壓縮文件

　　減少DNS查找次數

　　精簡Javascrīpt

　　避免跳轉

　　配置ETags

　　讓我們來看一個例子：一個Web2.0的Email客戶端會使用Ajax來自動完成對用戶地址薄的下載。如果用戶在上次使用過Email web應用程序後沒有對地址薄作任何的修改，而且Ajax響應通過Expire或者Cacke-Control頭來實現緩存，那麼就可以直接從上一次的緩存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄還是發送一個新的請求。這可以通過爲讀取地址薄的Ajax URL增加一個含有上次編輯時間的時間戳來實現，例如，&t=11900241612等。如果地址薄在上次下載後沒有被編輯過，時間戳就不變，則從瀏覽器的緩存中加載從而減少了一次HTTP請求過程。如果用戶修改過地址薄，時間戳就會用來確定新的URL和緩存響應並不匹配，瀏覽器就會重要請求更新地址薄。

　　即使你的Ajxa響應是動態生成的，哪怕它只適用於一個用戶，那麼它也應該被緩存起來。這樣做可以使你的Web2.0應用程序更加快捷。

推遲加載內容

　　你可以仔細看一下你的網頁，問問自己“哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構可以稍後再加載？

　　把整個過程按照onload事件分隔成兩部分，Javascrīpt是一個理想的選擇。例如，如果你有用於實現拖放和動畫的Javascrīpt，那麼它就以等待稍後加載，因爲頁面上的拖放元素是在初始化呈現之後才發生的。其它的例如隱藏部分的內容（用戶操作之後才顯現的內容）和處於摺疊部分的圖像也可以推遲加載

　　工具可以節省你的工作量：YUI ImageLoader可以幫你推遲加載摺疊部分的圖片，YUI Getutility是包含JS和 CSS的便捷方法。比如你可以打開Firebug的Net選項卡看一下Yahoo的首頁。

　　當性能目標和其它網站開發實踐一致時就會相得益彰。這種情況下，通過程序提高網站性能的方法告訴我們，在支持Javascrīpt的情況下，可以先去除用戶體驗，不過這要保證你的網站在沒有Javascrīpt也可以正常運行。在確定頁面運行正常後，再加載腳本來實現如拖放和動畫等更加花哨的效果。

預加載

　　預加載和後加載看起來似乎恰恰相反，但實際上預加載是爲了實現另外一種目標。預加載是在瀏覽器空閒時請求將來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，因此可以大大改善訪問速度。

　　下面提供了幾種預加載方法：

　　無條件加載：觸發onload事件時，直接加載額外的頁面內容。以Google.com爲例，你可以看一下它的spiritimage圖像是怎樣在onload中加載的。這個spirit image圖像在google.com主頁中是不需要的，但是卻可以在搜索結果頁面中用到它。

　　有條件加載：根據用戶的操作來有根據地判斷用戶下面可能去往的頁面並相應的預加載頁面內容。在search.yahoo.com中你可以看到如何在你輸入內容時加載額外的頁面內容。

　　有預期的加載：載入重新設計過的頁面時使用預加載。這種情況經常出現在頁面經過重新設計後用戶抱怨“新的頁面看起來很酷，但是卻比以前慢”。問題可能出在用戶對於你的舊站點建立了完整的緩存，而對於新站點卻沒有任何緩存內容。因此你可以在訪問新站之前就加載一部內容來避免這種結果的出現。在你的舊站中利用瀏覽器的空餘時間加載新站中用到的圖像的和腳本來提高訪問速度。

減少DOM元素數量

　　一個複雜的頁面意味着需要下載更多數據，同時也意味着Javascrīpt遍歷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內容和動態內容放在[url]www.example.org[/url]上，而把頁面各種組件（圖片、腳本、CSS)分別存放在statics1.example.org和statics.example.org上。

　　你可在Tenni Theurer和Patty Chi合寫的文章MaximizingParallel Downloads in the Carpool Lane找到更多相關信息。

 

使iframe的數量最小

 　　ifrmae元素可以在父文檔中插入一個新的HTML文檔。瞭解iframe的工作理然後才能更加有效地使用它，這一點很重要。

　　<iframe>優點：

　　解決加載緩慢的第三方內容如圖標和廣告等的加載問題

　　Security sandbox

　　並行加載腳本

　　<iframe>的缺點：

　　即時內容爲空，加載也需要時間

　　會阻止頁面加載

　　沒有語意

不要出現404錯誤

　　HTTP請求時間消耗是很大的，因此使用HTTP請求來獲得一個沒有用處的響應（例如404沒有找到頁面）是完全沒有必要的，它只會降低用戶體驗而不會有一點好處。

　　有些站點把404錯誤響應頁面改爲“你是不是要找***”，這雖然改進了用戶體驗但是同樣也會浪費服務器資源（如數據庫等）。最糟糕的情況是指向外部Javascrīpt的鏈接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當作Javascrīpt代碼來執行。

　　在本系列的第一節中，講了提高網站性能中網站“內容”有關的10條原則。除了在網站在內容上的改進外，在網站服務器端上也有需要注意和改進的地方，它們包括：

　　使用內容分發網絡

　　爲文件頭指定Expires或Cache-Control

　　Gzip壓縮文件內容

　　配置ETag

　　儘早刷新輸出緩衝

　　使用GET來完成AJAX請求

爲文件頭指定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 Apr2010 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文件頭，增加了緩存在瀏覽器中內容的數量，並且可以在用戶接下來的請求中再次使用這些內容，這甚至都不需要通過用戶發送一個字節的請求。

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壓縮所有可能的文件類型是減少文件體積增加用戶體驗的簡單方法。

配置ETag

　　Entity tags（ETags）（實體標籤）是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制（“實體”就是所說的“內容”，包括圖片、腳本、樣式表等）。增加ETag爲實體的驗證提供了一個比使用“last-modifieddate（上次編輯時間）”更加靈活的機制。Etag是一個識別內容版本號的唯一字符串。唯一的格式限制就是它必須包含在雙引號內。原始服務器通過含有ETag文件頭的響應指定頁面內容的ETag。

　　HTTP/1.1 200 OK

　　Last-Modified: Tue, 12Dec 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 NotModified

　　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和Javascrīpt文件，這樣瀏覽器就可以在後臺編譯剩餘HTML的同時並行下載它們。例子：

　　... <!-- css, js-->

　　</head>

　　<?php flush();?>

　　<body>

　　... <!-- content-->

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

使用GET來完成AJAX請求

　　Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然後才發送數據。因此使用GET最爲恰當，因爲它只需發送一個TCP包（除非你有很多cookie）。IE中URL的最大長度爲2K，因此如果你要發送一個超過2K的數據時就不能使用GET了。

　　一個有趣的不同就是POST並不像GET那樣實際發送數據。根據HTTP規範，GET意味着“獲取”數據，因此當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端保存數據時使用POST。

　　在第一部分和第二部分中我們分別介紹了改善網站性能中頁面內容和服務器的幾條守則，除此之外，Javascrīpt和CSS也是我們頁面中經常用到的內容，對它們的優化也提高網站性能的重要方面：

　　CSS：

　　把樣式表置於頂部

　　避免使用CSS表達式（Expression）

　　使用外部Javascrīpt和CSS

　　削減Javascrīpt和CSS

　　避免使用濾鏡

　　Javascrīpt

　　把腳本置於頁面底部

　　使用外部Javascrīpt和CSS

　　削減Javascrīpt和CSS

　　剔除重複腳本

　　減少DOM訪問

　　開發智能事件處理程序

把樣式表置於頂部

　　在研究Yahoo!的性能表現時，我們發現把樣式表放到文檔的<head />內部似乎會加快頁面的下載速度。這是因爲把樣式表放到<head />內會使頁面有步驟的加載顯示。

　　注重性能的前端服務器往往希望頁面有秩序地加載。同時，我們也希望瀏覽器把已經接收到內容儘可能顯示出來。這對於擁有較多內容的頁面和網速較慢的用戶來說特別重要。向用戶返回可視化的反饋，比如進程指針，已經有了較好的研究並形成了正式文檔。在我們的研究中HTML頁面就是進程指針。當瀏覽器有序地加載文件頭、導航欄、頂部的logo等對於等待頁面加載的用戶來說都可以作爲可視化的反饋。這從整體上改善了用戶體驗。

　　把樣式表放在文檔底部的問題是在包括InternetExplorer在內的很多瀏覽器中這會中止內容的有序呈現。瀏覽器中止呈現是爲了避免樣式改變引起的頁面元素重繪。用戶不得不面對一個空白頁面。

　　HTML規範清楚指出樣式表要放包含在頁面的<head />區域內：“和<a/>不同，<link />只能出現在文檔的<head />區域內，儘管它可以多次使用它”。無論是引起白屏還是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文檔<head />內加載你的樣式表。

 

避免使用CSS表達式（Expression）

　　CSS表達式是動態設置CSS屬性的強大（但危險）方法。InternetExplorer從第5個版本開始支持CSS表達式。下面的例子中，使用CSS表達式可以實現隔一個小時切換一次背景顏色：

　　background-color:expression( (new Date()).getHours()%2 ? "#B8D4FF" :"#F08A00" );

　　如上所示，expression中使用了Javascrīpt表達式。CSS屬性根據Javascrīpt表達式的計算結果來設置。expression方法在其它瀏覽器中不起作用，因此在跨瀏覽器的設計中單獨針對Internet Explorer設置時會比較有用。

　　表達式的問題就在於它的計算頻率要比我們想象的多。不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標時都會要重新計算一次。給CSS表達式增加一個計數器可以跟蹤表達式的計算頻率。在頁面中隨便移動鼠標都可以輕鬆達到10000次以上的計算量。

　　一個減少CSS表達式計算次數的方法就是使用一次性的表達式，它在第一次運行時將結果賦給指定的樣式屬性，並用這個屬性來代替CSS表達式。如果樣式屬性必須在頁面週期內動態地改變，使用事件句柄來代替CSS表達式是一個可行辦法。如果必須使用CSS表達式，一定要記住它們要計算成千上萬次並且可能會對你頁面的性能產生影響。

使用外部Javascript和CSS

　　很多性能規則都是關於如何處理外部文件的。但是，在你採取這些措施前你可能會問到一個更基本的問題：Javascrīpt和CSS是應該放在外部文件中呢還是把它們放在頁面本身之內呢？

　　在實際應用中使用外部文件可以提高頁面速度，因爲Javascrīpt和CSS文件都能在瀏覽器中產生緩存。內置在HTML文檔中的Javascrīpt和CSS則會在每次請求中隨HTML文檔重新下載。這雖然減少了HTTP請求的次數，卻增加了HTML文檔的大小。從另一方面來說，如果外部文件中的Javascrīpt和CSS被瀏覽器緩存，在沒有增加HTTP請求次數的同時可以減少HTML文檔的大小。

　　關鍵問題是，外部Javascrīpt和CSS文件緩存的頻率和請求HTML文檔的次數有關。雖然有一定的難度，但是仍然有一些指標可以一測量它。如果一個會話中用戶會瀏覽你網站中的多個頁面，並且這些頁面中會重複使用相同的腳本和樣式表，緩存外部文件就會帶來更大的益處。

　　許多網站沒有功能建立這些指標。對於這些網站來說，最好的堅決方法就是把Javascrīpt和CSS作爲外部文件引用。比較適合使用內置代碼的例外就是網站的主頁，如Yahoo!主頁和My Yahoo!。主頁在一次會話中擁有較少（可能只有一次）的瀏覽量，你可以發現內置Javascrīpt和CSS對於終端用戶來說會加快響應時 間。

　　對於擁有較大瀏覽量的首頁來說，有一種技術可以平衡內置代碼帶來的HTTP請求減少與通過使用外部文件進行緩存帶來的好處。其中一個就是在首頁中內置Javascrīpt和CSS，但是在頁面下載完成後動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。

削減Javascript和CSS

　　精簡是指從去除代碼不必要的字符減少文件大小從而節省下載時間。消減代碼時，所有的註釋、不需要的空白字符（空格、換行、tab縮進）等都要去掉。在Javascrīpt中，由於需要下載的文件體積變小了從而節省了響應時間。精簡Javascrīpt中目前用到的最廣泛的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用於精簡CSS。

　　混淆是另外一種可用於源代碼優化的方法。這種方法要比精簡複雜一些並且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也可以縮小原來代碼體積的21%，而混淆可以達到25%。儘管混淆法可以更好地縮減代碼，但是對於Javascrīpt來說精簡的風險更小。

　　除消減外部的腳本和樣式表文件外，<scrīpt>和<style>代碼塊也可以並且應該進行消減。即使你用Gzip壓縮過腳本和樣式表，精簡這些文件仍然可以節省5%以上的空間。由於Javascrīpt和CSS的功能和體積的增加，消減代碼將會獲得益處。

用<link>代替@import

　　前面的最佳實現中提到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中，腳本可能會被延遲但效果也不會像我們所期望的那樣。如果腳本可以被延遲，那麼它就可以移到頁面的底部。這會讓你的頁面加載的快一點。

剔除重複腳本

　　在同一個頁面中重複引用Javascrīpt文件會影響頁面的性能。你可能會認爲這種情況並不多見。對於美國前10大網站的調查顯示其中有兩家存在重複引用腳本的情況。有兩種主要因素導致一個腳本被重複引用的奇怪現象發生：團隊規模和腳本數量。如果真的存在這種情況，重複腳本會引起不必要的HTTP請求和無用的Javascrīpt運算，這降低了網站性能。

　　在Internet Explorer中會產生不必要的HTTP請求，而在Firefox卻不會。在Internet Explorer中，如果一個腳本被引用兩次而且它又不可緩存，它就會在頁面加載過程中產生兩次HTTP請求。即時腳本可以緩存，當用戶重載頁面時也會產生額外的HTTP請求。

　　除增加額外的HTTP請求外，多次運算腳本也會浪費時間。在Internet Explorer和Firefox中不管腳本是否可緩存，它們都存在重複運算Javascrīpt的問題。

　　一個避免偶爾發生的兩次引用同一腳本的方法是在模板中使用腳本管理模塊引用腳本。在HTML頁面中使用<scrīpt />標籤引用腳本的最常見方法就是：

　　<scrīpt type="text/javascrīpt" src="menu_1.0.17.js"></scrīpt>

　　在PHP中可以通過創建名爲insertscrīpt的方法來替代：

　　<?php insertscrīpt("menu.js") ?>

　　爲了防止多次重複引用腳本，這個方法中還應該使用其它機制來處理腳本，如檢查所屬目錄和爲腳本文件名中增加版本號以用於Expire文件頭等。

減少DOM訪問

　　使用Javascrīpt訪問DOM元素比較慢，因此爲了獲得更多的應該頁面，應該做到：

　　緩存已經訪問過的有關元素

　　線下更新完節點之後再將它們添加到文檔樹中

　　避免使用Javascrīpt來修改頁面佈局

　　有關此方面的更多信息請查看JulienLecomte在YUI專題中的文章“高性能Ajax應該程序”。

開發智能事件處理程序

　　有時候我們會感覺到頁面反應遲鈍，這是因爲DOM樹元素中附加了過多的事件句柄並且些事件句病被頻繁地觸發。這就是爲什麼說使用event delegation（事件代理）是一種好方法了。如果你在一個div中有10個按鈕，你只需要在div上附加一次事件句柄就可以了，而不用去爲每一個按鈕增加一個句柄。事件冒泡時你可以捕捉到事件並判斷出是哪個事件發出的。

　　你同樣也不用爲了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有圖像都加載完畢。

　　你可能會希望用DOMContentLoaded事件來代替onload，但是在所有瀏覽器都支持它之前你可使用YUI 事件應用程序中的onAvailable方法。

　　有關此方面的更多信息請查看JulienLecomte在YUI專題中的文章“高性能Ajax應該程序”。

　　我們在前面的幾節中分別講了提高網站性能中內容、服務器、Javascrīpt和CSS等方面的內容。除此之外，圖片和Coockie也是我們網站中幾乎不可缺少組成部分，此外隨着移動設備的流行，對於移動應用的優化也十分重要。這主要包括：

　　Coockie:

　　減小Cookie體積

　　對於頁面內容使用無coockie域名

　　圖片：

　　優化圖像

　　優化CSS Spirite

　　不要在HTML中縮放圖像

　　favicon.ico要小而且可緩存

　　移動應用：

　　保持單個內容小於25K

　　打包組件成複合文本

減小Cookie體積

　　HTTP coockie可以用於權限驗證和個性化身份等多種用途。coockie內的有關信息是通過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。因此保持coockie儘可能的小以減少用戶的響應時間十分重要。

　　有關更多信息可以查看TenniTheurer和Patty Chi的文章“When the Cookie Crumbles”。這們研究中主要包括：

　　去除不必要的coockie

　　使coockie體積儘量小以減少對用戶響應的影響

　　注意在適應級別的域名上設置coockie以便使子域名不受影響

　　設置合理的過期時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。

對於頁面內容使用無coockie域名

　　當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對於這些coockie不會做任何地使用。因此他們只是因爲某些負面因素而創建的網絡傳輸。所有你應該確定對於靜態內容的請求是無coockie的請求。創建一個子域名並用他來存放所有靜態內容。

　　如果你的域名是[url]www.example.org[/url]，你可以在static.example.org上存在靜態內容。但是，如果你不是在[url]www.example.org[/url]上而是在頂級域名example.org設置了coockie，那麼所有對於static.example.org的請求都包含coockie。在這種情況下，你可以再重新購買一個新的域名來存在靜態內容，並且要保持這個域名是無coockie的。Yahoo!使用的是ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。

　　使用無coockie域名存在靜態內容的另外一個好處就是一些代理（服務器）可能會拒絕對coockie的內容請求進行緩存。一個相關的建議就是，如果你想確定應該使用example.org還是[url]www.example.org[/url]作爲你的一主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到*.example.org（*是泛域名解析，代表了所有子域名譯者dudo注）外沒有其它選擇，因此出於性能方面的考慮最好是使用帶有www的子域名並且在它上面設置coockie。

優化圖像

　　設計人員完成對頁面的設計之後，不要急於將它們上傳到web服務器，這裏還需要做幾件事：

　　你可以檢查一下你的GIF圖片中圖像顏色的數量是否和調色板規格一致。使用imagemagick中下面的命令行很容易檢查：

　　identify -verboseimage.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

優化CSS Spirite

　　在Spirite中水平排列你的圖片，垂直排列會稍稍增加文件大小；

　　Spirite中把顏色較近的組合在一起可以降低顏色數，理想狀況是低於256色以便適用PNG8格式；

　　便於移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增加文件大小但對於用戶代理來說它需要更少的內存來把圖片解壓爲像素地圖。100x100的圖片爲1萬像素，而1000x1000就是100萬像素。

不要在HTML中縮放圖像

　　不要爲了在HTML中設置長寬而使用比實際需要大的圖片。如果你需要：

　　<imgwidth="100" height="100" src="mycat.jpg"alt="My Cat" />

　　那麼你的圖片（mycat.jpg）就應該是100x100像素而不是把一個500x500像素的圖片縮小使用。

favicon.ico要小而且可緩存

　　favicon.ico是位於服務器根目錄下的一個圖片文件。它是必定存在的，因爲即使你不關心它是否有用，瀏覽器也會對它發出請求，因此最好不要返回一個404 Not Found的響應。由於是在同一臺服務器上，它每被請求一次coockie就會被髮送一次。這個圖片文件還會影響下載順序，例如在IE中當你在onload中請求額外的文件時，favicon會在這些額外內容被加載前下載。

　　因此，爲了減少favicon.ico帶來的弊端，要做到：

　　文件儘量地小，最好小於1K

　　在適當的時候（也就是你不要打算再換favicon.ico的時候，因爲更換新文件時不能對它進行重命名）爲它設置Expires文件頭。你可以很安全地把Expires文件頭設置爲未來的幾個月。你可以通過覈對當前favicon.ico的上次編輯時間來作出判斷。

　　Imagemagick可以幫你創建小巧的favicon。

保持單個內容小於25K

　　這條限制主要是因爲iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。由於單純gizp壓縮可能達不要求，因此精簡文件就顯得十分重要。

　　查看更多信息，請參閱Wayne Shea和Tenni Theurer的文件“PerformanceResearch, Part 5: iPhone Cacheability - Making it Stick”。

部署

1、SVN文件不要部署到服務器上

2、將classes目錄中的內容壓縮成Jar包部署到服務器上，正式的網站classes目錄下爲空

測試

　　在基於Web的系統開發中，如果缺乏嚴格的過程，我們在開發、發佈、實施和維護Web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨着基於Web的系統變得越來越複雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對Web和Internet的信心可能會無法挽救地動搖，從而引起Web危機。並且，Web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加廣泛。

　　在Web工程過程中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此，我們必須爲測試和評估複雜的基於Web的系統研究新的方法和技術。

　　一般軟件的發佈週期以月或以年計算，而Web應用的發佈週期以天計算甚至以小時計算。Web測試人員必須處理更短的發佈週期，測試人員和測試管理人員面臨着從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。

界面測試

界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到嚮導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕鬆愉悅的感受和成功的感覺，相反由於界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。目前界面的設計引起軟件設計人員的重視的程度還遠遠不夠，直到最近網頁製作的興起，才受到專家的青睞。而且設計良好的界面由於需要具有藝術美的天賦而遭拒絕。
　　目前流行的界面風格有三種方式：多窗體、單窗體以及資源管理器風格，無論那種風格，以下規則是應該被重視的。

1．應驗證界面顯示內容的完整性：

a) 報表顯示時應考慮數據顯示寬度的自適應或自動換行。

b) 所有有數據展現的界面（如統計、查詢、編輯錄入、打印預覽、打印等），必須使測試數據的記錄數超過一屏/一頁，以驗證滿屏/頁時其窗體是否有橫向、縱向滾動條或換頁打印，界面顯示是否正常；

2．應驗證界面顯示內容的一致性：

a) 如有多個系統展現同一數據源時，應保證其一致性；

3．應驗證界面顯示內容的準確性：

a) 對於報表中的所有字段值都應該有明確的定義，對於無意義的字段值，不應該顯示空，應顯示“--”或“/”，表示該字段值無意義。

4．應驗證界面顯示內容的友好性：

a) 對統計的數據應按用戶習慣進行分類、排序。

b) 某些重要信息在輸入、修改、刪除時應有“確認”提示信息；

c) 界面內容更新後系統應提供刷新功能。

d) 用戶在退出系統後重新登陸時應考慮是否需要自動返回到上次退出系統時的界面；

5．應驗證界面提示信息的指導性：

a) 在多個業務功能組成的一個業務流程中，如果各個功能之間的執行順序有一定的制約條件，應通過界面提示用戶。

b) 用戶提示信息應具有一定的指導性，在應用程序正在進行關鍵業務的處理時，應考慮在前臺界面提示用戶應用程序正在進行的處理，以及相應的處理過程，在處理結束後再提示用戶處理完畢。

c) 在某些數據輸入界面，如果要求輸入的數據符合某項規則，應在輸入界面提供相應的規則描述；當輸入數據不符合規則時應提示用戶是否繼續。

d) 在對任何配置信息修改後，都應該在用戶退出該界面時提示用戶保存（如果用戶沒有主動保存的情況下）；

6．應驗證界面顯示內容的合理性：

a) 在對某些查詢功能進行測試時，應考慮查詢條件的設置的合理性以及查詢結果的互補性。如某些後臺處理時間不應該作爲查詢條件。

b) 界面測試時，應考慮某一界面上按鈕先後使用的順序問題，以免用戶對此產生迷惑。例如只能在查詢成功後顯示執行按鈕。

c) 界面測試時，應驗證窗口與窗口之間、字段與字段之間的瀏覽順序是否正確；

7．界面測試時，應考慮用戶使用的方便性：

a) 在某些對數據進行處理的操作界面，應考慮用戶可能對數據進行處理的頻繁程度和工作量，考慮是否可以進行批量操作。

8．界面測試時，應考慮界面顯示及處理的正確性：

a) 界面測試時應驗證所有窗體中的對象狀態是否正常，是否符合相關的業務規則需要。

b) 應驗證各種對象訪問方法（Tab 健、鼠標移動和快捷鍵）是否可正常使用，並且在一個激活界面中快捷鍵無重複；

c) 界面測試不光要考慮合理的鍵盤輸入，還應考慮是否可以通過鼠標拷貝粘貼輸入。

d) 對於統計查詢功能的查詢結果應驗證其是否只能通過界面上的查詢或刷新按鍵人工觸發，應避免其他形式的觸發。

e) 對界面上的任何對象進行拖拉，然後進行查詢、打印，應保證查詢打印結果不變；

9．界面測試時，應考慮數據顯示的規範性：

a) 確保數據精度顯示的統一：如單價0元，應顯示爲0.00元；

b) 確保時間及日期顯示格式的統一；

c) 確保相同含義屬性/字段名的統一；

d) 對所有可能產生的提示信息界面內容和位置進行驗證，確保所有的提示信息界面應居中。

功能測試

　　1、鏈接測試

　　鏈接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分爲三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。

　　鏈接測試可以自動進行，現在已經有許多工具可以採用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行鏈接測試。

　　2、表單測試

　　當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶註冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。

　　3、Cookies測試

　　Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。

　　如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什麼影響等。

性能測試

　　1、連接速度測試

　　用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。

　　另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。

　　2、負載測試

　　負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量用戶對同一個頁面的請求？

　　3、壓力測試

　　負載測試應該安排在Web系統發佈以後，在實際的網絡環境中進行測試。因爲一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果纔是正確可信的。

　　進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統重新啓動時獲得存取權。

　　壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。

可用性測試

　　1、導航測試

　　導航描述了用戶在一個頁面內操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜索引擎或其他的導航幫助？

　　在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。

　　導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。

　　Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。

　　2、圖形測試

　　在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：

　　（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。

　　（2）驗證所有頁面字體的風格是否一致。

　　（3）背景顏色應該與字體顏色和前景顏色相搭配。

　　（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮。

　　3、內容測試

　　內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。

　　信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；信息的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂"相關文章列表"。

　　4、整體界面測試

　　整體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？

對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般Web應用系統採取在主頁上做一個調查問卷的形式，來得到最終用戶的反饋信息。

　　對所有的可用性測試來說，都需要有外部人員（與Web應用系統開發沒有聯繫或聯繫很少的人員）的參與，最好是最終用戶的參與。

客戶端兼容性測試

　　1、平臺測試

　　市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。

　　因此，在Web系統發佈之前，需要在各種操作系統下對Web系統進行兼容性測試。

　　2、瀏覽器測試

　　瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、ActiveX、plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是爲InternetExplorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。

         測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。要求兼容的瀏覽器至少包含：IE7及以上、safari、谷歌瀏覽器、火狐瀏覽器、360瀏覽器、遨遊瀏覽器、騰訊瀏覽器以及搜狗瀏覽器。

3、移動端瀏覽器測試

　　移動端瀏覽器是是手機訪問的關鍵，由於目前手機品牌衆多，需要支持佔有率佔前十的手機進行適配測試。除了iphone外，android需要適配機型爲：三星 GALAXY S5、三星 GALAXY Note3、三星 GALAXY S4、魅族 MX3、華爲 榮耀3C、酷派 大神F1、諾基亞 X、華爲榮耀暢玩版、HTC One M8t、華碩 ZenFone 5、小米紅米NOTE、諾基亞Lumia 1520、vivo X3。

 

安全性測試

　　Web應用系統的安全性測試區域主要有：

　　（1）現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。

　　（2）Web應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。

　　（3）爲了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。

　　（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

　　（5）服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。

　　網頁加載速度測試可以採用HttpWatch軟件等，可以知道那些內容影響網站整體速度。

上線

要求有網站壓力測試報告、網站功能測試報告