前端是龐大的，包括html、css、javascript、image、flash等等各種各樣的資源。前端優(yōu)化是復雜的，針對方方面面的資源都有不同的方式。那么，前端優(yōu)化的目的是什么？

企業(yè)網(wǎng)站建設如何改善用戶(hù)體驗�。。�！

1. 從用戶(hù)角度而言，優(yōu)化能夠讓頁(yè)面加載得更快、對用戶(hù)的操作響應得更及時(shí)，能夠給用戶(hù)提供更為友好的體驗。

2. 從服務(wù)商角度而言，優(yōu)化能夠減少頁(yè)面請求數、或者減小請求所占帶寬，能夠節省可觀(guān)的資源。

總之，恰當的優(yōu)化不僅能夠改善站點(diǎn)的用戶(hù)體驗并且能夠節省相當的資源利用。前端優(yōu)化的途徑有很多，按粒度大致可以分為兩類(lèi)，第一類(lèi)是頁(yè)面級別的優(yōu) 化，例如http請求數、腳本的無(wú)阻塞加載、內聯(lián)腳本的位置優(yōu)化等；第二類(lèi)則是代碼級別的優(yōu)化，例如javascript中的dom操作優(yōu)化、css選擇 符優(yōu)化、圖片優(yōu)化以及html結構優(yōu)化等等。另外，本著(zhù)提高投入產(chǎn)出比的目的，后文提到的各種優(yōu)化策略大致按照投入產(chǎn)出比從大到小的順序排列。

一、頁(yè)面級優(yōu)化

1. 減少http請求數

這條策略基本上所有前端人都知道，而且也是最重要最有效的。都說(shuō)要減少http請求，那請求多了到底會(huì )怎么樣呢？首先，每個(gè)請求都是有成本的，既包 含時(shí)間成本也包含資源成本。一個(gè)完整的請求都需要經(jīng)過(guò)dns尋址、與服務(wù)器建立連接、發(fā)送數據、等待服務(wù)器響應、接收數據這樣一個(gè)“漫長(cháng)”而復雜的過(guò)程。 時(shí)間成本就是用戶(hù)需要看到或者“感受”到這個(gè)資源是必須要等待這個(gè)過(guò)程結束的，資源上由于每個(gè)請求都需要攜帶數據，因此每個(gè)請求都需要占用帶寬。

另外，由于瀏覽器進(jìn)行并發(fā)請求的請求數是有上限的(具體參見(jiàn)此處)，因此請求數多了以后，瀏覽器需要分批進(jìn)行請求，因此會(huì )增加用戶(hù)的等待時(shí)間，會(huì )給 用戶(hù)造成站點(diǎn)速度慢這樣一個(gè)印象，即使可能用戶(hù)能看到的第一屏的資源都已經(jīng)請求完了，但是瀏覽器的進(jìn)度條會(huì )一直存在。減少http請求數的主要途徑包括：

(1). 從設計實(shí)現層面簡(jiǎn)化頁(yè)面

如果你的頁(yè)面像百度首頁(yè)一樣簡(jiǎn)單，那么接下來(lái)的規則基本上都用不著(zhù)了。保持頁(yè)面簡(jiǎn)潔、減少資源的使用時(shí)最直接的。如果不是這樣，你的頁(yè)面需要華麗的皮膚，則繼續閱讀下面的內容。

(2). 合理設置http緩存

緩存的力量是強大的，恰當的緩存設置可以大大的減少http請求。以有啊首頁(yè)為例，當瀏覽器沒(méi)有緩存的時(shí)候訪(fǎng)問(wèn)一共會(huì )發(fā)出78個(gè)請求，共600多k 數據（如圖1.1），而當第二次訪(fǎng)問(wèn)即瀏覽器已緩存之后訪(fǎng)問(wèn)則僅有10個(gè)請求，共20多k數據（如圖1.2）。（這里需要說(shuō)明的是，如果直接f5刷新頁(yè)面 的話(huà)效果是不一樣的，這種情況下請求數還是一樣，不過(guò)被緩存資源的請求服務(wù)器是304響應，只有header沒(méi)有body，可以節省帶寬）

怎樣才算合理設置？原則很簡(jiǎn)單，能緩存越多越好，能緩存越久越好。例如，很少變化的圖片資源可以直接通過(guò)http header中的expires設置一個(gè)很長(cháng)的過(guò)期頭；變化不頻繁而又可能會(huì )變的資源可以使用last-modifed來(lái)做請求驗證。盡可能的讓資源能夠 在緩存中待得更久。

(3). 資源合并與壓縮

如果可以的話(huà)，盡可能的將外部的腳本、樣式進(jìn)行合并，多個(gè)合為一個(gè)。另外，css、javascript、image都可以用相應的工具進(jìn)行壓縮，壓縮后往往能省下不少空間。

(4). css sprites

合并css圖片，減少請求數的又一個(gè)好辦法。

(5). inline images

使用data: url scheme的方式將圖片嵌入到頁(yè)面或css中，如果不考慮資源管理上的問(wèn)題的話(huà)，不失為一個(gè)好辦法。如果是嵌入頁(yè)面的話(huà)換來(lái)的是增大了頁(yè)面的體積，而且無(wú)法利用瀏覽器緩存。使用在css中的圖片則更為理想一些。

(6). lazy load images

