摘要：無(wú)論是在工作中，還是在面試中，web前端性能的優(yōu)化都是很重要的，那么我們進(jìn)行優(yōu)化需要從哪些方面入手呢？可以遵循雅虎的前端優(yōu)化34條軍規(guī)，不過(guò)現(xiàn)在已經(jīng)是35條了，所以可以說(shuō)是雅虎前端優(yōu)化的35條軍規(guī)。已分類(lèi)，挺好的，這樣對(duì)于優(yōu)化有一個(gè)比較清晰的方向

內(nèi)容部分

1.盡量減少HTTP請(qǐng)求數(shù)

80%的終端用戶響應(yīng)時(shí)間都花在了前端上，其中大部分時(shí)間都在下載頁(yè)面上的各種組件：圖片，樣式表，腳本，F(xiàn)lash等等。減少組件數(shù)必然能夠減少頁(yè)面提交的HTTP請(qǐng)求數(shù)。這是讓頁(yè)面更快的關(guān)鍵。

減少頁(yè)面組件數(shù)的一種方式是簡(jiǎn)化頁(yè)面設(shè)計(jì)。但有沒(méi)有一種方法可以在構(gòu)建復(fù)雜的頁(yè)面同時(shí)加快響應(yīng)時(shí)間呢？嗯，確實(shí)有魚(yú)和熊掌兼得的辦法。

合并文件是通過(guò)把所有腳本放在一個(gè)文件中的方式來(lái)減少請(qǐng)求數(shù)的，當(dāng)然，也可以合并所有的CSS。如果各個(gè)頁(yè)面的腳本和樣式不一樣的話，合并文件就是一項(xiàng)比較麻煩的工作了，但把這個(gè)作為站點(diǎn)發(fā)布過(guò)程的一部分確實(shí)可以提高響應(yīng)時(shí)間。

CSS Sprites是減少圖片請(qǐng)求數(shù)量的首選方式。把背景圖片都整合到一張圖片中，然后用CSS的background-image和background-position屬性來(lái)定位要顯示的部分。

圖像映射可以把多張圖片合并成單張圖片，總大小是一樣的，但減少了請(qǐng)求數(shù)并加速了頁(yè)面加載。圖片映射只有在圖像在頁(yè)面中連續(xù)的時(shí)候才有用，比如導(dǎo)航條。給image map設(shè)置坐標(biāo)的過(guò)程既無(wú)聊又容易出錯(cuò)，用image map來(lái)做導(dǎo)航也不容易，所以不推薦用這種方式。

行內(nèi)圖片（Base64編碼）用data: URL模式來(lái)把圖片嵌入頁(yè)面。這樣會(huì)增加HTML文件的大小，把行內(nèi)圖片放在（緩存的）樣式表中是個(gè)好辦法，而且成功避免了頁(yè)面變“重”。但目前主流瀏覽器并不能很好地支持行內(nèi)圖片。

減少頁(yè)面的HTTP請(qǐng)求數(shù)是個(gè)起點(diǎn)，這是提升站點(diǎn)首次訪問(wèn)速度的重要指導(dǎo)原則。

2.減少DNS查找

域名系統(tǒng)建立了主機(jī)名和IP地址間的映射，就像電話簿上人名和號(hào)碼的映射一樣。當(dāng)你在瀏覽器輸入www.yahoo.com的時(shí)候，瀏覽器就會(huì)聯(lián)系DNS解析器返回服務(wù)器的IP地址。DNS是有成本的，它需要20到120毫秒去查找給定主機(jī)名的IP地址。在DNS查找完成之前，瀏覽器無(wú)法從主機(jī)名下載任何東西。

DNS查找被緩存起來(lái)更高效，由用戶的ISP（網(wǎng)絡(luò)服務(wù)提供商）或者本地網(wǎng)絡(luò)存在一個(gè)特殊的緩存服務(wù)器上，但還可以緩存在個(gè)人用戶的計(jì)算機(jī)上。DNS信息被保存在操作系統(tǒng)的DNS cache(微軟Windows上的”DNS客戶端服務(wù)”)里。大多數(shù)瀏覽器有獨(dú)立于操作系統(tǒng)的自己的cache。只要瀏覽器在自己的cache里還保留著這條記錄，它就不會(huì)向操作系統(tǒng)查詢(xún)DNS。

IE默認(rèn)緩存DNS查找30分鐘，寫(xiě)在DnsCacheTimeout注冊(cè)表設(shè)置中。Firefox緩存1分鐘，可以用network.dnsCacheExpiration配置項(xiàng)設(shè)置。(Fasterfox把緩存時(shí)間改成了1小時(shí) P.S. Fasterfox是FF的一個(gè)提速插件)

如果客戶端的DNS cache是空的（包括瀏覽器的和操作系統(tǒng)的），DNS查找數(shù)等于頁(yè)面上不同的主機(jī)名數(shù)，包括頁(yè)面URL，圖片，腳本文件，樣式表，F(xiàn)lash對(duì)象等等組件中的主機(jī)名，減少不同的主機(jī)名就可以減少DNS查找。

