一名網頁設計師在做具體設計的時候應該考慮的問題有哪些？業務，產品，信息結構，交互，視覺……別忘了還有頁面性能。我所崇尚的其實一直都是小作坊似的創業團隊協作開發模式，大伙兒能快速溝通，就算設計師沒關注到頁面性能這一點，前端同學也能迅速提醒他，因為他倆就無時無刻不在一起。而現在在標准項目流程中，大家的溝通成本成倍增加了，除非是與世隔絕的閉關（就算是閉關，前端同學多半也在陪著開發），前端同學很難在頁面設計過程中就和設計師溝通頁面性能的問題。
頁面性能的重要性不再贅述，就我個人而言，能忍受一個網站加載出DOM和css的時間是5秒，否則就會毫不猶豫的關閉網頁。上面羅嗦了半天，實際上只想說明一個問題，設計師需要考慮頁面性能。實際上設計師就是一種“通才”的角色。在傳統設計領域，多數設計大師都是通曉好幾個行業，比如科拉尼。在設計過程中充分考慮到各種因素，這是設計的難點，也是成就一個好設計的關鍵所在。以往那種網頁設計師做好psd圖稿，扔給前端工程師去做DEMO的時代已經過去了，因為互聯網進步了，用戶進步了。
浏覽器的原生控件雖然有其不足之處：ie的外觀很難控制；不能支持更加豐富復雜的交互等等，但它對浏覽器的兼容支持得特別好，在用戶需要費力填寫表單的地方，原生控件相比非原生控件會提高性能，讓用戶操作起來很流暢。這也是為什麼在一些銀行的網站或者客戶端上，會用原生的select來代替很多支持復雜的交互控件，比如選擇銀行。在滿足設計需求的前提下，優先考慮原生控件會讓你的頁面更快，兼容性更好，你的前端同學也會少許多抱怨。設計師應當了解，在寫具體應用中控件時，不止是展現出用戶可操作的部分就完事了，還有很多事情要做：驗證，安全，兼容，框架等等。這裡可看財付通的付款頁面的js請求數，會嚇你一跳的。
我在使用招行專業版客戶端的時候，遇到過一個很好的控件交互設計。需求是填寫銀行卡的開戶支行，給用戶一個input讓他自己去填顯然是不靠譜的。招行的做法是先給一個搜索框，讓用戶輸入關鍵字，比如我住在西湖區，我就輸入西湖二字，頁面刷新之後返回一個結果列表，從中用戶來選擇支行，這樣搜索過濾之後的結果，只有10條左右，容易辨認。而我只用了兩次就學會了這種操作，額外的好處是操作過程中頁面反應相當快。而我在其他網站上選擇開戶行支行的時候，遇到過省市，再選支行聯動控件，輸入+下拉列表混合控件，選擇的時候都能方便且正確的選中，但是我點擊控件的時候相應速度卻有延遲，心裡略有不爽，這就是差別。有關原生控件和復雜控件的應用對比，可見我的一篇舊文：易用且輕量級的交互設計。
而隨著html5的標准日益完善，新的原生控件會滿足更多的需求，比如外聯數據源xml，浏覽器內置的不同數據類型的驗證，這些會大大減少js的體積。當然這依賴著國內ie6市場份額的進一步下降（目前為60%）。相信未來一些輕量級的非原生控件，也會慢慢納入到html的標准之中，比如困擾過很多人的日期控件。
我並不完全贊同設計師必須要懂代碼，這應是因人而異的。但一個好的網頁設計師，必須要為頁面框架考慮，小到一個頁面上的一個控件，大到一個項目。這是經驗的積累，並不依靠對代碼的理解，和設計原則中的一致性是密切相關的。不僅僅是少兩張圖片，少兩行代碼，充分考慮css框架的設計，組件的重用，圖片的分割和整合，這些能讓頁面性能提高不止一個檔次，同時保證設計感。
我感於日常工作及學習中，大家討論設計時設計頁面性能的次數十分少，而它又是項目中設計師和前端最主要的分歧點，為了消弭這種分歧，最好的做法就是大家互相增進了解。我在公司裡有給設計師分享前端知識，給前端分享photoshop知識，也是為了大家一起進步做出更好的產品和應用。其實在自己的博客上實踐提高頁面性能的各種方法，是相當輕便且有效的，實踐過的常識經過轉化再提煉，成為知識，這點我十分認同白鴉和千鳥的看法。
http://www.shimuuu.com/blog/web-designer-should-focus-on-page-speed