網站前端性能優化方案，網站優化離不開前后端的互相協作，但是對于前端工程師來說，在保證后端技術方案不變時，能不能只利用前端技術來優化網站呢？答案是肯定。雅虎的郵件團隊總結了常用的35條網站優化最佳實踐，其中就有很多實踐，只要我們前端人員在日常開發過程中遵循這些實踐，就可以在一定程度優化網站加載速度。

下面就是這些實踐的詳細說明。

1.最小化HTTP請求

80%的終端響應時間花費在前端，這其中的大部分時間又浪費在下載頁面內容上，頁面內容包括圖片，樣式表，腳本，flash等等。減少頁面內容的數量，轉而就減少了渲染頁面需要的HTTP請求數量。這是優化頁面的關鍵。

減少頁面內容的一種方法是簡化頁面設計。但是是否存在其它方法既可以用豐富的內容來構建頁面，又可以獲取快速的相應時間呢？下面的幾種技術即可以減少HTTP請求數量，又可以支持豐富的頁面設計。

合并文件是一種減少HTTP請求的方式，通過合并多個Js文件到一個Js文件，合并多個CSS文件到一個CSS文件的方式。文件合并是非常有挑戰性的，因為每個頁面的Script和CSS都不一樣，但是如果在你的發布過程中有這個步驟確實可以響應時間。

CSS Sprites是減少圖片請求首選的方法。把你的背景圖片合并到一張圖片中，使用CSS的background-image和background-position屬性來展示期望的圖片部分。

Image maps 合并多個圖片到一個圖片中。圖片總大小是一樣的，但是減少了一定數量的HTTP請求，加快了頁面展示速度。只有當頁面中的圖片是連續的，Image maps才有用，例如導航欄。定義Image maps的坐標可能非常乏味并且也容易出錯，為導航使用Image maps也不是很方便，所以不推薦這種方式。

Inline images 使用data:URL scheme把圖片數據內嵌到當前頁面中。這種方式會增加HTML文檔的大小。把Inline images寫到（緩存的）樣式文件中是減少HTTP請求的同時避免增加頁面大小的一種方法。Inline images還沒有被所有的主流瀏覽器支持。

2.使用內容分發網絡（Content Delivery Network,CDN）

用戶跟Web服務器的距離對相應時間是有影響的。從用戶的角度來說，把你的內容部署在多個地理位置分散的服務器上有利于頁面加載的更快。

實施內容分發，首先不要嘗試把Web應用重構成分布式架構。根據不同的應用，改變架構可能會有艱巨的任務，比如在不同的服務器之前同步session狀態，復制數據庫事務。這樣的話應用架構這一步可能就會導致這種嘗試延遲。

記住80%到90%的終端響應時間花費在下載頁面內容上面:iamges,css,js,flash等等，這是性能的黃金法則。而不是以重構web應用架構的艱巨任務開始，最好首先分散靜態內容。這樣不僅最大化的減少響應時間，而且利用內容分發網絡可以變得更簡單。

內容分發網絡(CDN)是分布在多個地點的web服務器的集合，可以有效的為用戶分發內容。給用戶分發內容的服務器是根據網絡距離選擇的，例如，選擇擁有最少網絡跳轉或者最快相應速度的服務器。

3.增加Expires或者Cache-Control頭

這個規則有兩個方面：

對于靜態資源：實行"永不過期"策略，通過在header中把Expires設置盡量長點

對于動態資源：使用一個適當的Cache-Control header幫助瀏覽器響應條件請求

頁面設計的越來越豐富，這就意味著頁面中有更多的js,css,images,falsh等。首次訪問頁面的用戶可能會有幾個HTTP請求，但是通過使用Expires header你可以使這些內容緩存。這樣在后續頁面訪問時可以避免不必要的HTTP請求次數。Expires header經常和圖片一起用，但是js,css,flash都可以使用。

