前端是龐大的，包括 HTML蟀拷、 CSS碰纬、 Javascript、Image 问芬、Flash等等各種各樣的資源悦析。前端優(yōu)化是復(fù)雜的，針對(duì)方方面面的資源都有不同的方式此衅。那么强戴，前端優(yōu)化的目的是什么 ?

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

2. 從服務(wù)商角度而言墨微，優(yōu)化能夠減少頁(yè)面請(qǐng)求數(shù)道媚、或者減小請(qǐng)求所占帶寬，能夠節(jié)省可觀的資源翘县。

總之最域，恰當(dāng)?shù)膬?yōu)化不僅能夠改善站點(diǎn)的用戶體驗(yàn)并且能夠節(jié)省相當(dāng)?shù)馁Y源利用。

前端優(yōu)化的途徑有很多锈麸，按粒度大致可以分為兩類镀脂，第一類是頁(yè)面級(jí)別的優(yōu)化，例如 HTTP請(qǐng)求數(shù)掐隐、腳本的無(wú)阻塞加載狗热、內(nèi)聯(lián)腳本的位置優(yōu)化等

;第二類則是代碼級(jí)別的優(yōu)化钞馁，例如 Javascript中的DOM 操作優(yōu)化虑省、CSS選擇符優(yōu)化、圖片優(yōu)化以及

HTML結(jié)構(gòu)優(yōu)化等等僧凰。另外探颈，本著提高投入產(chǎn)出比的目的，后文提到的各種優(yōu)化策略大致按照投入產(chǎn)出比從大到小的順序排列训措。

一伪节、頁(yè)面級(jí)優(yōu)化

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

這條策略基本上所有前端人都知道光羞，而且也是最重要最有效的。都說(shuō)要減少 HTTP請(qǐng)求怀大，那請(qǐng)求多了到底會(huì)怎么樣呢 ?首先纱兑，每個(gè)請(qǐng)求都是有成本的，既包含時(shí)間成本也包含資源成本化借。一個(gè)完整的請(qǐng)求都需要經(jīng)過(guò) DNS尋址潜慎、與服務(wù)器建立連接、發(fā)送數(shù)據(jù)蓖康、等待服務(wù)器響應(yīng)铐炫、接收數(shù)據(jù)這樣一個(gè) “漫長(zhǎng)” 而復(fù)雜的過(guò)程。時(shí)間成本就是用戶需要看到或者 “感受” 到這個(gè)資源是必須要等待這個(gè)過(guò)程結(jié)束的蒜焊，資源上由于每個(gè)請(qǐng)求都需要攜帶數(shù)據(jù)倒信，因此每個(gè)請(qǐng)求都需要占用帶寬。另外泳梆，由于瀏覽器進(jìn)行并發(fā)請(qǐng)求的請(qǐng)求數(shù)是有上限的 (具體參見(jiàn)此處 )鳖悠，因此請(qǐng)求數(shù)多了以后，瀏覽器需要分批進(jìn)行請(qǐng)求优妙，因此會(huì)增加用戶的等待時(shí)間竞穷，會(huì)給用戶造成站點(diǎn)速度慢這樣一個(gè)印象，即使可能用戶能看到的第一屏的資源都已經(jīng)請(qǐng)求完了鳞溉，但是瀏覽器的進(jìn)度條會(huì)一直存在瘾带。

減少 HTTP請(qǐng)求數(shù)的主要途徑包括：

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

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

(2). 合理設(shè)置 HTTP緩存

緩存的力量是強(qiáng)大的呆贿，恰當(dāng)?shù)木彺嬖O(shè)置可以大大的減少 HTTP請(qǐng)求嚷兔。以有啊首頁(yè)為例，當(dāng)瀏覽器沒(méi)有緩存的時(shí)候訪問(wèn)一共會(huì)發(fā)出 78個(gè)請(qǐng)求做入，共 600多 K數(shù)據(jù)冒晰，而當(dāng)?shù)诙卧L問(wèn)即瀏覽器已緩存之后訪問(wèn)則僅有 10個(gè)請(qǐng)求，共 20多 K數(shù)據(jù) 竟块。 (這里需要說(shuō)明的是壶运，如果直接 F5刷新頁(yè)面的話效果是不一樣的，這種情況下請(qǐng)求數(shù)還是一樣浪秘，不過(guò)被緩存資源的請(qǐng)求服務(wù)器是 304響應(yīng)蒋情，只有 Header沒(méi)有Body 埠况，可以節(jié)省帶寬 )