減少不同主機(jī)名的數(shù)量同時(shí)也減少了頁(yè)面能夠并行下載的組件數(shù)量，避免DNS查找削減了響應(yīng)時(shí)間，而減少并行下載數(shù)量卻增加了響應(yīng)時(shí)間。我的原則是把組件分散在2到4個(gè)主機(jī)名下，這是同時(shí)減少DNS查找和允許高并發(fā)下載的折中方案。

3.避免重定向

重定向用301和302狀態(tài)碼，下面是一個(gè)有301狀態(tài)碼的HTTP頭：

HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html

瀏覽器會(huì)自動(dòng)跳轉(zhuǎn)到Location域指明的URL。重定向需要的所有信息都在HTTP頭部，而響應(yīng)體一般是空的。其實(shí)額外的HTTP頭，比如Expires和Cache-Control也表示重定向。除此之外還有別的跳轉(zhuǎn)方式：refresh元標(biāo)簽和JavaScript，但如果你必須得做重定向，最好用標(biāo)準(zhǔn)的3xxHTTP狀態(tài)碼，主要是為了讓返回按鈕能正常使用。

牢記重定向會(huì)拖慢用戶體驗(yàn)，在用戶和HTML文檔之間插入重定向會(huì)延遲頁(yè)面上的所有東西，頁(yè)面無(wú)法渲染，組件也無(wú)法開(kāi)始下載，直到HTML文檔被送達(dá)瀏覽器。

有一種常見(jiàn)的極其浪費(fèi)資源的重定向，而且web開(kāi)發(fā)人員一般都意識(shí)不到這一點(diǎn)，就是URL尾部缺少一個(gè)斜線的時(shí)候。例如，跳轉(zhuǎn)到http://astrology.yahoo.com/astrology會(huì)返回一個(gè)重定向到http://astrology.yahoo.com/astrology/的301響應(yīng)（注意添在尾部的斜線）。在Apache中可以用Alias，mod_rewrite或者DirectorySlash指令來(lái)取消不必要的重定向。

重定向最常見(jiàn)的用途是把舊站點(diǎn)連接到新的站點(diǎn)，還可以連接同一站點(diǎn)的不同部分，針對(duì)用戶的不同情況（瀏覽器類(lèi)型，用戶帳號(hào)類(lèi)型等等）做一些處理。用重定向來(lái)連接兩個(gè)網(wǎng)站是最簡(jiǎn)單的，只需要少量的額外代碼。雖然在這些時(shí)候使用重定向減少了開(kāi)發(fā)人員的開(kāi)發(fā)復(fù)雜度，但降低了用戶體驗(yàn)。一種替代方案是用Alias和mod_rewrite，前提是兩個(gè)代碼路徑都在相同的服務(wù)器上。如果是因?yàn)橛蛎兓褂昧酥囟ㄏ?，就可以?chuàng)建一條CNAME（創(chuàng)建一個(gè)指向另一個(gè)域名的DNS記錄作為別名）結(jié)合Alias或者mod_rewrite指令。

4.讓Ajax可緩存

Ajax的一個(gè)好處是可以給用戶提供即時(shí)反饋，因?yàn)樗軌驈暮笈_(tái)服務(wù)器異步請(qǐng)求信息。然而，用了Ajax就無(wú)法保證用戶在等待異步JavaScript和XML響應(yīng)返回期間不會(huì)非常無(wú)聊。在很多應(yīng)用程序中，用戶能夠一直等待取決于如何使用Ajax。例如，在基于web的電子郵件客戶端中，用戶為了尋找符合他們搜索標(biāo)準(zhǔn)的郵件消息，將會(huì)保持對(duì)Ajax請(qǐng)求返回結(jié)果的關(guān)注。重要的是，要記得“異步”并不意味著“即時(shí)”。

要提高性能，優(yōu)化這些Ajax響應(yīng)至關(guān)重要。最重要的提高Ajax性能的方法就是讓響應(yīng)變得可緩存，就像在添上Expires或者Cache-Control HTTP頭中討論的一樣。下面適用于Ajax的其它規(guī)則：

1. Gzip組件
2. 減少DNS查找
3. 壓縮JavaScript
4. 避免重定向
5. 配置ETags

我們一起看看例子，一個(gè)Web 2.0的電子郵件客戶端用了Ajax來(lái)下載用戶的通訊錄，以便實(shí)現(xiàn)自動(dòng)完成功能。如果用戶從上一次使用之后再?zèng)]有修改過(guò)她的通訊錄，而且Ajax響應(yīng)是可緩存的，有尚未過(guò)期的Expires或者Cache-Control HTTP頭，那么之前的通訊錄就可以從緩存中讀出。必須通知瀏覽器，應(yīng)該繼續(xù)使用之前緩存的通訊錄響應(yīng)，還是去請(qǐng)求一個(gè)新的。可以通過(guò)給通訊錄的Ajax URL里添加一個(gè)表明用戶通訊錄最后修改時(shí)間的時(shí)間戳來(lái)實(shí)現(xiàn)，例如&t=1190241612。如果通訊錄從上一次下載之后再?zèng)]有被修改過(guò)，時(shí)間戳不變，通訊錄就將從瀏覽器緩存中直接讀出，從而避免一次額外的HTTP往返消耗。如果用戶已經(jīng)修改了通訊錄，時(shí)間戳也可以確保新的URL不會(huì)匹配緩存的響應(yīng)，瀏覽器將請(qǐng)求新的通訊錄條目。

