前端的頁面主要包括xhtml,css,js。其實xhtml就是現實中所談到的內容，頁面的內容：文字，圖片，flash,視頻等。
而前端開發工作者可以控制的是什么呢？那就是xhtml，css，js的代碼及相應的修飾（背景）圖片。下面我就根據我自己的經驗來說說：
一、提倡前端開發工程師在書寫xhtml的時候做到結構語義化。
結構中主要包括了head和body兩個部分，但是我們經常說的是結構語義化主要是body中的標簽，但是我在這里還是簡單的說一下head，head中其實包括了一些對於我們seo很有用的一些東西，比如title,Description,Keywords,這些東西在蜘蛛抓取的時候都是有幫助的，當然，還有其他的一些，我在此就不一一說明了，比如設置緩存等一些其他的信息。
那么body中的話，包括的標簽就很多了，我覺得作為一個合格的前端開發人員你應該去熟悉他們，比如div,span,h,ul,ol,dl,p等等這類的標簽的使用。應該非常合理，還有就是注意h標簽的斷層，及h1標簽的使用，這些都是非常重要的。
同時在我們的結構中不要出現style和onclick這樣的內聯的樣式和事件。希望大家能夠注意結構與表現、行為的分離。
（PS：標簽語義化的好處：1.有利於搜索引擎；2.結構清晰的HTML在團隊合作中的作用，就不必說了吧；3.有利於盲人屏幕閱讀器。至於如何做到標簽語義化，就看個人的理解了，這方面我也覺得模糊，跟個人的習慣估計也有一定的關系，總之鄒惠斌老師是認為我的標簽不語義的。）
二、css，js文件數量及大小的優化
那么關於css、js的優化的話，一般情況下建議css和js采用外聯式。但是如果你的頁面內容比較多，設計師把整個效果做得比較花的話，恐怕css就非常多了，那么這種情況下，你一定要把你的css規划好，盡量的采用縮寫，這樣可以減少css文件的大小，那么對css做相應的規划也可以減少css的個數，減少http請求數，js同理。
（PS：減少重復性代碼，代碼重復利用，在這里顯得特別重要）
三、背景圖片數量及大小的優化
當我們將設計師的設計稿還原成靜態頁面后，除非頁面所有的修飾全是色塊，內容全是文字，沒有圖片，如果不是這樣的話，那么我們需要對圖片做優化處理。當然內容圖片我們是沒有辦法了，因為他是屬於內容部分的，一般情況是由於編輯處理，當然，我在還是有一個小小的建議，如果我們的網站中需要有內容圖片，希望編輯能夠將他們最優化以后，在進行上傳，一會兒告訴我的方法，下面我在說說，作為前端開發應該如何處理我們的修飾（背景）圖片。
由於我們的背景圖片數量比較多，這樣的話，會給服務器帶來影響，增加了http請求數，我們是否有一種好的解決辦法呢？這個答案是肯定的，如果你是一個合格的前端開發，你應該清楚，在我們的css定義背景的時候，可以通過坐標來實現對背景進行定位的，既然如此，那么我們可以將這些背景合並起來，這樣即可減少http請求數，同時，我們在背景整合的時候，也需要考慮圖片質量，同時也需要考慮圖片的大小，我在以前有寫過相應的博文。
（PS：這里建議使用PNG8格式的圖片結合css sprite，同樣的圖片，PNG8格式會相對來比GIF小）
四、內容圖片的大小的優化
其實剛才已經說了內容圖片的問題，那么我在這里呢，告訴大家一個比較簡單的方法，就是使用雅虎提供的一個工具。他就是smushit：http://www.smushit.com/
不過他這個工具我覺得對於我們需要發布的內容圖片還是比較麻煩，但是他可以進行優化，優化圖片的目的，最開始已經說了，圖片越小，我們的用戶下載速度越快，當然對企業的服務器的帶寬也可以起到節省的作用。
上面是我關於前端頁面性能的一些簡單的看法，當然web標准中提到的結構，表現，行為，我們工作說的xhtml,css,js其實他們還有很多東西，需要我們去學習，比如結構語義化他就是一個深入研究的課題，性能優化也是如此，不過只有我們不斷的去挖崛，我們才可能進步。下面對我前端開發的出品有一個簡單的建議：
1、我們做還原的頁面能夠通過http://validator.w3.org的驗證，當然css希望也能通過http://jigsaw.w3.org/css-validator/validator難證，不過有時候由於需要兼容多瀏覽器，會受到hack的影響，css不做強制要求。
2、作前端的我覺得應該知道yslow。如果不知道可以看看我以前寫的文章，你覺得你的靜態頁面應該能夠通過yslow2.0的classic（V1）級別的檢測，檢測的結果我覺得應該得到A。
3、你的背景圖片保證不超過3個以上，你的css文件不超過2個，js文件不超過3個。而且良好的遵守web標准的一些規定，css放到head中，js文件放到</body>之前或者之后。
4、當然就是希望你能夠對你的頁面進行裸體檢查。其實就是來檢驗你的結構語義化是否有效果。
裸體檢查：就是將你的css和js都去掉，查看你的html，看這些內容你是否能夠看懂。
5、檢測你的h標簽是否斷層。
（PS：就是按照h1,h2,h3,h4....，不要中間漏掉h2）
6、建議body中增加text-align:center。
7、當然還有很多，比如什么id，class的命名呀，這些東西，我覺得應該是你的團隊中應該做的事情。
（PS：這里得去好好看看clsaa選擇器的權重和優先級）
8、作為大型網站來說，首頁使用內聯式樣式表，這樣可以減少http請求數的同時，也可以防止裸奔。當然其他頁面需要使用外聯樣式表，這樣才可以方便維護。因為作為大型網站來說，他的首頁訪問量是非常的大的，所以。。
把樣式表置於頂部
把腳本置於頁面底部
避免使用 CSS 表達式（Expression）
使用外部 JavaScript 和 CSS
削減 JavaScript 和 CSS
用 <link> 代替 @import
避免使用濾鏡
剔除重復腳本
減少DOM訪問
開發智能事件處理程序
最好的方案就是按照 HTML 規范在文檔 <head /> 內加載你的樣式表。
對於擁有較大瀏覽量的首頁來說，有一種技術可以平衡內置代碼帶來的 HTTP 請求減少與通過使用外部文件進行緩存帶來的好處。其中一個就是在首頁中內置 JavaScript 和 CSS ，但是在頁面下載完成后動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。
Coockie:
減小Cookie體積
對於頁面內容使用無coockie域名
圖片：
優化圖像
優化CSS Spirite
不要在HTML中縮放圖像
favicon.ico要小而且可緩存
前端優化的目的是什?
1，從用戶角度而言，優化能夠讓頁面加載得更快、對用戶的操作響應得更及時，能夠給用戶提供更為友好的體驗。
2，從服務商角度而言，優化能夠減少頁面請求數、或者減小請求所占帶寬，能夠節省可觀的源。
第一類是頁面級別的優化
例如HTTP請求數、腳本的無阻塞加載、內聯腳本的位置優化等
1,減少HTTP請求數
? 從設計實現層面簡化頁面
? 合理設置HTTP緩存
? 資源合並與壓縮
如果可以的話，盡可能的將外部的腳本、樣式進行合並，多個合為一個。另外，CSS、Javascript、Image都可以用相應的工具進行壓縮，壓縮后往往能省下不少空間。
? CSS Sprites
合並CSS圖片，減少請求數的又一個好辦法
? Inline Images
使用data: URL scheme的方式將圖片嵌入到頁面或CSS中，如果不考慮資源管理上的問題的話，不失為一個好辦法。如果是嵌入頁面的話換來的是增大了頁面的體積，而且無法利用瀏覽器緩存。使用在CSS中的圖片則更為理想一些
? Lazy Load Image
這條策略實際上並不一定能減少HTTP請求數，但是卻能在某些條件下或者頁面剛加載時減少HTTP請求數。對於圖片而言，在頁面剛加載的時候可以只加載第一屏，當用戶繼續往后滾屏的時候才加載后續的圖片。這樣一來，假如用戶只對第一屏的內容感興趣時，那剩余的圖片請求就都節省了。有啊首頁曾經的做法是在加載的時候把第一屏之后的圖片地址緩存在Textarea標簽中，待用戶往下滾屏的時候才”惰性”加載。
2,將外部腳本置底
3,異步執行inline腳本
4, Lazy Load Javascript
5,將CSS放在HEAD中
6,異步請求Callback
7, 減少不必要的HTTP跳轉
8,避免重復的資源請求
第二類則是代碼級別的優化
例如Javascript中的DOM操作優化、CSS選擇符優化、圖片優化以及HTML結構優化等
1. Javascript
(1). DOM
DOM操作應該是腳本中最耗性能的一類操作，例如增加、修改、刪除DOM元素或者對DOM集合進行操作。如果腳本中包含了大量的DOM操作則需要注意以下幾點：
a. HTML Collection
在腳本中document.images、document.forms、getElementsByTagName()返回的都是HTMLCollection類型的集合，在平時使用的時候大多將它作為數組來使用，因為它有length屬性，也可以使用索引訪問每一個元素。不過在訪問性能上則比數組要差很多，原因是這個集合並不是一個靜態的結果，它表示的僅僅是一個特定的查詢，每次訪問該集合時都會重新執行這個查詢從而更新查詢結果。所謂的”訪問集合”包括讀取集合的length屬性、訪問集合中的元素。
因此，當你需要遍歷HTML Collection的時候，盡量將它轉為數組后再訪問，以提高性能。即使不轉換為數組，也請盡可能少的訪問它，例如在遍歷的時候可以將length屬性、成員保存到局部變量后再使用局部變量。
b. Reflow & Repaint
(2). 慎用with
with(obj){ p = 1}; 代碼塊的行為實際上是修改了代碼塊中的執行環境，將obj放在了其作用域鏈的最前端，在with代碼塊中訪問非局部變量是都是先從obj上開始查找，如果沒有再依次按作用域鏈向上查找，因此使用with相當於增加了作用域鏈長度。而每次查找作用域鏈都是要消耗時間的，過長的作用域鏈會導致查找性能下降。
因此，除非你能肯定在with代碼中只訪問obj中的屬性，否則慎用with，替代的可以使用局部變量緩存需要訪問的屬性。
(3). 避免使用eval和Function
每次 eval 或 Function 構造函數作用於字符串表示的源代碼時，腳本引擎都需要將源代碼轉換成可執行代碼。這是很消耗資源的操作 —— 通常比簡單的函數調用慢100倍以上。
eval 函數效率特別低，由於事先無法知曉傳給 eval 的字符串中的內容，eval在其上下文中解釋要處理的代碼，也就是說編譯器無法優化上下文，因此只能有瀏覽器在運行時解釋代碼。這對性能影響很大。
Function 構造函數比eval略好，因為使用此代碼不會影響周圍代碼;但其速度仍很慢。
此外，使用eval和Function也不利於Javascript壓縮工具執行壓縮。
(4). 減少作用域鏈查找
前文談到了作用域鏈查找問題，這一點在循環中是尤其需要注意的問題。如果在循環中需要訪問非本作用域下的變量時請在遍歷之前用局部變量緩存該變量，並在遍歷結束后再重寫那個變量，這一點對全局變量尤其重要，因為全局變量處於作用域鏈的最頂端，訪問時的查找次數是最多的。
(5). 數據訪問
Javascript中的數據訪問包括直接量(字符串、正則表達式)、變量、對象屬性以及數組，其中對直接量和局部變量的訪問是最快的，對對象屬性以及數組的訪問需要更大的開銷。當出現以下情況時，建議將數據放入局部變量：
a. 對任何對象屬性的訪問超過1次
b. 對任何數組成員的訪問次數超過1次
另外，還應當盡可能的減少對對象以及數組深度查找。
(6). 字符串拼接
在Javascript中使用”+”號來拼接字符串效率是比較低的，因為每次運行都會開辟新的內存並生成新的字符串變量，然后將拼接結果賦值給新變量。與之相比更為高效的做法是使用數組的join方法，即將需要拼接的字符串放在數組中最后調用其join方法得到結果。不過由於使用數組也有一定的開銷，因此當需要拼接的字符串較多的時候可以考慮用此方法。
2. CSS選擇符
在大多數人的觀念中，都覺得瀏覽器對CSS選擇符的解析式從左往右進行的,例如
| #toc A { color: #444; } |
這樣一個選擇符，如果是從右往左解析則效率會很高，因為第一個ID選擇基本上就把查找的范圍限定了，但實際上瀏覽器對選擇符的解析是從右往左進行的。如上面的選擇符，瀏覽器必須遍歷查找每一個A標簽的祖先節點，效率並不像之前想象的那樣高。根據瀏覽器的這一行為特點，在寫選擇符的時候需要注意很多事項，有人已經一一列舉了
3. HTML
對HTML本身的優化現如今也越來越多的受人關注了，詳情可以參見這篇總結性文章。
4. Image壓縮
圖片壓縮是個技術活，不過現如今這方面的工具也非常多，壓縮之后往往能帶來不錯的效果，具體的壓縮原理以及方法在《Even Faster Web Sites》第10章有很詳細的介紹，有興趣的可以去看看。