網站前端優化

網站前端優化

 

第一：減小HTTP請求

 

1: 將超連接關聯到圖片上，例如在導航欄按鈕中。若是是以這種形式關聯多個帶有超連接的圖片，使用圖片地圖這種方式既能減小HTTP請求，有無需改變頁面外觀感覺。圖片地圖容許在一個圖片上關聯多個URL.

 

2: CSS Sprites

和圖片地圖同樣，CSS Sprites也能夠合併圖片，可是更加靈活，能夠將多個圖片合併到一個單獨的圖片中。

 

3：合併腳本和樣式表

咱們在使用Javascript和CSS時，究竟是進行「內聯」(也就是將其嵌套在HTML文檔中)仍是將其放在外部的腳本和樣式表文件中。通常來講，使用外部腳本和樣式表對性能更加有利（後面會說到）。可是，若是將代碼分割到過多的小文件中，會下降性能，由於每一個文件都會致使一個額外的HTTP請求。爲了清晰，不建議將腳本和樣式表合併在一塊兒。可是多個

腳本應該合併爲一個腳本，多個樣式表也應該合併爲一個樣式表。到底頁面上應該有多少個腳本文件和CSS文件須要花必定的時間分析頁面。

 

第二：使用內容發佈網絡

 

網站最初一般將其全部的服務器放在同一個地方。當用戶羣增長時，公司就必須面對服務器放置地點再也不使用的事實，有必要再多個地理位置不一樣的服務器上部署內容。

CDN的通俗理解就是網站加速，CPU均衡負載，能夠解決跨運營商，跨地區，服務器負載能力太低，帶寬過少等帶來的網站打開速度慢等問題。

好比：

1.一個企業的網站服務器在北京，運營商是電信，在廣東的聯通用戶訪問企業網站時，由於跨地區，跨運營商的緣由，網站打開速度就會比北京當地的電信客戶訪問速度慢不少，很容易形成這個企業的客戶流失

2.一個網站的服務器性能比較差，承載能力有限，有時面臨突發流量，招架不住，直接致使服務器崩潰，網站打不開，尤爲是電商網站在節日期間，由於這種狀況網站打不開，銷售額白白流失的佔比都高漲至60%

3.再好比一些中小企業租用的虛擬主機，由於跟好幾個網站共用一臺服務器，每一個網站所分帶寬有限，帶寬太小常常致使流量稍微一多，網站打開速度就很慢，甚至打不開。

國內較爲有名的CDN服務商有藍汛、網宿科技，世紀互聯，帝聯科技等

 

第三：添加Expires頭

今天的WEB頁面包含了大量的組件，而且其數量在不斷增加，頁面的初次訪問者會進行不少HTTP請求，但經過一個長久的Expires頭，使這些組件能夠被緩存。這回在後續的頁面瀏覽中避免沒必要要的HTTP請求。長久的Expires頭最經常使用於圖片，可是應該將其用在全部的組件上，包括腳本，樣式表等。在HTTP1.1引入了Cache-Control頭來克服Expires頭的限制。由於Expires頭使用一個特定的時間，它要求服務器和客戶端的時鐘嚴格同步。

使用帶有max-age的Cache-Control能夠消除Expires的限制(我推薦儘可能使用Cache-Control)。若是二者同時出現，HTTP規定max-age指令將重寫Expires頭。

能夠在IIS管理器爲靜態內容設置Cache-Control:max-age.

還能夠在web.config文件裏應用該設置.以下所示:

<configuration>

…………..

<system.webServer>

……………………..

<staticContent>

 <clientCache cacheControlMode=」UseMaxAge」 cacheControlMaxAge= ‘365.00 :00 :00 ’ > 

</staticContent>

</system.webServer>

</configuration>

 

前面的<staticContent>節名字暗示這種方式只針對靜態內容。對於動態內容，須要設置客戶端緩存過時時間，能夠在aspx文件中設置。

<%@ Page ……%>

<%@ OutputCache Duration=」86400」 Location=」Client」 VaryByParam=」None」%>

該指令告訴運行時生成的HTTP頭，讓瀏覽器緩存該內容1天（86400秒）。

 

第四：減小ViewState的大小。

有些控件，好比GridView,會很容易地產生數K字節的ViewState.由於瀏覽器會將ViewState做爲HTTP POST的一部分發送回服務器，因此若是它大，會對頁面的加載時間有不利的影響。因此應該關閉ViewState,代碼以下

<%@ Page Title="" Language="C#" EnableViewState="false" AutoEventWireup="true" CodeBehind="View.aspx.cs" Inherits=" View" %>

 

 

第五：壓縮組件