即使Ajax響應(yīng)是動(dòng)態(tài)創(chuàng)建的，而且可能只適用于單用戶，它們也可以被緩存，而這樣會(huì)讓你的Web 2.0應(yīng)用更快。

5.延遲加載組件

可以湊近看看頁(yè)面并問(wèn)自己：什么才是一開(kāi)始渲染頁(yè)面所必須的？其余內(nèi)容都可以等會(huì)兒。

JavaScript是分隔onload事件之前和之后的一個(gè)理想選擇。例如，如果有JavaScript代碼和支持拖放以及動(dòng)畫(huà)的庫(kù)，這些都可以先等會(huì)兒，因?yàn)橥戏旁厥窃陧?yè)面最初渲染之后的。其它可以延遲加載的部分包括隱藏內(nèi)容（在某個(gè)交互動(dòng)作之后才出現(xiàn)的內(nèi)容）和折疊的圖片。

工具可幫你減輕工作量：YUI Image Loader可以延遲加載折疊的圖片，還有YUI Get utility是一種引入JS和CSS的簡(jiǎn)單方法。Yahoo!主頁(yè)就是一個(gè)例子，可以打開(kāi)Firebug的網(wǎng)絡(luò)面板仔細(xì)看看。

最好讓性能目標(biāo)符合其它web開(kāi)發(fā)最佳實(shí)踐，比如“漸進(jìn)增強(qiáng)”。如果客戶端支持JavaScript，可以提高用戶體驗(yàn)，但必須確保頁(yè)面在不支持JavaScript時(shí)也能正常工作。所以，在確定頁(yè)面運(yùn)行正常之后，可以用一些延遲加載腳本增強(qiáng)它，以支持一些拖放和動(dòng)畫(huà)之類(lèi)的華麗效果。

6.預(yù)加載組件

預(yù)加載可能看起來(lái)和延遲加載是相反的，但它其實(shí)有不同的目標(biāo)。通過(guò)預(yù)加載組件可以充分利用瀏覽器空閑的時(shí)間來(lái)請(qǐng)求將來(lái)會(huì)用到的組件（圖片，樣式和腳本）。用戶訪問(wèn)下一頁(yè)的時(shí)候，大部分組件都已經(jīng)在緩存里了，所以在用戶看來(lái)頁(yè)面會(huì)加載得更快。

實(shí)際應(yīng)用中有以下幾種預(yù)加載的類(lèi)型：

1. 無(wú)條件預(yù)加載——盡快開(kāi)始加載，獲取一些額外的組件。google.com就是一個(gè)sprite圖片預(yù)加載的好例子，這個(gè)sprite圖片并不是google.com主頁(yè)需要的，而是搜索結(jié)果頁(yè)面上的內(nèi)容。
2. 條件性預(yù)加載——根據(jù)用戶操作猜測(cè)用戶將要跳轉(zhuǎn)到哪里并據(jù)此預(yù)加載。在search.yahoo.com的輸入框里鍵入內(nèi)容后，可以看到那些額外組件是怎樣請(qǐng)求加載的。
3. 提前預(yù)加載——在推出新設(shè)計(jì)之前預(yù)加載。經(jīng)常在重新設(shè)計(jì)之后會(huì)聽(tīng)到：“這個(gè)新網(wǎng)站不錯(cuò)，但比以前更慢了”，一部分原因是用戶訪問(wèn)先前的頁(yè)面都是有舊緩存的，但新的卻是一種空緩存狀態(tài)下的體驗(yàn)?？梢酝ㄟ^(guò)在將要推出新設(shè)計(jì)之前預(yù)加載一些組件來(lái)減輕這種負(fù)面影響，老站可以利用瀏覽器空閑的時(shí)間來(lái)請(qǐng)求那些新站需要的圖片和腳本。

 7.減少DOM元素的數(shù)量

一個(gè)復(fù)雜的頁(yè)面意味著要下載更多的字節(jié)，而且用JavaScript訪問(wèn)DOM也會(huì)更慢。舉個(gè)例子，想要添加一個(gè)事件處理器的時(shí)候，循環(huán)遍歷頁(yè)面上的500個(gè)DOM元素和5000個(gè)DOM元素是有區(qū)別的。

大量的DOM元素是一種征兆——頁(yè)面上有些內(nèi)容無(wú)關(guān)的標(biāo)記需要清理。正在用嵌套表格來(lái)布局嗎？還是為了修復(fù)布局問(wèn)題而添了一堆的<div>s？或許應(yīng)該用更好的語(yǔ)義化標(biāo)記。

YUI CSS utilities對(duì)布局有很大幫助：grids.css針對(duì)整體布局，fonts.css和reset.css可以用來(lái)去除瀏覽器的默認(rèn)格式。這是個(gè)開(kāi)始清理和思考標(biāo)記的好機(jī)會(huì)，例如只在語(yǔ)義上有意義的時(shí)候使用<div>，而不是因?yàn)樗軌蜾秩疽粋€(gè)新行。

