前言
在上一篇文章《我的css架構理念》中，承蒙園內的朋友們抬愛，竟然一路被推薦，讓我這小小一枚前端攻城獅既意外又興奮進而惶恐。惶恐的是資歷實在有限，知識實在匱乏，相當害怕誤人子弟。此真心話！但接下來我依然會堅持有時間就寫寫文章，既能總結，又能學到新知識，還能分享給諸位，我認為，分享---是件功德無量的事，互聯網不就是因此而絢麗多彩嘛！
上篇文章的留言里有好多朋友是對我css架構就http請求的問題提出質疑，我本想回答的，但不知道從何說起。前端性能方面的知識我了解得並不深入，囫圇吞棗地看過一兩本重構的書、喜歡查查資料，看看一些大牛寫的文章，覺得人家那么做有道理了，就搬過來用，林林總總的做些總結，於是有了此文。都不是什么新東西，但是因為小知識點太多，希望這里面的東西有你想要的答案吧。
前端性能優化--前端工程師不得不說的痛
- html、css、js三者相分離。分離得徹底點！為什么這三者要分離，相信大家都明白，不多說。
- css的導入方式。css用link而不用@import，因為在 IE 中 @import 指令等同於把 link 標記寫在 HTML 的底部，延長css的載入時間，還可能出現文件下載次序被更改的情況。
- 理性對待jquery。jquery讓我們“write less,do more”，它有太多優勢：強大的選擇器、DOM操作的完美封裝、完善的Ajax、良好的兼容性處理。但是，我們是否就此離不開它呢？我覺得應該根據需求，根據業務邏輯來。一個頁面如果只需要幾行或幾十行js代碼可以搞定的效果，為什么要用jquery？讓頁面先加載個jquery.js，再書寫自己的代碼？沒必要吧。
- 合理布局頁面的內容。DOM的加載順序是由上而下的，遇到css，加載css，遇到js，停滯下來，加載並解析js。在布局頁面的時候，把主體內容優先顯示，把重要內容靠上布局，讓瀏覽器優先解析，是種較好的方案。
- js的導入方式。《javascript王者歸來》里有對js的導入方式進行優劣對比。我個人認為，在不考慮js代碼重用及維護的前提下(但是往往這點成為我最重要的衡量指標)，把具有重要業務模塊的js代碼置於title里，把次要的具有操作效果的js代碼置於DOM相對應的對象之后。而這樣做的理論依據即DOM的加載順序。上面那話不好理解，舉例來說：
上圖是QQ音樂首頁的導航，主導航的重要作用不言而喻，如下是兩段相應的代碼：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>test--js導入方式1</title> <script type="text/javascript"> </script> </head> <body> <ul> <li><a href="">首頁</a></li> <li><a href="">樂庫</a></li> <li> <a href="" id="mv">MV</a> <div class=""> <a href="">MV推薦</a> <a href="">MV庫</a> <a href="">音樂現場</a> <a href="">MV專題</a> </div> </li> <li><a href="">我的音樂</a></li> <li><a href="">下載客戶端</a></li> </ul> </body> </html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>test--js導入方式1</title> </head> <body> <ul> <li><a href="">首頁</a></li> <li><a href="">樂庫</a></li> <li> <a href="" id="mv">MV</a> <div class=""> <a href="">MV推薦</a> <a href="">MV庫</a> <a href="">音樂現場</a> <a href="">MV專題</a> </div> </li> <li><a href="">我的音樂</a></li> <li><a href="">下載客戶端</a></li> </ul> <script type="text/javascript"> </script> </body> </html>
兩段代碼的js效果為鼠標移到MV菜單項時顯示子菜單選項。第一段代碼中，當瀏覽器解析到<script>標簽時，會停滯下來，直到都解析完了，再繼續往下，當MV顯示時，我們鼠標一移上去，子菜單就會顯示出來；而第二段代碼中，瀏覽器解析到MV時，再到<script>，得先加載js，直到完成，子菜單才會顯示。顯然，對於這種重要功能模塊，更適合采用第一段代碼。關於這個原理，我理解的方向不知道有沒有偏差或者錯誤，園中朋友有深入研究的請糾錯。
- 圖片文件格式的選擇。關於這點，淘寶UED的圖片格式與設計那點事兒有很深入地探討，我個人覺得受益匪淺，但是文章太長，寫得太深入，沒耐心還真看不下去，所以后來我又自己總結了下，可以參考下三種圖像文件格式的選擇。當時總結完這篇文章后，工作的時候就嚴格按照這上面的來執行了。
- sprites貼圖技術。這是一項從一出現就備受爭議的技術，第一、我們需要打開ps，把許多小圖標有規則地排放在一起；第二、我們需要打開ps，最好再放大5倍，再水平垂直拉下兩條參考線，然后對到標尺，記下left/top值，寫到css文件里；第三、sprites貼圖技術與height、line-height關系緊密，因為它們，第二點中定位的left/top又將變得不准確，這時你應該給圖標之間留出一定的間隙，不然當心顯示出來的都是一半的圖標哦。我實在沒精力再去截圖寫代碼來證明我是對的，這個自己可以有。我似乎把這項技術說得一文不值，讓Dave Shea情何以堪！貼圖技術之所以到現在還在被廣泛使用，我想最主要的原因就是它大大減少了請求數並在一定程度上減少了圖片的總體積的緣故。跟這兩點比起來，我前面所說的那些缺點似乎不值一提了。
- 讓頁面漸進增強。將分辨率、操作系統、瀏覽器、項目針對的用戶目標群相結合，在頁面制作的過程中采用漸進增強的原則。如果項目的用戶目標群普遍采用的是1024*768、Mac os x、ie7+瀏覽器，那么在設計頁面的時候，寬度要做相應的限制，最好水平不出現滾動條；字體也不再選擇宋體，采用其他web安全字體；接下來我們開心了，因為可以不考慮ie6，是不是覺得工作忽然間變得很幸福？漸進增強不單單可以應用到大的方向上，還可以具體到單頁面模塊中：
（圖1)
（圖2） 圖1和圖2是截取自一列表中的一個li，圖2為鼠標移到li上的效果--顯示“取消關注”。 我將在這模塊中應用漸進增強原則：第一、需要考慮ie6，那么由於ie6不支持除了a標簽以外的其他標簽的hover效果，且“取消關注”又是個重要的功能，不要不行，所以只能采用js代碼來實現鼠標移入移出效果；第二、如果不考慮ie6，那么假設“取消關注”的標簽為span，就可以在css樣式表里這么書寫：li:hover span{display:block;}；第三、如果“取消關注”功能換成無關緊要文字顯示，如時間顯示，那么一樣可以采用第二點寫法，讓其他瀏覽器顯示、ie6不顯示影響也不大。
- 少用濾鏡、表達式和hack。這在很多重構書上都會被提到，項目中有對濾鏡進行過測試，一堵照片牆過去，全用上濾鏡，瀏覽器加載頁面速度那個慢啊，親眼見到了！表達式不曉得。hack打一開始就在規避，幾乎沒用過，所以不發表意見。
- 借助一些外在的應用來減少css、js文件的請求數。php程序的可以考慮用minify來把每個頁面的css和js整合到一起，再在頁面中進行調用，這樣頁面就只請求一次css和js，性能會優化許多。
我暫時能想到的就先寫到這里了。關於前端性能的優化應該還有很多，這些都是皮毛而已，慢慢再深入了。好吧，再侃點其他的！
前端與美工人員
前端工程師上銜美工、下接后端、背靠產品，缺一不可。職責分工要明確，前端要告訴美工能少用圖片盡量少用、合理地選擇圖片的文件格式、網站頁面風格盡量同一、給出網站主業務鏈接色、輔鏈接色、主文本顏色和其他文字顏色等等。美工都是單一頁面做出來的，往往沒辦法考慮到整個網站最終的效果，這個時候前端就應該起到一個提示的作用，如果這個環節沒把該確定的東西確定下來，到時候改版起來會相當痛苦。
前端與后端人員
把命名方式溝通清楚、跟后端人員解釋前端css、js、image目錄結構定義的想法、了解后端的工作原理。
前端與產品經理
每個職位的人員都不容易，產品經理更是，最終對產品負責的還是產品經理。不知是否是這樣的原因，我所遇到的產品經理都格外細致，有的甚至細致到跟原型效果圖差2、3px他都能看得出來！產品經理如果過於追求細節，前端會很悲催。怎么處理這樣的情況？和產品經理一樣站在產品和用戶的角度去思考問題，千萬不要站在個人的職位上去想問題，不然永遠無法說服他。當然，這有點難度...
終於侃完了，做個總結吧，關於程序設計的些許想法：程序跟人生一樣，有的時候需要妥協，不能說為了減少請求數，就不注重代碼維護，對待使用2M的用戶和10M的用戶是不能使用同樣的處理方式的，網站訪問量的多少也應該考慮在內，多個方面綜合考慮、權衡，給出一個最優化方案。我想這才是最合理的。