悟道web標準:前端效能優化
前端效能優化完全是一個技術話題，但是對於專案的使用者體驗有非常大的影響，如果你的網站打開要等待三五秒或等到瀏覽器提示無法連接，那網站哪來的流量，哪來的品牌影響和用戶忠誠度，賺錢就算了。
3s，作為判斷一個使用者忍受你網站速度的限度，如果超過3s，使用者已經對這個網站產生了負面的抵觸心理。
前端效能最佳化和web標準有什麼關係，接著第一篇悟道web標準－統一思想，遵循標準，這是對你遵循web標準的一個補償或是對標準的一個認可。
引用:
前端性能優化了解yahoo性能優化N條的同學應該不會陌生，安裝一個YSlow評分並對照著優化就可以了，但是有沒有想過為什麼要這麼做就可以提升速度，這些與Web標準有沒有某種關聯或者因果呢。
我把這些個條目分成三類，服務端運算優化，傳輸優化，客戶端運算優化：
第一類，伺服器端優化
伺服器端就是對你的網站的動態語言的執行(asp,php)，資料庫查詢，儲存等速度，總的來說就是輸入/輸出的運算。這些跟前端沒關係，但是影響前端。 YSlow裡面沒有，鬼知道你網站的伺服器效能如何，看不出來，就自行優化伺服器效能，資料庫效能，多買點伺服器擴容。
yslow有一條儘早刷新Buffer (Flush the Buffer Early)，看起來像是不等html完成產生就傳輸。
提高網域的DNS解析速度。減少DNS的解析個數。這個不好歸類，暫時放到這裡。
落後的頁面工程師體系，美工代勞的頁面代碼，唯獨IE才能瀏覽的頁面代碼，不需要寫代碼用圖形工具直接導出的頁面代碼，大量的流量消耗的頁面代碼，速度慢的像蝸牛的頁面代碼，程式設計師看到就頭大發麻的頁面代碼，每次改版修改都要打動乾戈，重複產生的頁面代碼，一種讓頁面工程師和民工一樣的頁面代碼。
我們當然要革命它，取代他，創造全新的頁面工程師體系和頁面質量，獨立的頁面工程師完成的頁面代碼，跨越平台的頁面代碼，只要能解析頁面的設備都能夠訪問和瀏覽，手寫的頁面代碼，整齊劃一，層次分明，最低流量消耗的頁面代碼，程式設計師喜歡的頁面代碼，訪問速度超快的頁面代碼，改版可重複利用的頁面代碼，讓頁面工程師抬起頭來，驕傲的稱自己是工程師，書寫的也是電腦程式碼的頁面代碼。
前端優化正好給Web標準提供了一個檢驗的機會，用「實踐是檢驗真理的唯一標準」來判斷標準化到底好不好，對不對。