DOM元素的數(shù)量很容易測(cè)試，只需要在Firebug的控制臺(tái)里輸入：

document.getElementsByTagName('*').length

那么多少DOM元素才算是太多呢？可以參考其它類(lèi)似的標(biāo)記良好的頁(yè)面，例如Yahoo!主頁(yè)是一個(gè)相當(dāng)繁忙的頁(yè)面，但只有不到700個(gè)元素（HTML標(biāo)簽）。

8.跨域分離組件

分離組件可以最大化并行下載，但要確保只用不超過(guò)2-4個(gè)域，因?yàn)榇嬖贒NS查找的代價(jià)。例如，可以把HTML和動(dòng)態(tài)內(nèi)容部署在www.example.org，而把靜態(tài)組件分離到static1.example.org和static2.example.org。

9.盡量少用iframe

用iframe可以把一個(gè)HTML文檔插入到父文檔里，重要的是明白iframe是如何工作的并高效地使用它。

<iframe>的優(yōu)點(diǎn)：

1. 引入緩慢的第三方內(nèi)容，比如標(biāo)志和廣告
2. 安全沙箱
3. 并行下載腳本

<iframe>的缺點(diǎn)：

1. 代價(jià)高昂，即使是空白的iframe
2. 阻塞頁(yè)面加載
3. 非語(yǔ)義

10.杜絕404

HTTP請(qǐng)求代價(jià)高昂，完全沒(méi)有必要用一個(gè)HTTP請(qǐng)求去獲取一個(gè)無(wú)用的響應(yīng)（比如404 Not Found），只會(huì)拖慢用戶體驗(yàn)而沒(méi)有任何好處。

有些站點(diǎn)用的是有幫助的404——“你的意思是xxx？”，這樣做有利于用戶體驗(yàn)，，但也浪費(fèi)了服務(wù)器資源（比如數(shù)據(jù)庫(kù)等等）。最糟糕的是鏈接到的外部JavaScript有錯(cuò)誤而且結(jié)果是404。首先，這種下載將阻塞并行下載。其次，瀏覽器會(huì)試圖解析404響應(yīng)體，因?yàn)樗荍avaScript代碼，需要找出其中可用的部分。

css部分

11.避免使用CSS表達(dá)式

用CSS表達(dá)式動(dòng)態(tài)設(shè)置CSS屬性，是一種強(qiáng)大又危險(xiǎn)的方式。從IE5開(kāi)始支持，但從IE8起就不推薦使用了。例如，可以用CSS表達(dá)式把背景顏色設(shè)置成按小時(shí)交替的：

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" ); 

12.選擇<link>舍棄@import

前面提到了一個(gè)最佳實(shí)踐：為了實(shí)現(xiàn)逐步渲染，CSS應(yīng)該放在頂部。

在IE中用@import與在底部用<link>效果一樣，所以最好不要用它。

13.避免使用濾鏡

IE專(zhuān)有的AlphaImageLoader濾鏡可以用來(lái)修復(fù)IE7之前的版本中半透明PNG圖片的問(wèn)題。在圖片加載過(guò)程中，這個(gè)濾鏡會(huì)阻塞渲染，卡住瀏覽器，還會(huì)增加內(nèi)存消耗而且是被應(yīng)用到每個(gè)元素的，而不是每個(gè)圖片，所以會(huì)存在一大堆問(wèn)題。

最好的方法是干脆不要用AlphaImageLoader，而優(yōu)雅地降級(jí)到用在IE中支持性很好的PNG8圖片來(lái)代替。如果非要用AlphaImageLoader，應(yīng)該用下劃線hack：_filter來(lái)避免影響IE7及更高版本的用戶。

14.把樣式表放在頂部

在Yahoo!研究性能的時(shí)候，我們發(fā)現(xiàn)把樣式表放到文檔的HEAD部分能讓頁(yè)面看起來(lái)加載地更快。這是因?yàn)榘褬邮奖矸旁趆ead里能讓頁(yè)面逐步渲染。

關(guān)注性能的前端工程師想讓頁(yè)面逐步渲染。也就是說(shuō)，我們想讓瀏覽器盡快顯示已有內(nèi)容，這在頁(yè)面上有一大堆內(nèi)容或者用戶網(wǎng)速很慢時(shí)顯得尤為重要。給用戶顯示反饋（比如進(jìn)度指標(biāo)）的重要性已經(jīng)被廣泛研究過(guò)，并且被記錄下來(lái)了。在我們的例子中，HTML頁(yè)面就是進(jìn)度指標(biāo)！當(dāng)瀏覽器逐漸加載頁(yè)面頭部，導(dǎo)航條，頂部logo等等內(nèi)容的時(shí)候，這些都被正在等待頁(yè)面加載的用戶當(dāng)作反饋，能夠提高整體用戶體驗(yàn)。

js部分

15.去除重復(fù)腳本

