前言
在上一篇文章《我的css架構(gòu)理念》中，承蒙園內(nèi)的朋友們抬愛，竟然一路被推薦，讓我這小小一枚前端攻城獅既意外又興奮進(jìn)而惶恐?；炭值氖琴Y歷實(shí)在有限，知識(shí)實(shí)在匱乏，相當(dāng)害怕誤人子弟。此真心話！但接下來(lái)我依然會(huì)堅(jiān)持有時(shí)間就寫寫文章，既能總結(jié)，又能學(xué)到新知識(shí)，還能分享給諸位，我認(rèn)為，分享---是件功德無(wú)量的事，互聯(lián)網(wǎng)不就是因此而絢麗多彩嘛！

上篇文章的留言里有好多朋友是對(duì)我css架構(gòu)就http請(qǐng)求的問(wèn)題提出質(zhì)疑，我本想回答的，但不知道從何說(shuō)起。前端性能方面的知識(shí)我了解得并不深入，囫圇吞棗地看過(guò)一兩本重構(gòu)的書、喜歡查查資料，看看一些大牛寫的文章，覺得人家那么做有道理了，就搬過(guò)來(lái)用，林林總總的做些總結(jié)，于是有了此文。都不是什么新東西，但是因?yàn)樾≈R(shí)點(diǎn)太多，希望這里面的東西有你想要的答案吧。

前端性能優(yōu)化--前端工程師不得不說(shuō)的痛
1.html、css、js三者相分離。分離得徹底點(diǎn)！為什么這三者要分離，相信大家都明白，不多說(shuō)。
2.css的導(dǎo)入方式。css用link而不用@import，因?yàn)樵?IE 中 @import 指令等同于把 link 標(biāo)記寫在 HTML 的底部，延長(zhǎng)css的載入時(shí)間，還可能出現(xiàn)文件下載次序被更改的情況。
3.理性對(duì)待jquery。jquery讓我們“write less,do more”，它有太多優(yōu)勢(shì)：強(qiáng)大的選擇器、DOM操作的完美封裝、完善的Ajax、良好的兼容性處理。但是，我們是否就此離不開它呢？我覺得應(yīng)該根據(jù)需求，根據(jù)業(yè)務(wù)邏輯來(lái)。一個(gè)頁(yè)面如果只需要幾行或幾十行js代碼可以搞定的效果，為什么要用jquery？讓頁(yè)面先加載個(gè)jquery.js，再書寫自己的代碼？沒必要吧。
4.合理布局頁(yè)面的內(nèi)容。DOM的加載順序是由上而下的，遇到css，加載css，遇到j(luò)s，停滯下來(lái)，加載并解析js。在布局頁(yè)面的時(shí)候，把主體內(nèi)容優(yōu)先顯示，把重要內(nèi)容靠上布局，讓瀏覽器優(yōu)先解析，是種較好的方案?！?
5.js的導(dǎo)入方式?！秊avascript王者歸來(lái)》里有對(duì)js的導(dǎo)入方式進(jìn)行優(yōu)劣對(duì)比。我個(gè)人認(rèn)為，在不考慮js代碼重用及維護(hù)的前提下(但是往往這點(diǎn)成為我最重要的衡量指標(biāo))，把具有重要業(yè)務(wù)模塊的js代碼置于title里，把次要的具有操作效果的js代碼置于DOM相對(duì)應(yīng)的對(duì)象之后。而這樣做的理論依據(jù)即DOM的加載順序。上面那話不好理解，舉例來(lái)說(shuō)：
 
上圖是QQ音樂(lè)首頁(yè)的導(dǎo)航，主導(dǎo)航的重要作用不言而喻，如下是兩段相應(yīng)的代碼：