瀏覽器（和代理）使用緩存減少HTTP請求數量和大小，加快頁面加載速度。web服務器在HTTP響應中使用Expires header告訴客戶端內容可以被緩存多長時間。 下面就是一個Expires header例子，告訴瀏覽器這個響應在2010-4-15之前不會過期Expires: Thu, 15 Apr 2010 20:00:00 GMT

如果是Apache服務器，使用ExpiresDefault指令相對當前日期設置過期時間。下面就是設置請求10年過期的例子：ExpiresDefault "access plus 10 years"

謹記，如果你使用了Expires header，那么當你的文件內容有改變時，內容的文件名必須改變。這樣內容才會更新。可以再文件名中加版本后，這樣每次發布時文件名都會改變。

使用Expire header只會影響已經訪問過你站點的用戶。如果用戶第一次訪問站點或者瀏覽器還沒有緩存，它不會減少HTTP請求次數。因此這種性能改善的影響依賴于用戶是不是經常訪問帶緩存的頁面。通過使用Expires header你可以讓瀏覽器增加緩存內容數量，在后續頁面訪問時重用這些內容而不用在通過網絡請求獲取。

4.Gzip壓縮內容

前端工程師做出的某些決定可以顯著的減少HTTP請求以及響應的網絡傳輸時間。終端用戶的帶寬速度，網絡服務提供商，距網絡交換節點的距離這些因素都不受開發團隊的控制。但是仍有其它的因素會影響響應時間。比如，通過壓縮HTTP響應來減少響應時間。

從HTTP/1.1開始，web客戶端就開始支持HTTP請求的 Accept-Encoding header。Accept-Encoding: gzip, deflate

如果web服務器在請求中看到這種header,它就會用客戶端列出來的方法來壓縮響應內容。web服務器通過響應中的Content-Encoding header通知web客戶端。Content-Encoding: gzip

Gzip是目前最流行以及最有效的壓縮方法。其它你有可能看到的壓縮格式是deflate,但是它不是很流行以及很有效。

Gzip通?？梢园秧憫獌热荽笮p少70%。目前瀏覽器當中接近90%的網絡流量支持gzip。

對于瀏覽器以及代理來說還有一個已知問題就是瀏覽器期望的內容和它獲取的壓縮內容可能不匹配。幸運的是，這種情況隨著舊版瀏覽器的使用率越來越低會越來越少。Apache模塊通過添加適當的不同響應頭來解決這個問題。

服務端選擇用Gzip壓縮內容主要依賴于文件類型，但是通常也受限于要決定壓縮的內容。大部分web站點用gzip壓縮html文檔。當然也值的壓縮腳本以及樣式文件，但是很多網站都沒有選擇這么做。事實上，可以用gzip壓縮任何文本響應內容，包括XML和JSON。Image和PDF不建議gzip壓縮，因為它們都是被壓縮過的。試圖壓縮它們不僅浪費CPU也有可能會增加文件大小。

用gzip壓縮盡可能多的文件類型是減少頁面大小提升用戶體驗的一種簡單方法。

5.把CSS文件放到頂部

把CSS文件移到文檔的HEAD中看起來好像可以加快頁面載入速度，其實這是因為把CSS文件放到HEAD中，可以讓頁面逐步渲染。

前端工程師可能只關注性能，希望頁面可以逐步加載，但是對于用戶來說，不管頁面有多少內容，希望瀏覽器可以盡快的展示頁面。對于頁面內容很多以及用戶網絡環境不好的情況，這一點非常重要。給用戶視覺反饋(例如進度提示)的重要性不言而喻，有很多類似的研究。當瀏覽器加載頁面時逐步加載頭部，導航欄，以及頂部logo等的過程，HTML頁面就相當于進度提示，這樣就給等待頁面加載的用戶一個視覺反饋。提高整體的用戶體驗。

如果把CSS文件放到頁面底部，在很多瀏覽器中可能會影響逐步渲染過程，包括IE瀏覽器。因為這些瀏覽器會阻塞渲染過程以防頁面元素樣式改變時重繪元素。用戶就會看到一個空白頁。

HTML的規范中明確聲明了CSS是包含在頁面的HEAD中的。

6.把Js文件放到底部****

