很高興看到越來越多的企業(yè)重視前端開發(fā)了，前端不再是網(wǎng)站開發(fā)人員的附屬技能?；叵胛覄傞_始入行時(shí)，那時(shí)ASP網(wǎng)站（非ASP.NET）盛行，80%的網(wǎng)站都是用ASP來做的,一個(gè)網(wǎng)頁可能就是一個(gè)ASP文件，里面前端代碼和后端代碼混在一起?，F(xiàn)在不同了，前后端分離，前端可以專注于展示了，不用太在意后端的實(shí)現(xiàn)。但是，因?yàn)榍岸税l(fā)展太快，展示環(huán)境也復(fù)雜多變，需要前端開發(fā)者掌握更廣的知識(shí)。

這篇雜談，我打算從一個(gè)比較廣的面(包含JS,CSS,網(wǎng)絡(luò)傳輸,HTML5等)，以化整為零為出發(fā)點(diǎn)，來和大家介紹一些前端優(yōu)化的方法。（因?yàn)閭€(gè)人知識(shí)和經(jīng)驗(yàn)有限，除了文中提到的幾點(diǎn)，一定還有別的優(yōu)化方法有化零為整的特性，歡迎大家一起補(bǔ)充哈,本文會(huì)不定期更新）

何為化零為整？通俗點(diǎn)說，就是我們將細(xì)碎的東西整合為一個(gè)整體，通過操作這個(gè)整體，也能達(dá)到逐個(gè)操作細(xì)碎東西的效果。比如，你給我四個(gè)蘋果，我雙手可以拿著到處走動(dòng)；如果給我十個(gè)蘋果，我全兜手上，走起路來可能會(huì)慢些了，因?yàn)橐疹櫶O果，怕掉了;但是，如果你再給我個(gè)袋子，我把十個(gè)蘋果裝里面，它們就成為一個(gè)整體，我就可以拎著到處跑了。

OK，說了這么一通，開始細(xì)數(shù)前端中需要化零為整的地方吧。

?

1.atlas/sprite assets/精靈圖/雪碧圖

這些都是對圖集合的稱呼，圖集合就是在做圖片資源的時(shí)候，將一些小的圖片元素集中做到一張圖片中。在使用時(shí)，通過一些參數(shù)，來顯示大圖集合中所需要那個(gè)圖片原素。比如，需要這個(gè)大圖的某個(gè)ICON來做為DIV的背景，則除了將這個(gè)大圖設(shè)為DIV的背景外，還需要更改背景圖的位置（position）來顯示具體某小圖。

例：某網(wǎng)站的sprite assets如下：

?

2.事件委托

面試時(shí)，我經(jīng)常問的一個(gè)問題，有一個(gè)列表頁，頁面結(jié)構(gòu)是外面一個(gè)BODY， 里面有一萬個(gè)子DIV，每個(gè)DIV里面有一些文字，這些文字都不相同。需求是，點(diǎn)擊一個(gè)DIV，要求彈個(gè)alert框，將DIV里的文字顯示出來。你會(huì)怎么做。

30%的人會(huì)用JQuery來綁事件，認(rèn)為看著簡潔，應(yīng)該效率高，如：$("body>div").click(……) ?，有20%的人會(huì)寫原生的語句來遍歷，給每個(gè)DIV添加點(diǎn)擊事件，有10%的人回答，在頁面滾動(dòng)時(shí)，存下頁面滾動(dòng)的高度，在點(diǎn)擊時(shí)，獲取觸發(fā)點(diǎn)在屏幕的Y坐標(biāo)，將Y的坐標(biāo)和頁面滾動(dòng)的高度相加，然后除以每個(gè)DIV的高度，就知道點(diǎn)了第幾個(gè)元素，再將這個(gè)元素的內(nèi)容彈出來。（或其它類似的做法）

回答出以上答案的面試者在這題會(huì)被扣分，正確答案是，只用給外面的元素（本題是BODY）添加點(diǎn)擊事件，在點(diǎn)擊時(shí)，可以獲取到引發(fā)點(diǎn)擊事件的源元素（如某DIV），將這個(gè)元素的文本內(nèi)容彈出來即可。

?

3.長連接 keep alive