經過減少HTTP響應的大小來減小響應時間。若是HTTP請求產生的響應包很小，傳輸時間就會減小，由於只須要將很小的包從服務器傳遞到客戶端。這一效果對速度較慢的帶寬尤爲明顯。最主要的方式是經過gzip編碼來壓縮HTTP響應包，並由此減小網絡響應時間。這是減少頁面大小的最簡單的技術，但影響是最大的。還有不少方式能夠減少HTML文檔的頁面大小（例如刪除註釋和額外的空格，移除沒有使用的CSS，移除沒有使用的JAVASCRIPT,檢查並移除冗餘標籤，移除沒有內容的標籤，移除<meta refresh>標籤：頁面自動刷新乍一看有時很動人，可是考慮到這樣的狀況，用戶離開了電腦，或者正在看瀏覽器的另一個選項卡，那麼這隻會浪費客戶端和服務器的資源）。

Web客戶端能夠經過HTTP請求中的Accept-Encoding頭來標示對壓縮的支持。

Accept-Encoding:gzip,deflate

若是Web服務器看到請求中有這個頭，就會使用客戶端列出來的方法中的一種來壓縮響應。Web服務器經過響應中的Content-Encoding頭來通知Web客戶端

Content-Encoding:gzip

Gzip是目前最流行和有效地壓縮方法，你能看到的另外一種壓縮方式爲deflate,可是效果不如gzip,而且也不太流行，支持deflate的瀏覽器也支持gzip,可是不少瀏覽器支持gzip卻不支持deflate,所以gzip是最理想的壓縮方法。不少網站會壓縮其HTML文檔，壓縮腳本和CSS樣式表也是很重要的，圖片不該該壓縮，由於能夠在上傳時進行壓縮，試圖對它們進行壓縮

只會浪費CPU資源。固然壓縮也是有成本的，服務端會額外花費CPU週期來完成壓縮，客戶端須要對壓縮文件進行解壓縮。要檢測收益是否大於開銷，須要考慮響應的大小，連接的帶寬和客戶端與服務器之間的Internet距離，這些信息是很可貴到的，根據經驗一般對於大於1KB或2KB的文件進行壓縮。

能夠在IIS中配置文件的壓縮，具體步驟能夠參考微軟的MSDN

http://msdn.microsoft.com/zh-cn/ff695514.aspx

 

壓縮分爲靜態壓縮和動態壓縮，我建議在這裏啓用靜態壓縮，而不要啓用動態壓縮。對於一個活躍的網站，啓用壓縮一般會增長大概3%~5%的CUP使用率。對於大多數網站，這種取捨一般是值得的。

這裏須要考慮代理緩存的狀況，有興趣的同窗能夠查一下資料。

第六：將樣式表放在頂部（使用Link標籤將樣式表放在HEAD標籤中）

咱們但願瀏覽器可以儘快顯示內容，這對於有不少內容的頁面以及Internet連接很慢的用戶來講很重要。將樣式表放在文檔底部會致使在瀏覽器中阻止內容逐步呈現。該規則對於加載頁面所須要的時間沒有什麼太大的影響。在瀏覽器和用戶等待位於底部的樣式表時，瀏覽器會延遲顯示任何的可視化的內容，咱們稱之爲」白屏」

你們能夠本身測試一下。

爲了不白屏，請將樣式表放在文檔頂部的Head中。在Head中導入外部樣式可使用Link,和@import，我更喜歡使用Link，由於性能要好一些，而且@import有時候可能會致使白屏的出現，甚至放在文檔的Head標籤中。

 

第七：將腳本放在底部

在使用樣式表時，頁面逐步呈現會被阻止，直到全部的樣式表下載完成。這就是最好將樣式表移到文檔的HEAD的緣由，這樣就能首先下載它們而不會阻止頁面呈現。使用腳本時，對於全部位於腳本如下的內容，逐步呈現都被阻塞了。將腳本放在頁面越靠下的地方，意味着越多的內容可以逐步呈現。

並行下載組件的優勢是很明顯的。然而在下載腳本文件時並行下載其實是被禁用的，其中的一個緣由是，腳本可能使用了document.write來修改頁面內容，所以瀏覽器會等待，以確保可以恰當的佈局。

另一個緣由是爲了保證腳本可以按照正確的順序執行。因此腳本會阻塞對其後面內容的呈現。若是將腳本放在頁面頂部，頁面中的全部的內容都位於腳本以後，整個頁面的呈現和下載都會被阻塞，直到腳本加載完畢。因爲整個頁面的呈現被阻塞了，所以也會出現白屏的現象。

 

第八：使用外部的CSS和Javascript

 

使用外部的CSS和Javascript的緣由是這些文件有機會被瀏覽器緩存起來。