腳本文件會導致的一個問題就是它們會阻塞并行下載。HTTP/1.1規范建議不要在一個主機上并行下載不超過兩個腳本文件。如果把圖片托管到多臺主機上面，那就可以并行下載多個圖片文件。但是當一個腳本文件正在下載時，瀏覽器不會下載其他的腳本文件，即便這個腳本文件在其它主機上面。

在有些情況下想要把腳本文件移動文檔底部并不容易。例如如果腳本使用document.write插入頁面內容，它就不能移到頁面底部。這可能會引起作用域問題。在很多情況下，還有其它的途徑解決類似的這種問題。

一個常用的建議就是使用延時腳本。script的DEFER屬性表明腳本不包含document.write，告訴瀏覽器可以繼續渲染。但是也不是所有的瀏覽器都支持。Firefox不支持DEFER屬性，IE對DEFER的支持也不盡如意。

如果腳本可以延遲加載，它就可以放到頁面底部，這樣就會加快頁面的載入速度。

7.避免CSS表達式

CSS表達式是動態設置CSS屬性的一種強大并且危險的方法。IE從5開始支持CSS表達式，但是從IE8開始棄用這種方式。下面的例子就是，背景顏色可以根據時間動態設置：
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

如上面展示的，expression方法接受一個js表達式參數，CSS的屬性是根據js表達式的計算結果設置的。其它瀏覽器不支持expression方法，所以它只適用于IE瀏覽器。

CSS表達式的問題是計算太頻繁了，不僅頁面渲染縮放時，需要計算，頁面滾動甚至鼠標滑過頁面時都需要重新計算。如果在CSS表達式里面加個計數器來追蹤CSS表達式的計算頻率，把鼠標滑過頁面就會發現計算次數會輕易的超過10000次。

減少CSS表達式計算次數的方法是使用一次性表達式，表達式第一次計算時會給樣式屬性設置一個顯示值來代替表達式。如果樣式屬性必須根據頁面活動動態設置，用事件綁定代替CSS表達式是一個好的選擇。

8.保持Js和CSS外部引用

有很多性能規則來處理外部組件管理。然而，在考慮這些因素之前，有一個更基本的問題需要考慮：js和css應該包含在外部文件中，還是內聯在頁面里面？

使用外部文件通常會加快頁面速度，因為這樣js,css文件可以被瀏覽器緩存。如果js,css內聯在頁面中，每次請求頁面的時候都會重新加載。這樣雖然減少了http請求數量，但是增加了html的大小。從另一方面來說，如果js,css在外部文件中并且被瀏覽器緩存，那么后續請求不會增加html文檔大小，也不會增加http請求數量(外部文件從瀏覽器緩存中取，不經過http請求了)。

關鍵是html文檔使用緩存的js,css文件的頻率。這個因素盡管難以量化，但是也可以通過其它維度衡量。如果一個站點用戶每個session周期需要訪問多個頁面，并且這多個頁面有共同的腳本和樣式文件，那么使用緩存的文件就有潛在的好處。

一般情況下都是把js,css寫到外部文件中，但是也有例外，內聯適合應用在首頁。首頁的每個session的訪問次數少，內聯js,css可以加快終端的響應時間。

內聯可以降低http請求，使用外部文件緩存也有好處。通常的處理是首頁內聯js,css，當也加載完成之后再動態下載外部文件，這樣后續頁面就可以從瀏覽器緩存中獲取這些文件。

9.減少DNS查詢路徑

域名系統(DNS)是把域名映射到IP地址上，就像手機通訊錄把人名映射到手機號上一樣。當你在瀏覽器輸入www.yahoo.com的時候，DNS解析服務連接到瀏覽器然后返回服務器的IP地址。DNS是有開銷的，一般會花費20-120ms為主機查詢IP地址。瀏覽器不能通過主機名下載任何東西，除非DNS解析已完成。

