前端技術-前端優化

前端優化

時間花哪裏去了？

只有10%-20%的最終用戶響應時間花在了下載html文檔上,其他80%-90%時間花在了下載頁面的相關組件上。如：圖片、Flash等。

因此主要優化：

減小http請求
緩存
減小文件大小：壓縮文件+優化代碼

健康的優化因該是根據頁面的加載過程，全面的優化過程

第一步、瀏覽器預處理

查詢Cache：讀取Cache 或者發送304請求

第二步、查詢DNS

優化規則--減小DNS查找

DNS緩存
瀏覽器DNS緩存 計算機DNS緩存 服務器DNS緩存（TTL）

使用Keep-Alive特性
減小DNS查找

當客戶端的DNS緩存爲空時，DNS查找的數量與Web頁面中惟一主機名的數量相等。減小惟一主機名的數量就能夠減小DNS查找的數量。
較少的域名來減小DNS查找（2-4個主機）

域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係同樣。當你在瀏覽器地址欄中輸入www.dudo.org 時，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查找次數和保持較高程度並行下載二者之間的權衡了。

第三步、創建鏈接

優化規則-- 使用內容分發網絡

CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是經過在現有的Internet中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡"邊緣"（邊緣服務器），使用戶能夠就近取得所需的內容，解決Internet網絡擁擠的情況，提升用戶訪問網站的響應速度。從技術上全面解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由所形成的用戶訪問網站響應速度慢的問題。

CDN技術是在美國首先興起並迅速發展起來的一種解決互聯網性能不佳問題的有效手段。其基本思路就是儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩。經過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。
優化規則--用域名劃分頁面內容

按頁面內容劃分域名，在合適的資源服務器上存放文件

把頁面內容劃分紅若干部分可使你最大限度地實現平行下載。因爲DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如，你能夠把用到的HTML內容和動態內容放在www.example.org上，而把頁面各類組件（圖片、腳本、CSS)分別存放在 statics1.example.org和statics.example.org上。
你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane找到更多相關信息。

第四步、發送請求
優化規則-- 減小HTTP請求

終端用戶響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。經過減小頁面中的元素能夠減小 HTTP請求的次數。這是提升網頁速度的關鍵步驟。
減小頁面組件的方法其實就是簡化頁面設計。那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這裏有幾條減小HTTP請求次數同時又可能保持頁面內容豐富的技術。
合併文件是經過把全部的腳本放到一個文件中來減小HTTP請求的方法，如能夠簡單地把全部的CSS文件都放入一個樣式表中。當腳本或者樣式表在不一樣頁面中使用時須要作不一樣的修改，這可能會相對麻煩點，但即使如此也要把這個方法做爲改善頁面性能的重要一步。
CSS Sprites是減小圖像請求的有效方法。把全部的背景圖像都放到一個圖片文件中，而後經過CSS的background-image和 background-position屬性來顯示圖片的不一樣部分；
圖片地圖是把多張圖片整合到一張圖片中。雖然文件的整體大小不會改變，可是能夠減小HTTP請求次數。圖片地圖只有在圖片的全部組成部分在頁面中是緊挨在一塊兒的時候才能使用，如導航欄。肯定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具備可讀性，所以不推薦這種方法；
內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中。這可能會增長頁面的大小。把內聯圖像放到樣式表（可緩存）中能夠減小HTTP請求同時又避免增長頁面文件的大小。可是內聯圖像如今尚未獲得主流瀏覽器的支持。
減小頁面的HTTP請求次數是你首先要作的一步。這是改進首次訪問用戶等待時間的最重要的方法。如同Tenni Theurer的他的博客Browser Cahe Usage - Exposed!中所說，HTTP請求在無緩存狀況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人得到更加快速的體驗吧！

優化規則- – 優化CSS Spirite
在Spirite中水平排列你的圖片，垂直排列會稍稍增長文件大小；
Spirite 中把顏色較近的組合在一塊兒能夠下降顏色數，理想情況是低於256色以便適用PNG8格式；
便於移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增長文件大小但對於用戶代理來講它須要更少的內存來把圖片解壓爲像素地圖。100x100的圖片爲1萬像素，而 1000x1000就是100萬像素。

優化規則– 避免404錯誤

HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。
有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部 JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分看成JavaScript代碼來執行。

規則優化 –不要使用frameset，少使用iframe

搜索引擎不友好、 即時內容爲空，加載也須要時間、會阻止頁面加載
禁止使用iframe引入外部資源，不包括allyes廣告，不包括about:blank的空頁面。

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

iframe優勢：

解決加載緩慢的第三方內容如圖標和廣告等的加載問題
Security sandbox
並行加載腳本
iframe的缺點：

即時內容爲空，加載也須要時間
會阻止頁面加載
沒有語意

第五步、等待響應

優化規則 --避免重定向

在重定向完畢而且HTML下載完畢以前，是沒有任何東西顯示給用戶的

涉及服務器負載、數據查詢、服務器端緩存等

跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
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記錄）來替代。

跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
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記錄）來替代。

跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
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記錄）來替代。

第七步、接收數據

優化規則 -- 壓縮組件

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個）

下載腳本時並行下載其實是被禁用的。
 

優化規則-- 移除重複腳本

 

優化規則 -- 避免CSS表達式

影響瀏覽器渲染時間

優化規則 – 優化圖像

儘可能使用GIF和PNG

儘可能使用png/gif格式的圖片，png的圖片優先，可是必須注意如要兼容IE6，則png使用必定要注意透明問題。

圖片在上次前必定要先用工具壓縮優化（png、jpg）

-------------------------------------------------------------------------------------------------------------------------------------

完

轉載需註明轉載字樣，標註原做者和原博文地址。

更多閱讀：

http://www.cnblogs.com/dolphinX/p/3508657.html

http://www.cnblogs.com/fullhouse/archive/2012/01/05/2312956.html

http://www.php100.com/html/webkaifa/javascript/2012/0619/10568.html

http://www.cnblogs.com/zhengyun_ustc/archive/2013/05/09/frontendoptimize.html

http://www.cnblogs.com/and/p/3390676.html