大型網站：前端性能優化和規范
Web性能涉及的范圍太廣，但一般web開發者在程序上線以后很多都曾遇到過性能的問題。普遍表現為頁面速度開始急劇變慢，正常訪問時間變的很長，或則干脆給你拋出異常錯誤頁面。這里會涉及到很多可能發生的情況，舉例幾個最主要發生的情況：
* 數據庫死鎖
* Web Server 超過最大連接數（一般在虛擬主機上才會限制）
* 內存泄漏
* Http連接數太多，即訪問量超過了機器和軟件設計正常所能提供的服務
而今天分享的主要是比較偏向前端
瀏覽器請求和響應的過程
第一步、瀏覽器預處理
查詢Cache：讀取Cache 或者發送304請求
第二步、查詢DNS
優化規則--減少DNS查找
DNS緩存
瀏覽器DNS緩存 計算機DNS緩存 服務器DNS緩存（TTL）
使用Keep-Alive特性
減少DNS查找
當客戶端的DNS緩存為空時，DNS查找的數量與Web頁面中唯一主機名的數量相等。減少唯一主機名的數量就可以減少DNS查找的數量。
較少的域名來減少DNS查找（2-4個主機）
第三步、建立連接
優化規則-- 使用內容分發網絡
美國十大Internet網站和CDN服務提供商
頁面靜態化,取決于發布系統
Ctrip使用的China-Cache和網宿
優化規則--用域名劃分頁面內容
按頁面內容劃分域名，在合適的資源服務器上存放文件
第四步、發送請求
優化規則-- 減少HTTP請求
HTTP請求30-40,合并文件,圖片地圖,內聯圖像
a)js文件（不超過7個）
不含ga.js、uiscript.asp和外鏈其他網站的js
b) css文件不超過4個，各頻道首頁和全站首頁不超過3個。
c) 目前無法解決的是allyes廣告的請求數。
這個只能從設計上搞定，需要權衡
優化規則- – 優化CSS Spirite
圖片地圖 Ctrip首頁例子
優化規則– 避免404錯誤
規則優化 –不要使用frameset，少使用iframe
即時內容為空，加載也需要時間、會阻止頁面加載
第五步、等待響應
優化規則 --避免重定向
第七步、接收數據
優化規則 -- 壓縮組件
HTML文檔、腳本和樣式表、XML和JSON的文本響應 壓縮如何工作
壓縮通常能將響應的數據量減少將近70%
優化規則 -- 精簡Javascript和Css
從代碼中移除不必要的字符以減少其大小，減少加載時間。
規則規則– 盡量縮減頁面大小
頁面必須小于150K(不含圖片）
a) 靜態文件是否gzip
b) 圖片是否壓縮優化過
第八步、讀取Cache
優化規則-- 添加Expire或Cache-Control
應用于不經常變化的組件，包括腳本、樣式表、Flash組件、圖片
Expires和Cache-Control
規則規則 -- 使用外部的Js和Css文件
盡可能使用外部Js和Css，因為我們目前大部分Js和Css都做了Gzip和緩存技術，可以充分利用。
第九步、處理元素
不要對image和pdf等二進制文件進行gzip壓縮
第十步、渲染元素
優化規則 -- 將樣式表放在頂部
界面原型頁面必須將樣式表置于頁面頂部，開發人員如無特殊原因也必須將樣式表置于頂部。
以往多數是因為masterpage原因無法將所有樣式表置頂，在改版修改masterpage時，盡可能按照此原則進行設計。
優化規則 – 建議將腳本放在底部
一般瀏覽器可以允許并行下載，取決于主機個數、帶寬等
（默認情況下，IE是2個而FF是8個）
下載腳本時并行下載實際上是被禁用的。
優化規則-- 移除重復腳本
必須為0
優化規則 -- 避免CSS表達式
影響瀏覽器渲染時間
優化規則 – 優化圖像
盡量使用GIF和PNG
盡量使用png/gif格式的圖片，png的圖片優先，但是必須注意如要兼容IE6，則png使用一定要注意透明問題。
圖片在上次前一定要先用工具壓縮優化（png、jpg）
Javascript開發規范
大型的項目在前端 JS 方面有幾個需要達成的目標：
- 代碼邏輯分層
- 避免全局變量
- 便于多人協作開發
- 各部分代碼模塊化，可以按需加載
- 保持全局變量的清潔
- 可進行單元測試