為了性能考慮DNS查詢都會緩存。這個緩存可能發生在某一臺緩存服務器上面，這個緩存服務器有用戶的ISP或者局域網維護，也有可能緩存到個別用戶電腦上。DNS信息保存在操作系統的DNS緩存中(windows上面的DNS client service)。大部分瀏覽器都是自己的DNS緩存以區分于操作系統的緩存。一旦瀏覽器在自己的緩存中保存了DNS記錄，它就不會從操作系統里面查這條記錄了。

IE默認緩存DNS查詢30分鐘，可以在注冊表DnsCacheTimeout中指定。Firefox默認緩存DNS查詢1分鐘，可以通過network.dnsCacheExpiration配置項設置。

當客戶端的DNS緩存都是空時(瀏覽器和操作系統的),DNS的查詢次數就和頁面中主機的DNS查詢次數一樣。包括頁面url，圖片，腳本樣式文件,flash對象里面的主機名。減少獨立主機名，就可以減少DNS查詢次數。
減少獨立主機名對頁面中需要并行下載的地方有潛在的影響。避免DNS查詢雖然可以減少響應時間，但是減少并行下載也會增加響應時間。這兩者是相互矛盾的，作者的建議是保持2到4個單獨主機，這樣DNS查詢不至于過多，也有一定的并行下載。

和中的代碼塊也應該壓縮。盡管你用gzip壓縮了你的腳本和樣式文件，再次壓縮它們仍然可以減少5%或者更多的體積。隨著使用的js和css越來越多，壓縮代碼可以消減成本。

10.壓縮js和css

壓縮的做法就是移除代碼中不必要的字符減少文件大小進而提升加載速度。代碼一旦被壓縮，所有的注釋，不需要的空白字符(空格，換行，tab)都會被移除。對于Js來說，這會提高響應時間性能，因為要下載的文件大小減少了。常用的壓縮js代碼的工具是JSMin，YUI Compressor。YUICompressor也可以壓縮css。和中的代碼塊也應該壓縮。盡管你用gzip壓縮了你的腳本和樣式文件，再次壓縮它們仍然可以減少5%或者更多的體積。隨著使用的js和css越來越多，壓縮代碼可以消減成本。

代碼混淆是處理源代碼的另一種選擇，它比代碼壓縮更復雜，因此在混淆過程中也更容易產生問題。有調查指出代碼壓縮可以減少21%的大小，代碼混淆可以減少25%的大小。盡快代碼混淆有更高的壓縮率，但是代碼壓縮風險更低。

除了外部的腳本樣式需要壓縮，內聯在<script>和<style>中的代碼塊也應該壓縮。盡管你用gzip壓縮了你的腳本和樣式文件，再次壓縮它們仍然可以減少5%或者更多的體積。隨著使用的js和css越來越多，壓縮代碼可以消減成本。

11.避免重定向

重定向是使用301,302狀態碼來完成的。下面就是一個使用301響應的HTTP header:

HTTP/1.1 301 Moved Permanently

Location: http://example.com/newuri

Content-Type: text/html

瀏覽器自動的把用戶帶到Location字段制定的url中。重定向所有有用額信息都在header里面。響應內容通常是空的。

12.刪除重復Scripts

一個頁面中有兩個一樣的js文件會影響性能。這可能不像你想的那樣不同尋常。當團隊人數及腳本數量增加時，很有可能一個頁面就會引入相同的腳本文件。這種情況發生時，重復的腳本會創建不需要HTTP連接而且多次執行進而會影響性能。不需要的HTTP請求發生在IE瀏覽器中，Firefox不會有這種現象。在IE中，如果一個外部js被引入了兩次并且沒被緩存，它就會在頁面加載時產生兩個HTTP請求。甚至當js被緩存時，當用戶刷新頁面后，額外的HTTP請求也會發生。除了產生浪費的HTTP請求，腳本多次也會浪費時間。這種情況在Firefox以及IE中都會發生，不管js文件有沒有被緩存。