怎樣才算合理設(shè)置 ?原則很簡(jiǎn)單，能緩存越多越好棵癣，能緩存越久越好辕翰。例如，很少變化的圖片資源可以直接通過(guò) HTTP Header中的Expires設(shè)置一個(gè)很長(zhǎng)的過(guò)期頭 ;變化不頻繁而又可能會(huì)變的資源可以使用 Last-Modifed來(lái)做請(qǐng)求驗(yàn)證狈谊。盡可能的讓資源能夠在緩存中待得更久金蜀。關(guān)于 HTTP緩存的具體設(shè)置和原理此處就不再詳述了，有興趣的可以參考下列文章：

HTTP1.1協(xié)議中關(guān)于緩存策略的描述

Fiddler HTTP Performance中關(guān)于緩存的介紹

(3). 資源合并與壓縮

如果可以的話的畴，盡可能的將外部的腳本渊抄、樣式進(jìn)行合并，多個(gè)合為一個(gè)丧裁。另外护桦， CSS、 Javascript煎娇、Image 都可以用相應(yīng)的工具進(jìn)行壓縮二庵，壓縮后往往能省下不少空間。

(4). CSS Sprites

合并 CSS圖片缓呛，減少請(qǐng)求數(shù)的又一個(gè)好辦法催享。

(5). Inline Images

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

(6). Lazy Load Images

這條策略實(shí)際上并不一定能減少 HTTP請(qǐng)求數(shù)，但是卻能在某些條件下或者頁(yè)面剛加載時(shí)減少 HTTP請(qǐng)求數(shù)洽沟。對(duì)于圖片而言以故，在頁(yè)面剛加載的時(shí)候可以只加載第一屏，當(dāng)用戶繼續(xù)往后滾屏的時(shí)候才加載后續(xù)的圖片裆操。這樣一來(lái)怒详，假如用戶只對(duì)第一屏的內(nèi)容感興趣時(shí)，那剩余的圖片請(qǐng)求就都節(jié)省了踪区。 有啊首頁(yè) 曾經(jīng)的做法是在加載的時(shí)候把第一屏之后的圖片地址緩存在 Textarea標(biāo)簽中昆烁，待用戶往下滾屏的時(shí)候才 “惰性” 加載。

2. 將外部腳本置底（將腳本內(nèi)容在頁(yè)面信息內(nèi)容加載后再加載）

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

3. 異步執(zhí)行 inline腳本(其實(shí)原理和上面是一樣，保證腳本在頁(yè)面內(nèi)容后面加載地熄。)

inline腳本對(duì)性能的影響與外部腳本相比华临，是有過(guò)之而無(wú)不及。首頁(yè)端考，與外部腳本一樣雅潭， inline腳本在執(zhí)行的時(shí)候一樣會(huì)阻塞并發(fā)請(qǐng)求，除此之外却特，由于瀏覽器在頁(yè)面處理方面是單線程的扶供，當(dāng) inline腳本在頁(yè)面渲染之前執(zhí)行時(shí)，頁(yè)面的渲染工作則會(huì)被推遲裂明。簡(jiǎn)而言之椿浓， inline腳本在執(zhí)行的時(shí)候，頁(yè)面處于空白狀態(tài)闽晦。鑒于以上兩點(diǎn)原因轰绵，建議將執(zhí)行時(shí)間較長(zhǎng)的 inline腳本異步執(zhí)行，異步的方式有很多種尼荆，例如使用 script元素的defer 屬性(存在兼容性問(wèn)題和其他一些問(wèn)題左腔，例如不能使用 document.write)、使用setTimeout 捅儒，此外戈擒，在HTML5中引入了 Web Workers的機(jī)制，恰恰可以解決此類問(wèn)題映挂。