頁(yè)面含有重復(fù)的腳本文件會(huì)影響性能，這可能和你想象的不一樣。在對(duì)美國(guó)前10大web站點(diǎn)的評(píng)審中，發(fā)現(xiàn)只有2個(gè)站點(diǎn)含有重復(fù)腳本。兩個(gè)主要原因增加了在單一頁(yè)面中出現(xiàn)重復(fù)腳本的幾率：團(tuán)隊(duì)大小和腳本數(shù)量。在這種情況下，重復(fù)腳本會(huì)創(chuàng)建不必要的HTTP請(qǐng)求，執(zhí)行無(wú)用的JavaScript代碼，而影響頁(yè)面性能。

IE會(huì)產(chǎn)生不必要的HTTP請(qǐng)求，而Firefox不會(huì)。在IE中，如果一個(gè)不可緩存的外部腳本被頁(yè)面引入了兩次，它會(huì)在頁(yè)面加載時(shí)產(chǎn)生兩個(gè)HTTP請(qǐng)求。即使腳本是可緩存的，在用戶重新加載頁(yè)面時(shí)也會(huì)產(chǎn)生額外的HTTP請(qǐng)求。

除了產(chǎn)生沒(méi)有意義的HTTP請(qǐng)求之外，多次對(duì)腳本求值也會(huì)浪費(fèi)時(shí)間。因?yàn)闊o(wú)論腳本是否可緩存，在Firefox和IE中都會(huì)執(zhí)行冗余的JavaScript代碼。

避免不小心把相同腳本引入兩次的一種方法就是在模版系統(tǒng)中實(shí)現(xiàn)腳本管理模塊。典型的腳本引入方法就是在HTML頁(yè)面中用SCRIPT標(biāo)簽：

 <script type="text/javascript" src="menu_1.0.17.js"></script> 

16.盡量減少DOM訪問(wèn)

用JavaScript訪問(wèn)DOM元素是很慢的，所以，為了讓頁(yè)面反應(yīng)更迅速，應(yīng)該：

1. 緩存已訪問(wèn)過(guò)的元素的索引
2. 先“離線”更新節(jié)點(diǎn)，再把它們添到DOM樹(shù)上
3. 避免用JavaScript修復(fù)布局問(wèn)題 

17.用智能的事件處理器

有時(shí)候感覺(jué)頁(yè)面反映不夠靈敏，是因?yàn)橛刑囝l繁執(zhí)行的事件處理器被添加到了DOM樹(shù)的不同元素上，這就是推薦使用事件委托的原因。如果一個(gè)div里面有10個(gè)按鈕，應(yīng)該只給div容器添加一個(gè)事件處理器，而不是給每個(gè)按鈕都添加一個(gè)。事件能夠冒泡，所以可以捕獲事件并得知哪個(gè)按鈕是事件源。

18.把腳本放在底部

腳本會(huì)阻塞并行下載，HTTP/1.1官方文檔建議瀏覽器每個(gè)主機(jī)名下并行下載的組件數(shù)不要超過(guò)兩個(gè)，如果圖片來(lái)自多個(gè)主機(jī)名，并行下載的數(shù)量就可以超過(guò)兩個(gè)。如果腳本正在下載，瀏覽器就不開(kāi)始任何其它下載任務(wù)，即使是在不同主機(jī)名下的。

有時(shí)候，并不容易把腳本移動(dòng)到底部。舉個(gè)例子，如果腳本是用document.write插入到頁(yè)面內(nèi)容中的，就沒(méi)辦法再往下移了。還可能存在作用域問(wèn)題，在多數(shù)情況下，這些問(wèn)題都是可以解決的。

一個(gè)常見(jiàn)的建議是用推遲（deferred）腳本，有DEFER屬性的腳本意味著不能含有document.write，并且提示瀏覽器告訴他們可以繼續(xù)渲染。不幸的是，F(xiàn)irefox不支持DEFER屬性。在IE中，腳本可能被推遲，但不盡如人意。如果腳本可以推遲，我們就可以把它放到頁(yè)面底部，頁(yè)面就可以更快地載入。

javascript, css

19.把JavaScript和CSS放到外面

很多性能原則都是關(guān)于如何管理外部組件的，然而，在這些顧慮出現(xiàn)之前你應(yīng)該問(wèn)一個(gè)更基礎(chǔ)的問(wèn)題：應(yīng)該把JavaScript和CSS放到外部文件中還是直接寫(xiě)在頁(yè)面里？

實(shí)際上，用外部文件可以讓頁(yè)面更快，因?yàn)镴avaScript和CSS文件會(huì)被緩存在瀏覽器。HTML文檔中的行內(nèi)JavaScript和CSS在每次請(qǐng)求該HTML文檔的時(shí)候都會(huì)重新下載。這樣做減少了所需的HTTP請(qǐng)求數(shù)，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS在外部文件中，并且已經(jīng)被瀏覽器緩存起來(lái)了，那么我們就成功地把HTML文檔變小了，而且還沒(méi)有增加HTTP請(qǐng)求數(shù)。

20.壓縮JavaScript和CSS

壓縮具體來(lái)說(shuō)就是從代碼中去除不必要的字符以減少大小，從而提升加載速度。代碼最小化就是去掉所有注釋和不必要的空白字符（空格，換行和tab）。在JavaScript中這樣做能夠提高響應(yīng)性能，因?yàn)橐螺d的文件變小了。兩個(gè)最常用的JavaScript代碼壓縮工具是JSMin和YUI Compressor，YUI compressor還可以壓縮CSS。