有一種方法可以避免多次引入相同的腳本，那就是在模板系統里面實現一個腳本管理模塊。這樣的話，在HTML頁面中就可以利用script標簽引入腳本管理文件。<script type="text/javascript" src="menu_1.0.17.js"></script>這種方式不僅可以避免相同的腳本插入多次，還可以處理腳本相關的其它情況，比如，依賴檢查，把版本號加到腳本文件名后面就可以實現緩存腳本更新。

13.配置Etags

ETags(Entity tags)是Web服務器和瀏覽器使用的一種機制，來決定瀏覽器中緩存的組件是否匹配源服務器上的組件。（entity和component一樣，代指：圖片，腳本，樣式等）ETags提供了一種可以驗證entities是否修改的機制。一個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傳到源服務器。如果ETags匹配，會返回一個304狀態碼，這樣可以減少12195字節的響應。

GET /i/yahoo.gif HTTP/1.1

Host: us.yimg.comIf-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMTIf-None-Match: "10c24bc-4ab-457e1c1f"HTTP/1.1 304 Not Modified

ETags的問題在于它們通常用屬性來構建，這些屬性使它們對于特定的網站服務器是獨有的。當瀏覽器從服務器獲取源組件，然后嘗試在不同的服務器上驗證這個組件時，ETags不會匹配的。這種情況在使用集群服務器處理請求時很常見。默認情況下，Apache和IIS在ETag中嵌入數據，這樣大大降低了在有多個服務器的站點上進行有效性測試成功的幾率。

Apache 1.3和2.x版本的ETag格式是inode-size-timestamp。盡管一個指定的文件在不同的服務器中保存在相同的目錄，有著相同的大小，權限，時間戳等等，但是不同服務器的inode是不一樣的。

IIS 5.0和6.0版本也有ETags問題。IIS的Etags格式是Filetimestamp:ChangeNumber
。ChangeNumber是一個追蹤IIS配置更改的計數器。一個站點的所有的IIS服務器的ChangeNumber不可能一樣。Apache和IIS的ETags問題導致的結果就是，對于相同的組件在各個服務器之間不會匹配。如果ETags沒有匹配，用戶就不會收到小的，快速的304響應；反而會收到一個正常的200響應和組件內容一起。如果web站點只部署在一臺機器上，就不會有這個問題。但是如果有多臺服務器，而且又使用了Apache或者IIS的默認ETag配置，用戶獲取頁面的速度就不會那么快，服務器有更高的負載，消耗更多的帶寬，代理也不會緩存有效的內容。即使組件有一個很大的過期時間，但是每當用戶點擊重載或刷新時，都會創建一個條件GET請求。

如果你沒有利用ETags提供的靈活驗證模型，最好移除ETag。Last-Modified頭驗證基于組件的時間戳。移除ETag可以減小響應和后續請求的HTTP頭的大小。在Apache中可以通過修改配置文件來實現：FileETag none。

14.使Ajax請求可緩存

使用Ajax的一個好處就是它能給用戶提供及時的響應，因為它從后端異步的獲取數據。然而使用Ajax并不能保證用戶可以立馬得到返回的異步js和xml響應。在許多應用中，用戶是否繼續等待，取決于Ajax如果如何使用。例如在內嵌頁面的郵件客戶端中用戶為了獲取符合搜索條件的郵件消息，會繼續等待Ajax的請求結果。重要的是要記住一點，“異步”并不代表“及時”。

為了提高性能，優化Ajax響應也很重要。提高Ajax性能最重要的方式是緩存響應內容。來看一個例子，一個Web2.0的郵箱客戶端可能使用Ajax來自動下載用戶地址列表。如果用戶從上次使用郵箱web app之后沒有修改過地址列表，那么之前地址列表響應可以從緩存中讀取，如果Ajax響應用Expires或者Cache-Control頭做了緩存。瀏覽器必須知道何時使用緩存地址列表對于一個新請求。可以通過添加一個時間戳到地址列表Ajax url后面，表明用戶修改地址列表的最新時間，例如，&t=1190241612。如果地址列表自從上次下載都沒有被修改，時間戳應該不變，然后就會從瀏覽器緩存中去地址列表，這樣就消除了一個多余的HTTP請求。如果用戶修改了地址列表，時間戳就確保了新的url不會匹配到緩存中的響應，瀏覽器會請求更新的地址列表。

