前端性能優化--筆記

一）Make fewer HTTP requests

減小HTTP請求次數。合併圖片、CSS、JS，改進首次訪問用戶等待時間。 

終端用戶響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。經過減小頁面中的元素能夠減小HTTP請求的次數。這是提升網頁速度的關鍵步驟。 

這裏有幾條減小HTTP請求次數同時又可能保持頁面內容豐富的技術。

合併文件是經過把全部的腳本放到一個文件中來減小HTTP請求的方法，如能夠簡單地把全部的CSS文件都放入一個樣式表中。當腳本或者樣式表在不一樣頁面中使用時須要作不一樣的修改，這可能會相對麻煩點，但即使如此也要把這個方法做爲改善頁面性能的重要一步。

CSS Sprites是減小圖像請求的有效方法。把全部的背景圖像都放到一個圖片文件中，而後經過CSS的background-image和background-position屬性來顯示圖片的不一樣部分；

圖片地圖是把多張圖片整合到一張圖片中。雖然文件的整體大小不會改變，可是能夠減小HTTP請求次數。圖片地圖只有在圖片的全部組成部分在頁面中是緊挨在一塊兒的時候才能使用，如導航欄。肯定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具備可讀性，所以不推薦這種方法；

內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中。這可能會增長頁面的大小。把內聯圖像放到樣式表（可緩存）中能夠減小HTTP請求同時又避免增長頁面文件的大小。可是內聯圖像如今尚未獲得主流瀏覽器的支持。

減小頁面的HTTP請求次數是你首先要作的一步。這是改進首次訪問用戶等待時間的最重要的方法。HTTP請求在無緩存狀況下佔去了40%到60%的響應時間。

二）Use a CDN

減小DNS查找次數。使用CDN，就近緩存==>智能路由==>負載均衡==>WSA全站動態加速 

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

域名系統（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查找次數和保持較高程度並行下載二者之間的權衡了。

三）Avoid empty src or href

避免空的src和href。
當link標籤的href屬性爲空、script標籤的src屬性爲空的時候，瀏覽器渲染的時候會把當前頁面的URL做爲它們的屬性值，從而把頁面的內容加載進來做爲它們的值。

四）Add an Expires headers

爲文件頭指定Expires 
使內容具備緩存性。避免了接下來的頁面訪問中沒必要要的HTTP請求。 

設置過時的HTTP Header.設置Expires Header能夠將腳本, 樣式表, 圖片, Flash等緩存在瀏覽器的Cache中。
五）Compress components with Gzip  

使用gzip壓縮內容。
壓縮任何一個文本類型的響應，包括XML和JSON，都是值得的。

對咱們的頁面內容進行Gzip格式的壓縮，Gzip格式是一種很廣泛的壓縮技術，幾乎全部的瀏覽器都有解壓Gzip格式的能力，並且它能夠壓縮的比例很是 大，通常壓縮率爲85%，就是說服務器端100K的頁面能夠壓縮到25K左右的Gzip格式的數據發給客戶端，客戶端收到Gzip格式的數據後自動解壓縮後顯示頁面。

網絡傳輸中的HTTP請求和應答時間能夠經過前端機制獲得顯著改善。的確，終端用戶的帶寬、互聯網提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。可是還有其餘因素影響着響應時間。經過減少HTTP響應的大小能夠節省HTTP響應時間。
從HTTP/1.1開始，web客戶端都默認支持HTTP請求中有Accept-Encoding文件頭的壓縮格式：
Accept-Encoding: gzip, deflate
若是web服務器在請求的文件頭中檢測到上面的代碼，就會以客戶端列出的方式壓縮響應內容。Web服務器把壓縮方式經過響應文件頭中的Content-Encoding來返回給瀏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項目開發並經過RFC 1952來標準化的。另外僅有的一個壓縮格式是deflate，可是它的使用範圍有限效果也稍稍遜色。
Gzip大概能夠減小70%的響應規模。目前大約有90%經過瀏覽器傳輸的互聯網交換支持gzip格式。若是你使用的是Apache，gzip模塊配置和你的版本有關：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
瀏覽器和代理都會存在這樣的問題：瀏覽器指望收到的和實際接收到的內容會存在不匹配的現象。幸虧，這種特殊狀況隨着舊式瀏覽器使用量的減小在減小。Apache模塊會經過自動添加適當的Vary響應文件頭來避免這種情況的出現。
服務器根據文件類型來選擇須要進行gzip壓縮的文件，可是這過於限制了可壓縮的文件。大多數web服務器會壓縮HTML文檔。對腳本和樣式表進行壓縮一樣也是值得作的事情，可是不少web服務器都沒有這個功能。實際上，壓縮任何一個文本類型的響應，包括XML和JSON，都值得的。圖像和PDF文件因爲已經壓縮過了因此不能再進行gzip壓縮。若是試圖gizp壓縮這些文件的話不但會浪費CPU資源還會增長文件的大小。
Gzip壓縮全部可能的文件類型是減小文件體積增長用戶體驗的簡單方法。