兩段代碼的js效果為鼠標(biāo)移到MV菜單項(xiàng)時(shí)顯示子菜單選項(xiàng)。第一段代碼中，當(dāng)瀏覽器解析到<script>標(biāo)簽時(shí)，會(huì)停滯下來(lái)，直到都解析完了，再繼續(xù)往下，當(dāng)MV顯示時(shí)，我們鼠標(biāo)一移上去，子菜單就會(huì)顯示出來(lái)；而第二段代碼中，瀏覽器解析到MV時(shí)，再到<script>，得先加載js，直到完成，子菜單才會(huì)顯示。顯然，對(duì)于這種重要功能模塊，更適合采用第一段代碼。關(guān)于這個(gè)原理，我理解的方向不知道有沒有偏差或者錯(cuò)誤，園中朋友有深入研究的請(qǐng)糾錯(cuò)。

6.圖片文件格式的選擇。關(guān)于這點(diǎn)，淘寶UED的圖片格式與設(shè)計(jì)那點(diǎn)事兒有很深入地探討，我個(gè)人覺得受益匪淺，但是文章太長(zhǎng)，寫得太深入，沒耐心還真看不下去，所以后來(lái)我又自己總結(jié)了下，可以參考下三種圖像文件格式的選擇。當(dāng)時(shí)總結(jié)完這篇文章后，工作的時(shí)候就嚴(yán)格按照這上面的來(lái)執(zhí)行了。

7.sprites貼圖技術(shù)。這是一項(xiàng)從一出現(xiàn)就備受爭(zhēng)議的技術(shù)，第一、我們需要打開ps，把許多小圖標(biāo)有規(guī)則地排放在一起；第二、我們需要打開ps，最好再放大5倍，再水平垂直拉下兩條參考線，然后對(duì)到標(biāo)尺，記下left/top值，寫到css文件里；第三、sprites貼圖技術(shù)與height、line-height關(guān)系緊密，因?yàn)樗鼈?，第二點(diǎn)中定位的left/top又將變得不準(zhǔn)確，這時(shí)你應(yīng)該給圖標(biāo)之間留出一定的間隙，不然當(dāng)心顯示出來(lái)的都是一半的圖標(biāo)哦。我實(shí)在沒精力再去截圖寫代碼來(lái)證明我是對(duì)的，這個(gè)自己可以有。我似乎把這項(xiàng)技術(shù)說(shuō)得一文不值，讓Dave Shea情何以堪！貼圖技術(shù)之所以到現(xiàn)在還在被廣泛使用，我想最主要的原因就是它大大減少了請(qǐng)求數(shù)并在一定程度上減少了圖片的總體積的緣故。跟這兩點(diǎn)比起來(lái)，我前面所說(shuō)的那些缺點(diǎn)似乎不值一提了。

8.讓頁(yè)面漸進(jìn)增強(qiáng)。將分辨率、操作系統(tǒng)、瀏覽器、項(xiàng)目針對(duì)的用戶目標(biāo)群相結(jié)合，在頁(yè)面制作的過(guò)程中采用漸進(jìn)增強(qiáng)的原則。如果項(xiàng)目的用戶目標(biāo)群普遍采用的是1024*768、Mac os x、ie7+瀏覽器，那么在設(shè)計(jì)頁(yè)面的時(shí)候，寬度要做相應(yīng)的限制，最好水平不出現(xiàn)滾動(dòng)條；字體也不再選擇宋體，采用其他web安全字體；接下來(lái)我們開心了，因?yàn)榭梢圆豢紤]ie6，是不是覺得工作忽然間變得很幸福？漸進(jìn)增強(qiáng)不單單可以應(yīng)用到大的方向上，還可以具體到單頁(yè)面模塊中;
（圖1) （圖2）
圖1和圖2是截取自一列表中的一個(gè)li，圖2為鼠標(biāo)移到li上的效果--顯示“取消關(guān)注”。 我將在這模塊中應(yīng)用漸進(jìn)增強(qiáng)原則：第一、需要考慮ie6，那么由于ie6不支持除了a標(biāo)簽以外的其他標(biāo)簽的hover效果，且“取消關(guān)注”又是個(gè)重要的功能，不要不行，所以只能采用js代碼來(lái)實(shí)現(xiàn)鼠標(biāo)移入移出效果；第二、如果不考慮ie6，那么假設(shè)“取消關(guān)注”的標(biāo)簽為span，就可以在css樣式表里這么書寫：li:hover span{display:block;}；第三、如果“取消關(guān)注”功能換成無(wú)關(guān)緊要文字顯示，如時(shí)間顯示，那么一樣可以采用第二點(diǎn)寫法，讓其他瀏覽器顯示、ie6不顯示影響也不大。