4. Lazy Load Javascript（只有在需要加載的時(shí)候加載瓮孙，在一般情況下并不加載信息內(nèi)容。）

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

5. 將 CSS放在 HEAD中

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

6. 異步請(qǐng)求 Callback（就是將一些行為樣式提取出來(lái)芒澜，慢慢的加載信息的內(nèi)容）　　在某些頁(yè)面中可能存在這樣一種需求，需要使用 script標(biāo)簽來(lái)異步的請(qǐng)求數(shù)據(jù)创淡。類似：　　Javascript:function myCallback(info){//do something here}　　HTML:　　cb返回的內(nèi)容 :myCallback('Hello world!');像以上這種方式直接在頁(yè)面上寫(xiě)對(duì)頁(yè)面的性能也是有影響的痴晦，即增加了頁(yè)面首次加載的負(fù)擔(dān)，推遲了 DOMLoaded和window.onload 事件的觸發(fā)時(shí)機(jī)琳彩。如果時(shí)效性允許的話誊酌，可以考慮在 DOMLoaded事件觸發(fā)的時(shí)候加載，或者使用 setTimeout方式來(lái)靈活的控制加載的時(shí)機(jī)露乏。

7. 減少不必要的 HTTP跳轉(zhuǎn)

對(duì)于以目錄形式訪問(wèn)的 HTTP鏈接碧浊，很多人都會(huì)忽略鏈接最后是否帶 ’/'，假如你的服務(wù)器對(duì)此是區(qū)別對(duì)待的話瘟仿，那么你也需要注意箱锐，這其中很可能隱藏了 301跳轉(zhuǎn)，增加了多余請(qǐng)求劳较。

8. 避免重復(fù)的資源請(qǐng)求

這種情況主要是由于疏忽或頁(yè)面由多個(gè)模塊拼接而成驹止，然后每個(gè)模塊中請(qǐng)求了同樣的資源時(shí)，會(huì)導(dǎo)致資源的重復(fù)請(qǐng)求

二观蜗、代碼級(jí)優(yōu)化

1. Javascript

(1). DOM

DOM操作應(yīng)該是腳本中最耗性能的一類操作臊恋，例如增加、修改墓捻、刪除 DOM元素或者對(duì) DOM集合進(jìn)行操作抖仅。如果腳本中包含了大量的 DOM操作則需要注意以下幾點(diǎn)：

a. HTML Collection（HTML收集器，返回的是一個(gè)數(shù)組內(nèi)容信息）

在腳本中 document.images、document.forms 撤卢、getElementsByTagName()返回的都是 HTMLCollection類型的集合环凿，在平時(shí)使用的時(shí)候大多將它作為數(shù)組來(lái)使用，因?yàn)樗?length屬性凸丸，也可以使用索引訪問(wèn)每一個(gè)元素拷邢。不過(guò)在訪問(wèn)性能上則比數(shù)組要差很多袱院，原因是這個(gè)集合并不是一個(gè)靜態(tài)的結(jié)果屎慢，它表示的僅僅是一個(gè)特定的查詢，每次訪問(wèn)該集合時(shí)都會(huì)重新執(zhí)行這個(gè)查詢從而更新查詢結(jié)果忽洛。所謂的 “訪問(wèn)集合” 包括讀取集合的 leng屬性腻惠、訪問(wèn)集合中的元素。

因此欲虚，當(dāng)你需要遍歷 HTML Collection的時(shí)候集灌，盡量將它轉(zhuǎn)為數(shù)組后再訪問(wèn)，以提高性能复哆。即使不轉(zhuǎn)換為數(shù)組欣喧，也請(qǐng)盡可能少的訪問(wèn)它，例如在遍歷的時(shí)候可以將 length屬性梯找、成員保存到局部變量后再使用局部變量唆阿。

b. Reflow & Repaint

除了上面一點(diǎn)之外， DOM操作還需要考慮瀏覽器的 Reflow和Repaint 锈锤，因?yàn)檫@些都是需要消耗資源的驯鳖，具體的可以參加以下文章：

如何減少瀏覽器的repaint和reflow?

Understanding Internet Explorer Rendering Behaviour