六）Put CSS at top

把CSS放到頂部

Put CSS at the top 把CSS外部連接放到頁面的頂部。其實這個原則咱們通常都遵照的，若是把CSS外部連接做爲邏輯的一部分出如今頁面頭部如下，我我的以爲這個自己就 是個錯誤。
七）Put JS at  bottom

把JS放到底部 
防止js加載對以後資源形成阻塞。

把Javascript腳本儘可能放到頁面底部加載。 一開始爲覺得Javascript腳本儘可能放到頁面底部加載，是指全部的JS腳本都要放到底部，後來才發現，並不 徹底是這樣，這裏所指的腳本是指那些在加載過程當中要執行的腳本，因此通常的處理辦法仍是頁面頭部引入JS連接，頁面底部執行JS腳本程序。爲何要這麼作 呢？呵呵，其實很簡單，爲了實現最大的下載並行，頁面加載初期作的事，最好只有下載，HTML的下載，CSS的下載,JS的下載，等下載完成後再去實現頁 面渲染，JS腳本運行。
八）Avoid CSS expressions

避免使用CSS表達式 

避免CSS表達式 其實在CSS中運行表達式和頁面加載中運行大量的JS腳本差很少，或許還更慢，並且還不兼容，雖然可使咱們在頁面邏輯簡單很多，可是咱們徹底能夠拋棄之。

九）Make JS and CSS external

將CSS和JS放到外部文件中 
目的是緩存，但有時候爲了減小請求，也會直接寫到頁面裏，需根據PV和IP的比例權衡。
十）Reduce DNS lookups

儘量少的DNS查找。

權衡DNS查找次數 
減小主機名能夠節省響應時間。但同時，須要注意，減小主機會減小頁面中並行下載的數量。 
IE瀏覽器在同一時刻只能從同一域名下載兩個文件。當在一個頁面顯示多張圖片時，IE 用戶的圖片下載速度就會受到影響。因此新浪會搞N個二級域名來放圖片。 

十一）Minify JS and CSS

精簡CSS和JS 

對Javascript 代碼進行壓縮。壓縮工具，yuicompressor，雅虎美國開發的JAVA 壓縮包yuicompressor.jar。壓縮的至關完美，不只把代碼間的空格換行給去除掉了，並且對變量名，北部方法名都進行的簡化，無心中實現了混 淆腳本的做用。
十二）Avoid URL redirects

避免重定向。

避免跳轉 
同域：注意避免反斜槓 「/」 的跳轉； 
跨域：使用Alias或者mod_rewirte創建CNAME（保存域名與域名之間關係的DNS記錄）

十三）Remove duplicate JS and CSS

scripts 去除重複的腳本。

刪除重複的JS和CSS 
重複調用腳本，除了增長額外的HTTP請求外，屢次運算也會浪費時間。在IE和Firefox中無論腳本是否可緩存，它們都存在重複運算JavaScript的問題。 

十四）Configure entity ETags

這個好像是服務器端配置的問題。

配置ETags 
它用來判斷瀏覽器緩存裏的元素是否和原來服務器上的一致。比last-modified date更具備彈性，例如某個文件在1秒內修改了10次，Etag能夠綜合Inode(文件的索引節點(inode)數)，MTime(修改時間)和Size來精準的進行判斷，避開UNIX記錄MTime只能精確到秒的問題。 服務器集羣使用，可取後兩個參數。使用ETags減小Web應用帶寬和負載。

 

