摘要：

　　一般說來Web前端指網站業務邏輯之前的部分，包括瀏覽器載入、網站檢視模型、圖片服務、CDN服務等，主要優化手段有優化瀏覽器訪問、使用反向代理、CDN加速等。

1、 減少HTTP請求

　 在瀏覽器(客戶端)和伺服器發生通訊時，就已經消耗了大量的時間，尤其是在網路情況比較糟糕的時候，這個問題尤其的突出。
　　一個正常HTTP請求的流程簡述：如在瀏覽器中輸入”www.xxxxxx.com”並按下回車，瀏覽器再與這個URL指向的伺服器建立連線，然後瀏覽器才能向伺服器傳送請求資訊，伺服器在接受到請求的資訊後再返回相應的資訊，瀏覽器接收到來自伺服器的應答資訊後，對這些資料解釋執行。
　　 HTTP協議是無狀態的應用層協議，意味著每次HTTP請求都需要建立通訊鏈路、進行資料傳輸，當我們請求的網頁檔案中有很多圖片、CSS、JS甚至音樂等資訊時，將會頻繁的與伺服器建立連線並釋放連線，這必定會造成資源的浪費

，而在服務端，每個HTTP都需要啟動獨立的執行緒去處理，這些通訊和服務的開銷都很昂貴，每個HTTP請求都會對伺服器和瀏覽器產生效能負擔。
　　 網速相同的條件下，下載一個100KB的圖片比下載兩個50KB的圖片要快。
　　 減少HTTP的主要手段是合併CSS、合併JavaScript、合併圖片。將瀏覽器一次訪問需要的JavaScript、CSS合併成一個檔案，這樣瀏覽器只需要一次請求。圖片也可以合成，多張圖片合併成一張，如果每張圖片都有不同的超連結，可通過CSS偏移響應滑鼠點選操作，構造不同的URL。

2、 使用瀏覽器快取

　 對一個網站而言，CSS、JavaScript、Logo、圖示這些靜態資原始檔更新的頻率都比較低，而這些檔案又幾乎是每次HTTP請求都需要的，如果將這些檔案快取在瀏覽器中，可以極好地改善效能

。通過設定HTTP頭中的Cache-Control和Expires屬性，可設定瀏覽器快取，快取時間可以是數天，甚至是數月。
　　在某些時候，靜態資原始檔變化需要及時應用到客戶端瀏覽器，這種情況，可以通過改變檔名實現 ，即更新JavaScript檔案並不是更新JavaScript檔案內容，而是生成現代戰爭新的JS檔案並更新HTML檔案中的引用。
　　使用瀏覽器快取策略的網站在更新靜態資源時，應採用分批次更新的方法，比如需要更新10個圖示檔案，不宜把10個檔案一次全部更新，而應該一個檔案一個檔案逐步更新，並有一定的間隔時間，以免使用者瀏覽器突然大量快取失效，集中更新快取，造成伺服器負載驟增，網路堵塞的情況。 　　

3、服務端啟用壓縮

　 在伺服器端對檔案進行壓縮，在瀏覽器對檔案解壓縮，可有效減少通訊傳輸的資料量。文字檔案的壓縮率可達80%以上，因此HTML、CSS、JavaScript檔案啟用GZip壓縮可達到較好的效果。但是壓縮對伺服器和瀏覽器產生一定的壓力，在通訊頻寬良好，而伺服器資源不足的情況下要權衡考慮。

4、 CSS放在頁面最上面、JavaScript放在頁面最下面

　 瀏覽器會在下載完全部CSS之後才對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器儘快下載CSS，HTML規範清楚指出CSS要放包含在頁面的區域內。JavaScript則相反，瀏覽器在載入JavaScript後立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此JavaScript最好放在頁面最下面，但如果頁面解析時就需要用到JavaScript，這裡放在底部就不合適了。
　　JavaScript是瀏覽器中的霸主，為什麼這麼說，因為在瀏覽器在執行JavaScript程式碼時，不能同時做其它事情，即<script>標籤每次出現都會讓頁面等待指令碼的解析和執行（不論JavaScript是內嵌的還是外鏈的），JavaScript程式碼執行完成後，才繼續渲染頁面。這個也就是JavaScript的阻塞特性。因為這個阻塞的特點，建議把JavaScript程式碼放到</body>標籤以前，這樣既能有效的防止JavaScript的阻塞，又能使得頁面的HTML結構能更快的釋放。

5、 精簡CSS和JS檔案

　 有一條非常重要的準則一直沒有提到，就是CSS和JavaScript的壓縮，直接減少下載的檔案體積。我個人經常使用的方式是使用 YUI Compressor，它的特點是：移除註釋；移除額外的空格；細微優化；識別符號替換。
　　YUI Compressor是java程式，如果你對java很熟悉的話可快速的上手使用yuicompressor.jar；如果你對java很陌生也沒關係，一樣可以使用YUI Compressor。
　　以我自己的yuicompressor-2.4.2.jar為例：
　　1.壓縮JS

java -jar yuicompressor-2.4.2.jar api.js > api.min.js

　　2.壓縮CSS

java -jar yuicompressor-2.4.2.jar style.css > style.min.css

6、減少對DOM的操作

　 對DOM操作的代價是高昂的，這在網頁應用中的通常是一個性能瓶頸，天生就慢。在《高效能JavaScript》中這麼比喻：“把DOM看成一個島嶼，把JavaScript(ECMAScript)看成另一個島嶼，兩者之間以一座收費橋連線”。所以每次訪問DOM都會教一個過橋費，而訪問的次數越多，交的費用也就越多。所以一般建議儘量減少過橋次數。
　　 修改和訪問DOM元素會造成頁面的重繪和重排，迴圈對DOM操作更是罪惡的行為。 所以請合理的使用JavaScript變數儲存內容，考慮大量DOM元素中迴圈的效能開銷，在迴圈結束時一次性寫入。減少對DOM元素的查詢和修改，查詢時可將其賦值給區域性變數。