Notes on HTML Reflow

(2). 慎用 with

with(obj){ p = 1}; 代碼塊的行為實(shí)際上是修改了代碼塊中的 執(zhí)行環(huán)境 ，將obj放在了其作用域鏈的最前端久免，在 with代碼塊中訪問(wèn)非局部變量是都是先從 obj上開(kāi)始查找浅辙，如果沒(méi)有再依次按作用域鏈向上查找，因此使用 with相當(dāng)于增加了作用域鏈長(zhǎng)度阎姥。而每次查找作用域鏈都是要消耗時(shí)間的记舆，過(guò)長(zhǎng)的作用域鏈會(huì)導(dǎo)致查找性能下降。

因此呼巴，除非你能肯定在 with代碼中只訪問(wèn) obj中的屬性氨淌，否則慎用 with，替代的可以使用局部變量緩存需要訪問(wèn)的屬性伊磺。

(3). 避免使用 eval和 Function

每次 eval 或 Function 構(gòu)造函數(shù)作用于字符串表示的源代碼時(shí)盛正，腳本引擎都需要將源代碼轉(zhuǎn)換成可執(zhí)行代碼。這是很消耗資源的操作 —— 通常比簡(jiǎn)單的函數(shù)調(diào)用慢 100倍以上屑埋。

eval 函數(shù)效率特別低豪筝，由于事先無(wú)法知曉傳給 eval 的字符串中的內(nèi)容，eval在其上下文中解釋要處理的代碼，也就是說(shuō)編譯器無(wú)法優(yōu)化上下文续崖，因此只能有瀏覽器在運(yùn)行時(shí)解釋代碼敲街。這對(duì)性能影響很大。

Function 構(gòu)造函數(shù)比 eval略好严望，因?yàn)槭褂么舜a不會(huì)影響周圍代碼 ;但其速度仍很慢多艇。

此外，使用 eval和 Function也不利于Javascript 壓縮工具執(zhí)行壓縮像吻。

(4). 減少作用域鏈查找（這方面設(shè)計(jì)到一些內(nèi)容的相關(guān)問(wèn)題）

前文談到了作用域鏈查找問(wèn)題峻黍，這一點(diǎn)在循環(huán)中是尤其需要注意的問(wèn)題。如果在循環(huán)中需要訪問(wèn)非本作用域下的變量時(shí)請(qǐng)?jiān)诒闅v之前用局部變量緩存該變量拨匆，并在遍歷結(jié)束后再重寫(xiě)那個(gè)變量姆涩，這一點(diǎn)對(duì)全局變量尤其重要，因?yàn)槿肿兞刻幱谧饔糜蜴湹淖铐敹瞬衙浚L問(wèn)時(shí)的查找次數(shù)是最多的骨饿。

低效率的寫(xiě)法：

// 全局變量

var globalVar = 1;

function myCallback(info){

for( var i = 100000; i--;){

//每次訪問(wèn) globalVar 都需要查找到作用域鏈最頂端，本例中需要訪問(wèn) 100000 次

globalVar += i;

}

}

更高效的寫(xiě)法：

// 全局變量

var globalVar = 1;

function myCallback(info){

//局部變量緩存全局變量

var localVar = globalVar;

for( var i = 100000; i--;){

//訪問(wèn)局部變量是最快的

localVar += i;

}

//本例中只需要訪問(wèn) 2次全局變量

在函數(shù)中只需要將 globalVar中內(nèi)容的值賦給localVar 中區(qū)
對(duì)頁(yè)面的性能也是有影響的台腥，即增加了頁(yè)面首次加載的負(fù)擔(dān)宏赘，推遲了 DOMLoaded和window.onload 事件的觸發(fā)時(shí)機(jī)。如果時(shí)效性允許的話黎侈，可以考慮在 DOMLoaded事件觸發(fā)的時(shí)候加載察署，或者使用 setTimeout方式來(lái)靈活的控制加載的時(shí)機(jī)。

globalVar = localVar;

}

此外蜓竹，要減少作用域鏈查找還應(yīng)該減少閉包的使用箕母。