混淆是一種可選的源碼優(yōu)化措施，要比壓縮更復(fù)雜，所以混淆過(guò)程也更容易產(chǎn)生bug。在對(duì)美國(guó)前十的網(wǎng)站調(diào)查中，壓縮可以縮小21%，而混淆能縮小25%。雖然混淆的縮小程度更高，但比壓縮風(fēng)險(xiǎn)更大。

除了壓縮外部腳本和樣式，行內(nèi)的<script>和<style>塊也可以壓縮。即使啟用了gzip模塊，先進(jìn)行壓縮也能夠縮小5%或者更多的大小。JavaScript和CSS的用處越來(lái)越多，所以壓縮代碼會(huì)有不錯(cuò)的效果。

圖片

21.優(yōu)化圖片

嘗試把GIF格式轉(zhuǎn)換成PNG格式，看看是否節(jié)省空間。在所有的PNG圖片上運(yùn)行pngcrush（或者其它PNG優(yōu)化工具）

22.優(yōu)化CSS Sprite

1. 在Sprite圖片中橫向排列一般都比縱向排列的最終文件小
2. 組合Sprite圖片中的相似顏色可以保持低色數(shù)，最理想的是256色以下PNG8格式
3. “對(duì)移動(dòng)端友好”，不要在Sprite圖片中留下太大的空隙。雖然不會(huì)在很大程度上影響圖片文件的大小，但這樣做可以節(jié)省用戶代理把圖片解壓成像素映射時(shí)消耗的內(nèi)存。100×100的圖片是1萬(wàn)個(gè)像素，而1000×1000的圖片就是100萬(wàn)個(gè)像素了。

23.不要用HTML縮放圖片

不要因?yàn)樵贖TML中可以設(shè)置寬高而使用本不需要的大圖。如果需要

<img width="100" height="100" src="mycat.jpg" alt="My Cat" /> 

那么圖片本身（mycat.jpg）應(yīng)該是100x100px的，而不是去縮小500x500px的圖片。

24.用小的可緩存的favicon.ico（P.S. 收藏夾圖標(biāo)）

favicon.ico是放在服務(wù)器根目錄的圖片，它會(huì)帶來(lái)一堆麻煩，因?yàn)榧幢隳悴还芩?，瀏覽器也會(huì)自動(dòng)請(qǐng)求它，所以最好不要給一個(gè)404 Not Found響應(yīng)。而且只要在同一個(gè)服務(wù)器上，每次請(qǐng)求它時(shí)都會(huì)發(fā)送cookie，此外這個(gè)圖片還會(huì)干擾下載順序，例如在IE中，當(dāng)你在onload中請(qǐng)求額外組件時(shí)，將會(huì)先下載favicon。

所以為了緩解favicon.ico的缺點(diǎn)，應(yīng)該確保：

1. 足夠小，最好在1K以下
2. 設(shè)置合適的有效期HTTP頭（以后如果想換的話就不能重命名了），把有效期設(shè)置為幾個(gè)月后一般比較安全，可以通過(guò)檢查當(dāng)前favicon.ico的最后修改日期來(lái)確保變更能讓瀏覽器知道。

cookie

25.給Cookie減肥

使用cookie的原因有很多，比如授權(quán)和個(gè)性化。HTTP頭中cookie信息在web服務(wù)器和瀏覽器之間交換。重要的是保證cookie盡可能的小，以最小化對(duì)用戶響應(yīng)時(shí)間的影響。

1. 清除不必要的cookie
2. 保證cookie盡可能小，以最小化對(duì)用戶響應(yīng)時(shí)間的影響
3. 注意給cookie設(shè)置合適的域級(jí)別，以免影響其它子域
4. 設(shè)置合適的有效期，更早的有效期或者none可以更快的刪除cookie，提高用戶響應(yīng)時(shí)間

26.把組件放在不含cookie的域下

當(dāng)瀏覽器發(fā)送對(duì)靜態(tài)圖像的請(qǐng)求時(shí)，cookie也會(huì)一起發(fā)送，而服務(wù)器根本不需要這些cookie。所以它們只會(huì)造成沒(méi)有意義的網(wǎng)絡(luò)通信量，應(yīng)該確保對(duì)靜態(tài)組件的請(qǐng)求不含cookie?？梢詣?chuàng)建一個(gè)子域，把所有的靜態(tài)組件都部署在那兒。

如果域名是www.example.org，可以把靜態(tài)組件部署到static.example.org。然而，如果已經(jīng)在頂級(jí)域example.org或者www.example.org設(shè)置了cookie，那么所有對(duì)static.example.org的請(qǐng)求都會(huì)含有這些cookie。這時(shí)候可以再買(mǎi)一個(gè)新域名，把所有的靜態(tài)組件部署上去，并保持這個(gè)新域名不含cookie。Yahoo!用的是yimg.com，YouTube是ytimg.com，Amazon是images-amazon.com等等。