這條策略實(shí)際上并不一定能減少http請求數，但是卻能在某些條件下或者頁(yè)面剛加載時(shí)減少http請求數。對于圖片而言，在頁(yè)面剛加載的時(shí)候可以只 加載第一屏，當用戶(hù)繼續往后滾屏的時(shí)候才加載后續的圖片。這樣一來(lái)，假如用戶(hù)只對第一屏的內容感興趣時(shí)，那剩余的圖片請求就都節省了。有啊首頁(yè)曾經(jīng)的做法 是在加載的時(shí)候把第一屏之后的圖片地址緩存在textarea標簽中，待用戶(hù)往下滾屏的時(shí)候才“惰性”加載。

2. 將外部腳本置底

前文有談到，瀏覽器是可以并發(fā)請求的，這一特點(diǎn)使得其能夠更快的加載資源，然而外鏈腳本在加載時(shí)卻會(huì )阻塞其他資源，例如在腳本加載完成之前，它后面 的圖片、樣式以及其他腳本都處于阻塞狀態(tài)，直到腳本加載完成后才會(huì )開(kāi)始加載。如果將腳本放在比較靠前的位置，則會(huì )影響整個(gè)頁(yè)面的加載速度從而影響用戶(hù)體 驗。解決這一問(wèn)題的方法有很多，在這里有比較詳細的介紹（這里是譯文和更詳細的例子），而最簡(jiǎn)單可依賴(lài)的方法就是將腳本盡可能的往后挪，減少對并發(fā)下載的 影響。

3. 異步執行inline腳本

inline腳本對性能的影響與外部腳本相比，是有過(guò)之而無(wú)不及。首頁(yè)，與外部腳本一樣，inline腳本在執行的時(shí)候一樣會(huì )阻塞并發(fā)請求，除此之 外，由于瀏覽器在頁(yè)面處理方面是單線(xiàn)程的，當inline腳本在頁(yè)面渲染之前執行時(shí)，頁(yè)面的渲染工作則會(huì )被推遲。簡(jiǎn)而言之，inline腳本在執行的時(shí) 候，頁(yè)面處于空白狀態(tài)。鑒于以上兩點(diǎn)原因，建議將執行時(shí)間較長(cháng)的inline腳本異步執行，異步的方式有很多種，例如使用script元素的defer屬 性（存在兼容性問(wèn)題和其他一些問(wèn)題，例如不能使用document.write）、使用settimeout，此外，在html5中引入了web workers的機制，恰恰可以解決此類(lèi)問(wèn)題。

4. lazy load javascript

隨著(zhù)javascript框架的流行，越來(lái)越多的站點(diǎn)也使用起了框架。不過(guò)，一個(gè)框架往往包括了很多的功能實(shí)現，這些功能并不是每一個(gè)頁(yè)面都需要 的，如果下載了不需要的腳本則算得上是一種資源浪費-既浪費了帶寬又浪費了執行花費的時(shí)間。目前的做法大概有兩種，一種是為那些流量特別大的頁(yè)面專(zhuān)門(mén)定制 一個(gè)專(zhuān)用的mini版框架，另一種則是lazy load。yui則使用了第二種方式，在yui的實(shí)現中，最初只加載核心模塊，其他模塊可以等到需要使用的時(shí)候才加載。

5. 將css放在head中

如果將css放在其他地方比如body中，則瀏覽器有可能還未下載和解析到css就已經(jīng)開(kāi)始渲染頁(yè)面了，這就導致頁(yè)面由無(wú)css狀態(tài)跳轉到css狀 態(tài)，用戶(hù)體驗比較糟糕。除此之外，有些瀏覽器會(huì )在css下載完成后才開(kāi)始渲染頁(yè)面，如果css放在靠下的位置則會(huì )導致瀏覽器將渲染時(shí)間推遲。

6. 異步請求callback

在某些頁(yè)面中可能存在這樣一種需求，需要使用script標簽來(lái)異步的請求數據。類(lèi)似：

javascript:  /*callback函數*/  function mycallback(info){  //do something here  }   html:  <script type="text/javascript" src="http://abc.com/cb"></script> cb返回的內容:  mycallback('hello world!'); 

像以上這種方式直接在頁(yè)面上寫(xiě)<script>對頁(yè)面的性能也是有影響的，即增加了頁(yè)面首次加載的負擔，推遲了domloaded和 window.onload事件的觸發(fā)時(shí)機。如果時(shí)效性允許的話(huà)，可以考慮在domloaded事件觸發(fā)的時(shí)候加載，或者使用settimeout方式來(lái) 靈活的控制加載的時(shí)機。

7. 減少不必要的http跳轉

對于以目錄形式訪(fǎng)問(wèn)的http鏈接，很多人都會(huì )忽略鏈接最后是否帶’/'，假如你的服務(wù)器對此是區別對待的話(huà)，那么你也需要注意，這其中很可能隱藏了301跳轉，增加了多余請求。具體參見(jiàn)下圖，其中第一個(gè)鏈接是以無(wú)’/'結尾的方式訪(fǎng)問(wèn)的，于是服務(wù)器有了一次跳轉。

8. 避免重復的資源請求

這種情況主要是由于疏忽或頁(yè)面由多個(gè)模塊拼接而成，然后每個(gè)模塊中請求了同樣的資源時(shí)，會(huì )導致資源的重復請求。出現的幾率不大，但是還是要注意排查，不然可能會(huì )出現如下局面，來(lái)自這里。