9.少用濾鏡、表達(dá)式和hack。這在很多重構(gòu)書上都會(huì)被提到，項(xiàng)目中有對(duì)濾鏡進(jìn)行過(guò)測(cè)試，一堵照片墻過(guò)去，全用上濾鏡，瀏覽器加載頁(yè)面速度那個(gè)慢啊，親眼見到了！表達(dá)式不曉得。hack打一開始就在規(guī)避，幾乎沒用過(guò)，所以不發(fā)表意見。

10.借助一些外在的應(yīng)用來(lái)減少css、js文件的請(qǐng)求數(shù)。php程序的可以考慮用minify來(lái)把每個(gè)頁(yè)面的css和js整合到一起，再在頁(yè)面中進(jìn)行調(diào)用，這樣頁(yè)面就只請(qǐng)求一次css和js，性能會(huì)優(yōu)化許多。
我暫時(shí)能想到的就先寫到這里了。關(guān)于前端性能的優(yōu)化應(yīng)該還有很多，這些都是皮毛而已，慢慢再深入了。好吧，再侃點(diǎn)其他的！

前端與美工人員
前端工程師上銜美工、下接后端、背靠產(chǎn)品，缺一不可。職責(zé)分工要明確，前端要告訴美工能少用圖片盡量少用、合理地選擇圖片的文件格式、網(wǎng)站頁(yè)面風(fēng)格盡量同一、給出網(wǎng)站主業(yè)務(wù)鏈接色、輔鏈接色、主文本顏色和其他文字顏色等等。美工都是單一頁(yè)面做出來(lái)的，往往沒辦法考慮到整個(gè)網(wǎng)站最終的效果，這個(gè)時(shí)候前端就應(yīng)該起到一個(gè)提示的作用，如果這個(gè)環(huán)節(jié)沒把該確定的東西確定下來(lái)，到時(shí)候改版起來(lái)會(huì)相當(dāng)痛苦。

前端與后端人員
把命名方式溝通清楚、跟后端人員解釋前端css、js、image目錄結(jié)構(gòu)定義的想法、了解后端的工作原理。

前端與產(chǎn)品經(jīng)理
每個(gè)職位的人員都不容易，產(chǎn)品經(jīng)理更是，最終對(duì)產(chǎn)品負(fù)責(zé)的還是產(chǎn)品經(jīng)理。不知是否是這樣的原因，我所遇到的產(chǎn)品經(jīng)理都格外細(xì)致，有的甚至細(xì)致到跟原型效果圖差2、3px他都能看得出來(lái)！產(chǎn)品經(jīng)理如果過(guò)于追求細(xì)節(jié)，前端會(huì)很悲催。怎么處理這樣的情況？和產(chǎn)品經(jīng)理一樣站在產(chǎn)品和用戶的角度去思考問(wèn)題，千萬(wàn)不要站在個(gè)人的職位上去想問(wèn)題，不然永遠(yuǎn)無(wú)法說(shuō)服他。當(dāng)然，這有點(diǎn)難度...
終于侃完了，做個(gè)總結(jié)吧，關(guān)于程序設(shè)計(jì)的些許想法：程序跟人生一樣，有的時(shí)候需要妥協(xié)，不能說(shuō)為了減少請(qǐng)求數(shù)，就不注重代碼維護(hù)，對(duì)待使用2M的用戶和10M的用戶是不能使用同樣的處理方式的，網(wǎng)站訪問(wèn)量的多少也應(yīng)該考慮在內(nèi)，多個(gè)方面綜合考慮、權(quán)衡，給出一個(gè)最優(yōu)化方案。我想這才是最合理的。

最新評(píng)論