把靜態(tài)組件部署在不含cookie的域下還有一個(gè)好處是有些代理可能會(huì)拒絕緩存帶cookie的組件。有一點(diǎn)需要注意：如果不知道應(yīng)該用example.org還是www.example.org作為主頁(yè)，可以考慮一下cookie的影響。省略www的話，就只能把cookie寫(xiě)到*.example.org，所以因?yàn)樾阅茉蜃詈糜脀ww子域，并且把cookie寫(xiě)到這個(gè)子域下。

移動(dòng)端

27.保證所有組件都小于25K

這個(gè)限制是因?yàn)閕Phone不能緩存大于25K的組件，注意這里指的是未壓縮的大小。這就是為什么縮減內(nèi)容本身也很重要，因?yàn)閱渭兊膅zip可能不夠。

28.把組件打包到一個(gè)復(fù)合文檔里

把各個(gè)組件打包成一個(gè)像有附件的電子郵件一樣的復(fù)合文檔里，可以用一個(gè)HTTP請(qǐng)求獲取多個(gè)組件（記住一點(diǎn)：HTTP請(qǐng)求是代價(jià)高昂的）。用這種方式的時(shí)候，要先檢查用戶代理是否支持（iPhone就不支持）。

服務(wù)器

29.Gzip組件

前端工程師可以想辦法明顯地縮短通過(guò)網(wǎng)絡(luò)傳輸HTTP請(qǐng)求和響應(yīng)的時(shí)間。毫無(wú)疑問(wèn)，終端用戶的帶寬速度，網(wǎng)絡(luò)服務(wù)商，對(duì)等交換點(diǎn)的距離等等，都是開(kāi)發(fā)團(tuán)隊(duì)所無(wú)法控制的。但還有別的能夠影響響應(yīng)時(shí)間的因素，壓縮可以通過(guò)減少HTTP響應(yīng)的大小來(lái)縮短響應(yīng)時(shí)間。

從HTTP/1.1開(kāi)始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請(qǐng)求頭。

Accept-Encoding: gzip, deflate 

如果web服務(wù)器看到這個(gè)請(qǐng)求頭，它就會(huì)用客戶端列出的一種方式來(lái)壓縮響應(yīng)。web服務(wù)器通過(guò)Content-Encoding相應(yīng)頭來(lái)通知客戶端。

Content-Encoding: gzip 

盡可能多地用gzip壓縮能夠給頁(yè)面減肥，這也是提升用戶體驗(yàn)最簡(jiǎn)單的方法。

30.避免圖片src屬性為空

Image with empty string src屬性是空字符串的圖片很常見(jiàn)，主要以?xún)煞N形式出現(xiàn)：

1.straight HTML

<img src=””>

2.JavaScript

var img = new Image();
img.src = “”;

這兩種形式都會(huì)引起相同的問(wèn)題：瀏覽器會(huì)向服務(wù)器發(fā)送另一個(gè)請(qǐng)求。

31.配置ETags

實(shí)體標(biāo)簽（ETags），是服務(wù)器和瀏覽器用來(lái)決定瀏覽器緩存中組件與源服務(wù)器中的組件是否匹配的一種機(jī)制（“實(shí)體”也就是組件：圖片，腳本，樣式表等等）。添加ETags可以提供一種實(shí)體驗(yàn)證機(jī)制，比最后修改日期更加靈活。一個(gè)ETag是一個(gè)字符串，作為一個(gè)組件某一具體版本的唯一標(biāo)識(shí)符。唯一的格式約束是字符串必須用引號(hào)括起來(lái)，源服務(wù)器用相應(yīng)頭中的ETag來(lái)指定組件的ETag：

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195 

然后，如果瀏覽器必須驗(yàn)證一個(gè)組件，它用If-None-Match請(qǐng)求頭來(lái)把ETag傳回源服務(wù)器。如果ETags匹配成功，會(huì)返回一個(gè)304狀態(tài)碼，這樣就減少了12195個(gè)字節(jié)的響應(yīng)體。

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

32.對(duì)Ajax用GET請(qǐng)求

Yahoo!郵箱團(tuán)隊(duì)發(fā)現(xiàn)使用XMLHttpRequest時(shí)，瀏覽器的POST請(qǐng)求是通過(guò)一個(gè)兩步的過(guò)程來(lái)實(shí)現(xiàn)的：先發(fā)送HTTP頭，在發(fā)送數(shù)據(jù)。所以最好用GET請(qǐng)求，它只需要發(fā)送一個(gè)TCP報(bào)文（除非cookie特別多）。IE的URL長(zhǎng)度最大值是2K，所以如果要發(fā)送的數(shù)據(jù)超過(guò)2K就無(wú)法使用GET了。

POST請(qǐng)求的一個(gè)有趣的副作用是實(shí)際上沒(méi)有發(fā)送任何數(shù)據(jù)，就像GET請(qǐng)求一樣。正如HTTP說(shuō)明文檔中描述的，GET請(qǐng)求是用來(lái)檢索信息的。所以它的語(yǔ)義只是用GET請(qǐng)求來(lái)請(qǐng)求數(shù)據(jù)，而不是用來(lái)發(fā)送需要存儲(chǔ)到服務(wù)器的數(shù)據(jù)。