(5). 數(shù)據(jù)訪問(wèn)

Javascript中的數(shù)據(jù)訪問(wèn)包括直接量 (字符串、正則表達(dá)式 )俱济、變量嘶是、對(duì)象屬性以及數(shù)組，其中對(duì)直接量和局部變量的訪問(wèn)是最快的蛛碌，對(duì)對(duì)象屬性以及數(shù)組的訪問(wèn)需要更大的開(kāi)銷聂喇。當(dāng)出現(xiàn)以下情況時(shí)，建議將數(shù)據(jù)放入局部變量：

a. 對(duì)任何對(duì)象屬性的訪問(wèn)超過(guò) 1次

b. 對(duì)任何數(shù)組成員的訪問(wèn)次數(shù)超過(guò) 1次

另外蔚携，還應(yīng)當(dāng)盡可能的減少對(duì)對(duì)象以及數(shù)組深度查找希太。

(6). 字符串拼接

在 Javascript中使用"+" 號(hào)來(lái)拼接字符串效率是比較低的，因?yàn)槊看芜\(yùn)行都會(huì)開(kāi)辟新的內(nèi)存并生成新的字符串變量酝蜒，然后將拼接結(jié)果賦值給新變量誊辉。與之相比更為高效的做法是使用數(shù)組的 join方法，即將需要拼接的字符串放在數(shù)組中最后調(diào)用其 join方法得到結(jié)果亡脑。不過(guò)由于使用數(shù)組也有一定的開(kāi)銷堕澄，因此當(dāng)需要拼接的字符串較多的時(shí)候可以考慮用此方法邀跃。

關(guān)于 Javascript優(yōu)化的更詳細(xì)介紹請(qǐng)參考：

Write Efficient Javascript(PPT)

Efficient JavaScript

2. CSS選擇符

在大多數(shù)人的觀念中，都覺(jué)得瀏覽器對(duì) CSS選擇符的解析式從左往右進(jìn)行的蛙紫，例如

#toc A { color: #444; }

這樣一個(gè)選擇符拍屑，如果是從右往左解析則效率會(huì)很高，因?yàn)榈谝粋€(gè) ID選擇基本上就把查找的范圍限定了坑傅，但實(shí)際上瀏覽器對(duì)選擇符的解析是從右往左進(jìn)行的僵驰。如上面的選擇符，瀏覽器必須遍歷查找每一個(gè) A標(biāo)簽的祖先節(jié)點(diǎn)唁毒，效率并不像之前想象的那樣高蒜茴。根據(jù)瀏覽器的這一行為特點(diǎn)，在寫(xiě)選擇符的時(shí)候需要注意很多事項(xiàng)枉证，有人已經(jīng)一一列舉了矮男， 詳情參考此處移必。

3. HTML

對(duì) HTML本身的優(yōu)化現(xiàn)如今也越來(lái)越多的受人關(guān)注了室谚，詳情可以參見(jiàn)這篇 總結(jié)性文章 。

4. Image壓縮

圖片壓縮是個(gè)技術(shù)活崔泵，不過(guò)現(xiàn)如今這方面的工具也非常多秒赤，壓縮之后往往能帶來(lái)不錯(cuò)的效果，具體的壓縮原理以及方法在《 Even Faster Web Sites》第10 章有很詳細(xì)的介紹憎瘸，有興趣的可以去看看入篮。

總結(jié)

本文從頁(yè)面級(jí)以及代碼級(jí)兩個(gè)粒度對(duì)前端優(yōu)化的各種方式做了一個(gè)總結(jié)，這些方法基本上都是前端開(kāi)發(fā)人員在開(kāi)發(fā)的過(guò)程中可以借鑒和實(shí)踐的幌甘，除此之外潮售，完整的前端優(yōu)化還應(yīng)該包括很多其他的途徑，例如 CDN锅风、 Gzip酥诽、多域名、無(wú) Cookie服務(wù)器等等皱埠，由于對(duì)于開(kāi)發(fā)人員的可操作性并不強(qiáng)大肮帐，在此也就不多敘述了，詳細(xì)的可以參考 Yahoo和Google 的這些“金科玉律边器。