7、正確理解Repaint和Reflow

　 Repaint 和 Reflow 也就是重繪和重排，Repaint(重繪)就是在一個元素的外觀被改變，但沒有改變佈局(寬高)的情況下發生，如改變visibility、outline、背景色等等。
　　Reflow(重排)就是DOM的變化影響到了元素的幾何屬性（寬和高），瀏覽器會重新計算元素的幾何屬性，會使渲染樹中受到影響的部分失效，瀏覽器會驗證DOM樹上的所有其它結點的visibility屬性，這也是Reflow低效的原因。如：改變窗囗大小、改變文字大小、內容的改變、瀏覽器視窗變化，style屬性的改變等等。如果Reflow的過於頻繁，CPU使用率就會噌噌的往上漲，所以前端也就有必要知道 Repaint 和 Reflow的知識。
　　上面提到通過設定style屬性改變結點樣式的話，每設定一次都會導致一次reflow，所以最好通過設定class的方式；有動畫效果的元素，它的position屬性應當設為fixed或absolute，這樣不會影響其它元素的佈局；如果功能需求上不能設定position為fixed或absolute，那麼就權衡速度的平滑性。
　　總之，因為 Reflow 有時確實不可避免，所以只能儘可能限制Reflow的影響範圍。

8、使用JSON格式進行資料交換

　 JSON是一種輕量級的資料交換格式，採用完全獨立於語言的文字格式，是理想的資料交換格式。同時，JSON是 JavaScript原生格式，這意味著在 JavaScript 中處理 JSON資料不需要任何特殊的 API 或工具包。
　　與XML序列化相比，JSON序列化後產生的資料一般要比XML序列化後資料體積小，所以在Facebook等知名網站中都採用了JSON作為資料交換方式。
　　在JSON中，有兩種結構：物件和陣列。
　　1. 一個物件以 “ { ” 開始，“ } ” 結束。每個“名稱”後跟一個 “ : ” ；“名稱/值 對”之間使用 “ , ”（逗號）分隔。 名稱用引號括起來；值如果是字串則必須用引號括起來，數值型則不需要。如：

var obj={"name":"darren","age":24,"location":"beijing"} ; 

　　2. 陣列是值（value）的有序集合。一個數組以 “ [ ” 開始， “ ] ” 結束。值之間使用 “ , ” （逗號）分隔。如：

var jsonlist=[{"name":"darren","age":24,"location":"beijing"},{"name":"weidong.nie","age":24,"location":"hunan"}];; 

　　對這種陣列和物件字面量的操作是非常方便且高效的。如果預先知道JSON結構的情況下，使用JSON進行資料傳遞簡直是太美妙了，可以寫出很實用美觀可讀性強的程式碼。如果你是純粹的前臺開發人員，一定會非常喜歡JSON。

9、減少Cookie傳輸

　 一方面，Cookie包含在每次請求和響應中，太大的Cookie會嚴重影響資料傳輸，因此哪些資料需要寫入Cookie需要慎重考慮，儘量減少Cookie中傳輸的資料量。另一方面對於某些靜態資源的訪問，如CSS、Script等，傳送Cookie沒有意義，可以考慮靜態資源使用獨立域名訪問，避免請求靜態資源時傳送Cookie，減少Cookie傳輸的次數。
　 因為Cookie是本地的磁碟檔案，每次瀏覽器都會去讀取相應的Cookie，所以建議去除不必要的Coockie，使Coockie體積儘量小以減少對使用者響應的影響；
　　使用Cookie跨域操作時注意在適應級別的域名上設定coockie以便使子域名不受其影響。
　　Cookie是有生命週期的，所以請注意設定合理的過期時間，合理地Expire時間和不要過早去清除coockie，都會改善使用者的響應時間。

10、使用CDN加速

　 CDN的全稱是Content Delivery Network，即內容分發網路。
　 CDN本質仍然是一個快取，而且將資料快取在離使用者最近的地方，使使用者以最快的速度獲取資料。
　　由於CDN部署在網路運營商的桐廬，這些運營商又是終端使用者的網路服務提供商，因此使用者請求路由的第一跳就到達了CDN伺服器，當CDN中存在瀏覽器請求的資源時，從CDN直接返回瀏覽器，最短路徑返回響應，加快使用者訪問速度，減少資料中心負載壓力。 CDN能夠快取的一般是靜態資源，如圖片、檔案（例如視訊）、CSS、Script指令碼、靜態網頁等，這些檔案訪問頻率很高（例如NBA總決賽這些的熱門視訊檔案），將其快取在CDN可極大改善網頁的開啟速度。
　　實時性不太好是CDN的缺陷。隨著對CDN需求的逐漸升溫，這一缺陷將得到改進， 使來自於遠端伺服器的網路內容網頁與副本伺服器或快取器中的網頁保持同步。解決方法是在網路內容發生變化時將新的網路內容從伺服器端直接傳送到快取器，或者當對網路內容的訪問增加時將資料來源伺服器的網路內容儘可能實時地複製到快取伺服器。

小結

　　前端攻城師這個職位正越來越受到各個網際網路公司的重視，身邊也有越來越多的朋友加入到前端開發這個崗位上。

　　由於現在本人表達能力和技術能力上的欠缺，難免有理解不對的地方，也請大家多多諒解。