33.盡早清空緩沖區(qū)

當(dāng)用戶請(qǐng)求一個(gè)頁(yè)面時(shí)，服務(wù)器需要用大約200到500毫秒來(lái)組裝HTML頁(yè)面，在這期間，瀏覽器閑等著數(shù)據(jù)到達(dá)。PHP中有一個(gè)flush()函數(shù)，允許給瀏覽器發(fā)送一部分已經(jīng)準(zhǔn)備完畢的HTML響應(yīng)，以便瀏覽器可以在后臺(tái)準(zhǔn)備剩余部分的同時(shí)開(kāi)始獲取組件，好處主要體現(xiàn)在很忙的后臺(tái)或者很“輕”的前端頁(yè)面上（P.S. 也就是說(shuō)，響應(yīng)時(shí)耗主要在后臺(tái)方面時(shí)最能體現(xiàn)優(yōu)勢(shì)）。

較理想的清空緩沖區(qū)的位置是HEAD后面，因?yàn)镠TML的HEAD部分通常更容易生成，并且允許引入任何CSS和JavaScript文件，這樣就可以讓瀏覽器在后臺(tái)還在處理的時(shí)候就開(kāi)始并行獲取組件。

例如：

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

34.使用CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）

用戶與服務(wù)器的物理距離對(duì)響應(yīng)時(shí)間也有影響。把內(nèi)容部署在多個(gè)地理位置分散的服務(wù)器上能讓用戶更快地載入頁(yè)面。但具體要怎么做呢？

實(shí)現(xiàn)內(nèi)容在地理位置上分散的第一步是：不要嘗試去重新設(shè)計(jì)你的web應(yīng)用程序來(lái)適應(yīng)分布式結(jié)構(gòu)。這取決于應(yīng)用程序，改變結(jié)構(gòu)可能包括一些讓人望而生畏的任務(wù)，比如同步會(huì)話狀態(tài)和跨服務(wù)器復(fù)制數(shù)據(jù)庫(kù)事務(wù)（翻譯可能不準(zhǔn)確）?？s短用戶和內(nèi)容之間距離的提議可能被推遲，或者根本不可能通過(guò)，就是因?yàn)檫@個(gè)難題。

記住終端用戶80%到90%的響應(yīng)時(shí)間都花在下載頁(yè)面組件上了：圖片，樣式，腳本，F(xiàn)lash等等，這是業(yè)績(jī)黃金法則。最好先分散靜態(tài)內(nèi)容，而不是一開(kāi)始就重新設(shè)計(jì)應(yīng)用程序結(jié)構(gòu)。這不僅能夠大大減少響應(yīng)時(shí)間，還更容易表現(xiàn)出CDN的功勞。

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）是一組分散在不同地理位置的web服務(wù)器，用來(lái)給用戶更高效地發(fā)送內(nèi)容。典型地，選擇用來(lái)發(fā)送內(nèi)容的服務(wù)器是基于網(wǎng)絡(luò)距離的衡量標(biāo)準(zhǔn)的。例如：選跳數(shù)（hop）最少的或者響應(yīng)時(shí)間最快的服務(wù)器。

35.添上Expires或者Cache-Control HTTP頭

這條規(guī)則有兩個(gè)方面：

1. 對(duì)于靜態(tài)組件：通過(guò)設(shè)置一個(gè)遙遠(yuǎn)的將來(lái)時(shí)間作為Expires來(lái)實(shí)現(xiàn)永不失效
2. 多余動(dòng)態(tài)組件：用合適的Cache-ControlHTTP頭來(lái)讓瀏覽器進(jìn)行條件性的請(qǐng)求

網(wǎng)頁(yè)設(shè)計(jì)越來(lái)越豐富，這意味著頁(yè)面里有更多的腳本，圖片和Flash。站點(diǎn)的新訪客可能還是不得不提交幾個(gè)HTTP請(qǐng)求，但通過(guò)使用有效期能讓組件變得可緩存，這避免了在接下來(lái)的瀏覽過(guò)程中不必要的HTTP請(qǐng)求。有效期HTTP頭通常被用在圖片上，但它們應(yīng)該用在所有組件上，包括腳本、樣式和Flash組件。

瀏覽器（和代理）用緩存來(lái)減少HTTP請(qǐng)求的數(shù)目和大小，讓頁(yè)面能夠更快加載。web服務(wù)器通過(guò)有效期HTTP響應(yīng)頭來(lái)告訴客戶端，頁(yè)面的各個(gè)組件應(yīng)該被緩存多久。用一個(gè)遙遠(yuǎn)的將來(lái)時(shí)間做有效期，告訴瀏覽器這個(gè)響應(yīng)在2010年4月15日前不會(huì)改變。

Expires: Thu, 15 Apr 2010 20:00:00 GMT 

如果你用的是Apache服務(wù)器，用ExpiresDefault指令來(lái)設(shè)置相對(duì)于當(dāng)前日期的有效期。下面的例子設(shè)置了從請(qǐng)求時(shí)間起10年的有效期：

ExpiresDefault "access plus 10 years"

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。