盡管Ajax響應是動態創建的，也可能只適用于單個用戶，也應該被緩存。這樣做可以使你的Web2.0 apps更快。

15.盡早刷新緩存

當用戶請求一個頁面時，后端可能會消耗200或者500ms來整合HTML頁面。在這段時間內，瀏覽器處在等待服務器返回數據的空閑狀態。在PHP中，可以使用flush()函數。它可以讓服務器發送部分準備好的html響應給瀏覽器，然后當后端正在處理html頁面的其余部分時，瀏覽器可以開始獲取內容。

刷新緩存的最佳位置是在HEAD標簽之后，因為HTML頁面的head通常更容易產生，而且它可以引入任何CSS和JS文件，這樣當后端還在處理時，瀏覽器也可以開始并行的下載引用文件。

... <!-- css, js --></head><?php flush(); ?><body>

... <!-- content -->

16.使用GET方式的Ajax請求

雅虎郵件團隊發現當使用XMLHttpRequest時，瀏覽器器實施POST請求有兩步，第一步發送headers,然后發送數據。所以最好使用GET請求，它只發一個TCP包（除非cookie數量很多）。在IE中url的最大長度是2K，如果數據超過2K，不能使用GET請求。

如果POST請求沒有發送數據，那么它的行為就像POST一樣?；贖TTP協議，GET請求是用來獲取信息的，所以當你僅僅是獲取數據而不是向服務端發送數據時，最好使用GET請求。

17.延遲加載組件

看一眼頁面，然后思考下：“那些是一定需要在初始化渲染頁面時？”。其余的內容和組件都可以延遲獲取。

js文件是一個理想的備選項。例如如果js代碼或者庫是用來實現拖拽，動畫效果的，那么就可以等待加載，因為頁面中的拖拽元素在初始化渲染之后的。考慮可以延遲加載組件時也包括隱藏內容（在用戶某個行為之后的才出現的內容）和圖片的修飾。

當性能目標存在于其他web開發最佳實踐中是非常好的。在這種情況下，漸進增強告訴我們js可以提升用戶體驗，但是必須確保頁面沒有js時也可以正常工作。因此當你確定頁面正常后，你可以用一些延時加載js來增強頁面效果。

18.預加載組件

預加載看起來和延遲加載相反，但是它有不同的目的。通過預加載組件，你可以充分利用瀏覽器空閑時間獲取需要的組件（圖片，樣式文件，腳本文件）。這樣當用戶訪問下個頁面時，你可能已經把大部分組件緩存到瀏覽器緩存，然后頁面加載時就會更快。有下面幾種類型的預加載：

無條件預加載：一旦開始加載，你就開始獲取一些額外的組件。拿google.com作為例子，看下一張sprite圖片時如何請求加載的。這張sprite圖片google首頁并不需要，但是在搜索結果頁面需要。
有條件預加載：基于用戶行為，你做了一個猜測用戶下一步要去那個頁面，然后預加載響應的東西。在search.yahoo.com站點你會發現當你開始在輸入框輸入時，一些額外的組件時如何被請求的。
預期預加載：發新版本時提前加載。發布新版后，可能會有這樣的抱怨“新本很酷，但是速度比之前慢”。

一部分原因可能是用戶訪問之前版本時有了充分的緩存，但是新版本剛開始沒有緩存。你可以消除這方面的影響通過預加載一些組件，在你發新版之前。舊站點可以利用瀏覽器的空閑時間加載新版要使用的圖片和腳本。

19.減少DOM元素數量

一個復雜的頁面意味著要下載更多的字節，js中更慢的DOM訪問速度。例如當你遍歷500個或者5000個dom元素添加時間處理時是不同的。

大量的dom元素可能意味著有些頁面標記需要被改進而不一定需要刪除一些內容。你是否有過嵌套表格達到布局目的？使用很多<div>僅僅是修復布局問題？也許對標記來說有更好的語義正確的方式。