Entity tags（ETags）（實體標籤）是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制（「實體」就是所說的「內容」，包括圖片、腳本、樣式表等）。增長ETag爲實體的驗證提供了一個比使用「last-modified date（上次編輯時間）」更加靈活的機制。Etag是一個識別內容版本號的惟一字符串。惟一的格式限制就是它必須包含在雙引號內。原始服務器經過含有ETag文件頭的響應指定頁面內容的ETag。
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195
稍後，若是瀏覽器要驗證一個文件，它會使用If-None-Match文件頭來把ETag傳回給原始服務器。在這個例子中，若是ETag匹配，就會返回一個304狀態碼，這就節省了12195字節的響應。 GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified
ETag的問題在於，它是根據能夠辨別網站所在的服務器的具備惟一性的屬性來生成的。當瀏覽器從一臺服務器上得到頁面內容後到另一臺服務器上進行驗證時ETag就會不匹配，這種狀況對於使用服務器組和處理請求的網站來講是很是常見的。默認狀況下，Apache和IIS都會把數據嵌入ETag中，這會顯著減小多服務器間的文件驗證衝突。
Apache 1.3和2.x中的ETag格式爲inode-size-timestamp。即便某個文件在不一樣的服務器上會處於相同的目錄下，文件大小、權限、時間戳等都徹底相同，可是在不一樣服務器上他們的內碼也是不一樣的。
IIS 5.0和IIS 6.0處理ETag的機制類似。IIS中的ETag格式爲Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤IIS配置的改變。網站所用的不一樣IIS服務器間ChangeNumber也不相同。 不一樣的服務器上的Apache和IIS即便對於徹底相同的內容產生的ETag在也不相同，用戶並不會接收到一個小而快的304響應；相反他們會接收一個正常的200響應並下載所有內容。若是你的網站只放在一臺服務器上，就不會存在這個問題。可是若是你的網站是架設在多個服務器上，而且使用Apache和IIS產生默認的ETag配置，你的用戶得到頁面就會相對慢一點，服務器會傳輸更多的內容，佔用更多的帶寬，代理也不會有效地緩存你的網站內容。即便你的內容擁有Expires文件頭，不管用戶何時點擊「刷新」或者「重載」按鈕都會發送相應的GET請求。
若是你沒有使用ETag提供的靈活的驗證模式，那麼幹脆把全部的ETag都去掉會更好。Last-Modified文件頭驗證是基於內容的時間戳的。去掉ETag文件頭會減小響應和下次請求中文件的大小。微軟的這篇支持文稿講述瞭如何去掉ETag。在Apache中，只須要在配置文件中簡單添加下面一行代碼就能夠了：
FileETag none

 

十五）make AJAX cacheable

(AJAX 緩存)。

可緩存的AJAX 
「異步」並不意味着「即時」：Ajax並不能保證用戶不會在等待異步的JavaScript和XML響應上花費時間。

十六）Use GET for AJEX requests

 使用GET來完成AJAX請求 
當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，而後才發送數據。所以使用GET獲取數據時更加有意義。

十七）Reduce the number of DOM elements

減小DOM元素數量 。

 

一個複雜的頁面意味着須要下載更多數據，同時也意味着JavaScript遍歷DOM的效率越慢。好比當你增長一個事件句柄時在500和5000個DOM元素中循環效果確定是不同的。
大量的DOM元素的存在乎味着頁面中有能夠不用移除內容只須要替換元素標籤就能夠精簡的部分。你在頁面佈局中使用表格了嗎？你有沒有僅僅爲了佈局而引入更多的<div>元素呢？也許會存在一個適合或者在語意是更貼切的標籤能夠供你使用。
YUI CSS utilities能夠給你的佈局帶來巨大幫助：grids.css能夠幫你實現總體佈局，font.css和reset.css能夠幫助你移除瀏覽器默認格式。它提供了一個從新審視你頁面中標籤的機會，好比只有在語意上有意義時才使用<div>，而不是由於它具備換行效果才使用它。
DOM元素數量很容易計算出來，只須要在Firebug的控制檯內輸入：
document.getElementsByTagName('*').length
那麼多少個DOM元素算是多呢？這能夠對照有很好標記使用的相似頁面。好比Yahoo!主頁是一個內容很是多的頁面，可是它只使用了700個元素（HTML標籤）。

 

十八）Avoid HTTP 404(Not  Found )error

 避免404 。
有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部 JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分看成JavaScript代碼來執行。 

 

HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。

 

十九）Reduce cookie size

減小Cookie的大小 

二十）Use cookie-free domains

使用無cookie的域 
好比圖片 CSS 等，Yahoo! 的靜態文件都在 yimg.com 上，客戶端請求靜態文件的時候，減小了 Cookie 的反覆傳輸對主域名 (yahoo.com) 的影響。

二一）Avoid AlphaImageLoader filter

不要使用濾鏡 
png24的在IE6半透明那種東西，別亂使，淡定的切成PNG8+jpg 

二二）Do not scale images in HTML

不要在HTML中縮放圖片 

二三）Make favicon small and cacheable

 

 縮小favicon.ico並緩存