若是你的網站中的每一個頁面都使用了相同的CSS和Javascript，使用外部文件能夠提升這些組件的重用率。在這些狀況下使用外部文件更加具備優點，由於當用戶在頁面間導航時，Javascript和CSS組件已經位於瀏覽器的緩存中了。相反的狀況時，若是沒有任何兩個頁面共享相同的JAVASCRIPT和CSS，重用率就會下降。固然解決這個問題，沒有什麼好的辦法，我認爲能夠採用一個折中的辦法，就是將你網站的頁面劃分紅幾種頁面類型，而後爲每種類型建立單獨的腳本和樣式表，這樣的話對於給定的任意界面都只須要下載不多的多餘的CSS和JAVASCRIPT文件。固然，你的CSS和JAVASCRIPT有很高的重用度，則部署在外部文件中更有優點，可是若是重用度很低，仍是內聯更有意義一些。

 

第九：減小DNS的查找

Internet是經過IP地址來查找服務器的，因爲IP地址比較難記，一般使用包含主機名的URL來代替（域名），可是當瀏覽器發出請求時，IP地址仍然是必須的，這就須要DNS將主機名稱映射到IP地址上，你在瀏覽器上鍵入 :www.baidu.com時，鏈接到瀏覽器的DNS解析器會返回服務器的IP地址。DNS也是有開銷的，一般狀況下瀏覽器查找一個給定的主機名的IP地址須要花費20~120毫秒，在DNS查找完成以前，瀏覽器是不能從主機名那裏下載到任何東西的。響應的時間依賴於DNS解析器，它所承擔的請求的壓力，你與它之間的距離和你的帶寬。固然DNS也是能夠被緩存起來的，可是瀏覽器對緩存的DNS記錄的數量也有限制，而無論緩存記錄的時間。若是用戶在短期內訪問了不少具備不一樣域名的網站，較早的DNS記錄將被丟棄，必須從新查找該域名。

減小DNS查找，個人建議是將CSS,圖片，腳本等這些組件分別放在至少2個，但不要超過4個主機域名下。這是在減小DNS查找和容許高度並行下載之間作出的很好的權衡。

 

第十：精簡JavaScript

精簡是從代碼中移除沒必要要的字符以減少其大小，進而改善加載時間，在代碼被精簡之後，全部的註釋以及沒必要要的空白字符（空格，換行等）都被移除。對於Javascript而言，這能夠改善響應時間效率，由於須要下載的文件大小減少了。說到精簡，簡單提一下混淆。

混淆是能夠應用在源碼上的另一種優化方式，和精簡同樣，它也會移除註釋空白，同時它還會改寫代碼。做爲改寫的一部分，函數和變量的名字將被變的更短，可是也更難閱讀。一般這樣作的目的主要是爲了增長對代碼進行反向工程的難度。固然對提升性能也有幫助，由於這比精簡更能減少代碼的大小。缺點就是，更加複雜，並且很難閱讀與調試。

精簡JavaScript代碼的工具可使用JSMin.

咱們在前面說過，能夠對Javascript外部文件使用gzip來完成壓縮，當前gzip壓縮比精簡更能減小文件的大小，那麼若是已經啓用了壓縮，是否還要在進行精簡呢？

是有必要的，由於gzip雖然壓縮產生的影響更大，可是精簡可以進一步的減少文件的大小。

精簡CSS可以帶來的節省要小於精簡JAVASCRIPT，由於CSS中的空白和註釋通常狀況下要比JAVASCRIPT的少，因此CSS主要是合併相同的類，移除不用的類等。

 

十一：移除重複的腳本

重複腳本損傷性能的方式主要有兩種狀況，沒必要要的HTTP請求和執行JavaScript所浪費的時間。這種錯誤看似簡單可是倒是常常發生的，例如在母版頁中引用了一個腳本文件，在具體的內容頁面中又引用了一次。有可能有人認爲，如今腳本文件已經被緩存了，不會再發新的請求了，可是若是單擊瀏覽器的刷新按鈕時，仍是會產生兩個HTTP請求（這種狀況存在IE中）。同時，對腳本進行屢次求值也會浪費時間。

 

十二：注意圖片的優化

 

1：減小頁面上的圖片的數量

圖片一般比HTML佔用更多的網站帶寬，因此圖片優化的第一步應該是考慮一下是否須要頁面上全部的圖片。

2：可使用CSS來代替翻轉圖片的效果。

3：優化背景圖片

優化背景圖片，必定要利用瀏覽器能夠經過平鋪重複單個圖片的功能。例如將圖片是1像素寬的漸變圖片平鋪。

4：選擇正確的圖片格式

5：壓縮縮小圖片尺寸。

6：使用圖片切片

7：若是您的網站存在大量的圖片讀寫操做，我建議您使用圖片服務器