這點(diǎn)和后端有關(guān)系了，不光是前端的事了。大多數(shù)網(wǎng)頁是用http方式來獲取資源（如圖片，樣式表文件，JS文件等），有部分服務(wù)器不會(huì)維持連接，來了個(gè)請求，就建立連接，然后輸出內(nèi)容，輸出完后斷開連接，再重新建立下個(gè)請求的連接和輸出。如果一個(gè)網(wǎng)頁需要請求一百個(gè)文件，服務(wù)器就要建立和斷開一百次連接。每次建立和斷開都需要時(shí)間（甚至比傳輸數(shù)據(jù)時(shí)間還長），無疑增加了頁面的呈現(xiàn)時(shí)間。如果服務(wù)器啟用了keep alive，不光減輕了服務(wù)器負(fù)擔(dān)，也加快了頁面打開時(shí)間。

如下圖，我們可以看到，實(shí)際接收內(nèi)容的時(shí)間(Receiving)是很短的，大部分時(shí)間花在了等待（Waiting）和阻塞(Blocking)。

?

4.多DOM合并

由于前端表現(xiàn)越來越豐富，頁面上東西也越來越多，隨之而來的問題是DOM太多了，在做一些DOM操作時(shí)，會(huì)帶來性能問題。在DOM非常多的情況下，我們有必要把DOM進(jìn)行合并，可以考慮把多個(gè)DOM合并為少量幾個(gè)，或在可以的情況下，使用CANVAS來展示。

如：有些需求會(huì)要求前端開發(fā)者做這種日期選擇器

?如果使用一個(gè)DOM來裝一個(gè)選項(xiàng)（如：1970），不考慮按鈕，單獨(dú)看日期選項(xiàng)的話，可能會(huì)需要44+12+31=87個(gè)DOM，對于移動(dòng)瀏覽器來說，DOM越少越好。萬一產(chǎn)品后來一想，除了日期，還要添加時(shí)分秒選項(xiàng)呢？這就需要44+12+31+24+60+60=231個(gè)DOM了。但我們可以細(xì)想一下，如果把各字段（年、月、日）只用一個(gè)很高的容器（如DIV）來裝，內(nèi)容可以用換行符來換行，取值時(shí)通過一些算法來得到，是不是大幅縮小了DOM數(shù)量？從87個(gè)DOM變?yōu)?個(gè)DOM。少了一個(gè)數(shù)量級(jí)。

?

5.WebSocket

很多網(wǎng)頁有實(shí)時(shí)更新數(shù)據(jù)的要求,如證券類網(wǎng)站。為了避免頁面刷新，會(huì)使用AJAX來進(jìn)行長輪詢，每隔一段時(shí)間（如一秒鐘）就連一次服務(wù)器取下數(shù)據(jù)。這樣會(huì)造成大量的請求連接，不止給前端，也給后端帶來了不小的壓力。幸好HTML5給我們帶來了WebSocket,網(wǎng)頁能夠和服務(wù)器保持長連接，通過長連接來維持?jǐn)?shù)據(jù)的實(shí)時(shí)更新了。

?

6.CSS屬性繼承

CSS會(huì)繼承父元素的屬性，我們可以將一些通用的屬性在父元素的CSS中定義，子元素通過繼承來獲取這些元素。在某些情況下，合理使用繼承能較明顯地縮小CSS文件的大小。

?

7.documentFragment

"一個(gè)列表頁，需要你往里面插入一千個(gè)DOM，你怎么做？" 這是我經(jīng)常問別人的一道題。

很多時(shí)候，你往頁面中加一個(gè)DOM，就會(huì)引起頁面的重構(gòu)。如果你使用遍歷來逐一添加，每添加一次，頁面都會(huì)重新渲染一次，這種做法會(huì)帶來性能的下降。好的方式是把要添加的元素先緩存起來， 要添加時(shí)一次性添加。一般會(huì)使用documentFragment來進(jìn)行緩存，還有些使用長的字符串（HTML代碼串）來緩存。

?

8.多動(dòng)畫合并為一個(gè)

在做CSS3的動(dòng)畫時(shí)，如果需求中要求有多步驟的動(dòng)畫（如，將一個(gè)DIV沿Y軸旋轉(zhuǎn)30度，接著沿X軸旋轉(zhuǎn)30度，再沿Z軸旋轉(zhuǎn)30度），我們可以將這些動(dòng)畫合并，使用animation的關(guān)鍵幀來將這些步驟隔離。省去多步操作DOM的成本。

?

9.多文件壓縮與合并

對JS和CSS文件壓縮，是前端縮小網(wǎng)絡(luò)傳輸量的有效方式（壓縮的做法一般是去除多余空格和換行，以及替換變量名或方法名。YUI?Compressor是個(gè)不錯(cuò)的工具）

將多個(gè)小的JS或CSS文件合并（merge）為一個(gè)大文件，這種做法可以大幅減少請示的次數(shù)。

?