dom元素的數量很好測試，在Firebug控制臺輸入：document.getElementsByTagName("*").length。

但是多少dom元素算多呢？可以參考下有良好標記的類似頁面。

20.跨域分離組件

分離組件可以最大化的并行下載?？紤]到DNS查考消耗，確保使用不超過2到4個域。例如你可以托管HMTL和動態內容在www.example.org，將靜態組件放在static1.example.org和static2.example.org上面。

21.減少iframe

iframe允許把html文檔內嵌到父文檔中。理解iframe的工作原理有助于更有效的使用iframe。

iframe優點：有助于緩沖第三方內容，像廣告；安全沙箱；并行下載js；
iframe缺點:即使是空白標簽也有消耗；阻塞頁面加載；非語義；

22.不要404

HTTP請求是費時操作，所以發HTTP請求但是獲取一個無用響應（例如404）是完全沒必要的，也會降低用戶體驗而么有任何好處。

有些站點有一些有用的404內容，這有助于提高用戶體驗，但是仍然會浪費服務端的資源（像數據庫等）。當引入的一個外部js文件是有問題的而且找不到的時候，這種情況是很糟糕的。首先這次下載會阻塞并行下載，然后瀏覽器可能會把404響應內容當成js代碼解析，找出一些有用的東西。

23.減少Cookie大小

之所以會使用HTTP cookies是有多種理由的，例如權限，個性化。cookies的信息在瀏覽器和服務端通過HTTP頭交換。盡量減少cookies大小有助于減少用戶響應時間。

24.組件使用沒有cookie的域

當瀏覽器請求一個靜態圖片時，會隨請求發送cookies到服務器，但是這些cookies在服務端又沒什么用。只會增加網絡流量。應該確保靜態組件響應沒有cookie請求?？梢詣摻ㄒ蛔佑驅ｉT托管靜態組件。

假設你的域名是www.forever-japan.cn，你可以把靜態組件托管在static.zishenwang.com。如果你已經在頂級域名zishenwang.com上面設置了cookie而不是在www.forever-japan.cn上面設置，那么所有的經過static.zishenwang.com的請求都會攜帶cookie。這種情況你可以買一個新域名，把靜態組件托管到新域名上，并保持這個域名沒有cookie。

把靜態文件托管在無cookie的域，還有一個好處就是，有些代理可能不會緩存那些請求中帶cookie的靜態組件。如果你想知道你是應該用zishenwang.com或者static.zishenwang.com作為主頁，考慮下cookie的影響。如果忽略www,會把cookie寫到*.zishenwang.com中，所以為了性能考慮最好使用帶www的子域并且把cookie寫到子域。

25.減少DOM訪問次數

js訪問DOM元素也是耗時操作，為了更好的頁面響應，你最好做到下面幾點：

緩存訪問到的元素引用
更新"離線"節點添加到DOM樹中避免用js操作布局

26.優化事件處理

有時頁面可能會響應延時，因為DOM樹中不同元素上綁定了太多的事件，然后這些事件執行的太頻繁了。這就是為什么事件委托是一個好的方法。如果在一個div里面有10個button,可以給div綁定一個事件而不是給每一個button綁定事件。因為有事件冒泡，所以你可以捕獲到這個事件，并且可以定位出來自于那個button。

如果你想開始對DOM樹做點什么，你并不需要等待onload事件。通常你需要確定是你要獲取的標簽在DOM樹中已經可用。你也沒必要等待所有的圖片都被下載。等到所有瀏覽器都支持DOMContentLoad事件，你可以用DOMContentLoad事件代替onload事件。

27.選擇<link>而不是@import

前面的最佳實踐有一點就是把CSS放到頂部，這樣可以漸進渲染。在IE中@import的行為和在頁面底部使用<link>的效果一樣，所以最好不要使用它。

28.避免Filter

IE有個屬性AlphaImageLoader filter，這個屬性主要為了實現真彩色的PNG圖片在IE7以下中的半透明效果。當瀏覽器正在下載圖片時，使用這個filter會阻塞渲染讓瀏覽器停止響應。它也會增加內存開銷，會作用于每個元素而不是每個圖片。

最好的方式是完全避免使用AlphaImageLoader，使用PNG8代替，PNG8對IE友好。如果必須要使用AlphaImageLoader，使用下劃線hack _filter以防對使用IE7+的用戶不利。

29.優化Images

設計師為網頁設計好圖片之后，在傳到服務器上面之前還有很多事情要做。

你可以檢查下GIFs，看看他們使用的調色板大小是佛對應圖片顏色數。使用imagemagick工具，非常容易檢查，使用命令 -verbose image.gif。當你看到一個圖片使用了4種顏色，一個256顏色“槽”在調色板中，這說明還是有提升空間的。

嘗試把GIFs轉成PNGs，看下大小是否減少了。通常是有所減小的。開發者經常在使用PNG時猶豫，擔心瀏覽器支持限制，但是現在這種事不會發生了。現在唯一要擔心的是真彩色PNG的透明度通道，GIF不是真彩色，不支持透明度變化。因此GIF可以做的，PNG也可以做（動畫除外）。在imagemagick工具中使用下面命令可以安全的使用PNG：convert image.gif image.png在pngcrush工具(PNG優化工具)中處理所有的PNG。在jpegtran工具中處理所有的JPEG。這個工具無損JPEG操作，可以用來優化移除圖片中的注解以及無用信息（例如EXIF信息）。

30.優化CSS Sprites

在sprite中水平排列圖片比垂直排列圖片更?？臻g。

在sprite中組合同類色可以降低顏色數量。理想情況下小于256色，這樣更適應PNG8。保持移動友好性，sprite中的圖片之間不要留大的空白。這樣雖然對文件大小沒多少影響，但是用戶代理可以更少的內存把圖片解壓成像素地圖。100X100的圖片有一萬個像素，1000X1000就有一百萬個像素。

31.不要在HTML中使用過大的Images

不要使用超過你需要的大圖片，因為你可以在HTML中設置寬高。如果你需要<img width="100" height="100" src="mycat.jpg" alt="My Cat" />，那么你的圖片（mycat.jpg）應該是100X100，而不是500X500。

32.favicon.ico最小化以及可緩存

favicon.ico存在服務端根目錄。即使你不關注它，但是瀏覽器仍然需要請求它，因此最好不要用404響應。因為在同一臺服務器上面，瀏覽器每次請求它時也會帶著cookie。這個圖片也會干擾下載序列，例如在IE瀏覽器中當你請求額外的組件，favicon會在這些組件之前下載。所以為了減少favicon的缺點，需要做到下面幾點：
使用小的favicon，最好1K一下。設置一個你認為合適的Expires header。你可以設置Expires header為幾個月。為了做明智的決定，你可以檢查favicon.icon的上次修改時間。

33.內容保持在25K以下

這個限制是基于這樣一個事實，iphone不會緩存超過25K的內容。注意這是未壓縮大小。這也說明了壓縮的重要性，但是僅僅gzip壓縮是不夠的。

34.把內容打包成一個復合文檔

把內容打包成一個復合文檔相當于帶附件的郵件，可以讓你通過一個HTTP請求獲取多個內容。使用這項技術之前，先確認下用戶代理是否支持這種技術。

35.避免空的Image src

空src屬性的Image經常會出現。主要有兩種形式：

HTML形式：<img src="">
js形式：var img = new Image(); img.src = "";

這兩種形式都有同樣的影響：瀏覽器給服務端發送另外的請求。

IE對當前頁所在目錄發請求。Safari和Chrome對當前頁面本身發請求。Firefox3和之前的版本行為和Safari和Chrome一樣，但是3.5以上版本不會發請求。Opera碰到這種情況也不會發請求。

本文原作者：留七七 原文鏈接鏈接：https://www.jianshu.com/p/d75555313845，本文鏈接：http://www.forever-japan.cn/zyh/16。

本文由資深網整理發布，如有侵權請聯系刪除。