性能優化是老生常談了，從雅虎的N條軍規，前端各種優化準則，到2010年Google IO上 Steven 提出的高性能建站指南，都在告訴開發者，一個站點的性能非常重要，如何在有限的帶寬條件下，達到極限的訪問性能，如何讓訪問者，無論是從響應速度，視覺感官，操作流暢度都達到最佳體驗, 是目前Web技術上的一個至關重要的挑戰.
相較於前端， 後端的性能優化手段非常多。 這裡前端的放在後面討論，先從Back-End開始.
Back-End 後端工程
1. 使用Nginx做轉發
Nginx作為一個開源的高性能負載均衡的HTTP和反向代理服務器， 是開源界的業界標杆之作， 一般來說，通過後臺程序啟動的服務， 通過Nginx作轉發可以輕鬆的做到：
負載均衡
限制對於資源路徑的訪問
對靜態資源自動開啟Gzip壓縮
配合分佈式服務器架構
2. Redis , Varnish 做緩存
使用緩存中間層可以極大程度上的減少對於數據庫的重複讀寫操作次數，減小服務器的壓力。極限配置過的Varnish緩存層面可以自動檢測到已經修改的文件，沒有改變的文件則告訴客戶端使用緩存，而改變過的文件會自動返回新的文件，這種技術詳情請見 Github IO 站點， 非常適合靜態資源
減少對於數據庫層面的讀寫操作
緩存靜態數據，配置，資源
併發量大時, 減小服務器壓力
3. 字段加密，字段壓縮
從後端的開發角度來說，直接讀寫數據庫之後，原樣返回數據庫對應字段作為響應數據是一種極其懶惰愚蠢的行為，這樣的做法不單是告訴攻擊者數據庫的字段就是這樣的， 更是讓有經驗的人容易的揣測到數據庫的表結構。所以字段的加密， 字段的壓縮，就變得極其的重要.
字段的加密, 壓縮意思是指，從數據庫中拿出的對應數據自動轉化成非邏輯形態數據
id: 201293 a : 201293name: "Sam" -> z : 88score: 88 n : "U2Ft"
配合前端的filter的層面，將數據轉化成視圖對應所需要的平行話格式
4. 靜態資源分離，發佈自動化
運維當然是必不可少的，將靜態資源自動抽離，通過Python，或者Shell腳本自動化將靜態資源分佈到CDN服務器，替換對應的文本等操作， 內存監控等一系列的task，當然，中小公司很少有這麼專業的幹活。
Front-End 前端工程
1. JS CSS極簡化, 減少文件大小
從帶寬能力的角度上來說，一個站點的訪問速度，最直觀的其實是從文件的大小入手，而不是執行效率。 當併發量變得極其龐大時（Google首頁，百度首頁），減少css和js的文件大小就變得相當的重要，假設每秒一個訪問者每次訪問該站點可以少加載 2KB 大小的資源的加載， 那麼100個訪問者會怎麼樣？ 1000個訪問者， 1000萬個訪問者呢？這就是為什麼 騰訊QQ空間項目組，減少CSS JS文件大小10KB就有豐厚的年終獎的原因了.
至於減少字節的各種奇技淫巧我就不展示那麼詳細了，舉個幾個例子
Css
// 減少1字節font-weight: bold -> font-weight:700// 組合寫法// 減少n字節margin-top:**
Javascript
var str = "abcd"if(str.indexOf("d") === -1)2. 真正意義上將樣式，配置邏輯embed到頁面中，從而減少http請求
CSS放在頭部加載，JS放在尾部加載 這種調調聽的太多了，人云亦云，123456789，跟著一起喊，實際情況並不是這樣，現代瀏覽器越來越快，多線程並行加載CSS的能力得到了巨幅提升，很多人沒有真正去理解Steven在2010年Google IO大會上論述的：“減少http請求”
通過觀察 Google的首頁我們發現，居然沒有CSS請求？ 查看頁面源碼時發現， Google將樣式embed到了頁面中一起加載過來 。
這樣的做法有4個好處
瀏覽器預先加載CSS 不會執行並行加載CSS文件，減少http請求
隨頁面享受Gzip壓縮，並且隨時可以解決緩存問題
embed在頁面中，瀏覽器預解析，不會造成並行下載css同時解析html時出現的迴流或者重繪等問題
讓觀察者無法輕鬆調試，定位，甚至修改。
3. 圖片的壓縮, 靜態資源 CDN化
主要是將圖片，CSS， JS 等資源，CDN化，從而很大程度上減少主服務器的壓力. 圖片壓縮，WebP 格式可以說是Web圖片格式的未來趨勢，壓縮算法真心屌, 不過只有Chrome和Opera支持的最好， 其他瀏覽器都不太Care，希望Chrome趕緊一統江湖吧.
一般的JPG其實只需要70%的質量就差不多了. 但是，它仍然不是最理想的狀態， 圖片的除了壓縮質量以外，還需要移除掉圖片的其他信息，壓縮最好是在後端完成，而不是用前端的Canvas（需要考慮Base64碼比原圖片要大的問題）
4. 視圖層使用js模版，或者完整的View框架（React），以Lazyload的形式分塊加載
看看淘寶和天貓首頁是怎麼做的就知道了，將視圖模版化，訪問者滾動時才加載對應的數據，從而很大程度上減少一次性數據的傳輸量.
5. CSS JS選擇器ID化
這一點可能很多人不相信，而一段時間的總結和實踐後我發現，ID選擇器是最快的， 主業務邏輯的元素綁定ID是一種非常不錯的做法，而給ID寫樣式，也不是一種糟糕的實踐，而可以一定程度上加快解析，渲染的速度。詳情可以參見Google首頁的樣式 ， 非常多的ID寫法.
YouTube 作為全球最大的視頻網站，每天都承載了數億級別的PV，自然YouTube的前端必須要做到極致，為了加快渲染速度，除了Embed CSS和 JS之外， CSS大部分使用了ID的寫法, 更多細節請科學上網:
6. PC站點和移動端完全分開，拒絕響應式
2011年前後掀起的響應式站點浪潮，其中最著名的CSS框架相信大家絕對不會陌生，BootStrap, 也是Github 上少有的可以突破10萬Star的項目， 一個站點，多屏幕，多設備適配，通過編寫不同的Media Query CSS就可以做到，但是從性能角度來講確是一個非常糟糕的實踐. 所以基本上沒有大公司搞響應式（國內)
其缺點如下:
多餘的HTML結構和CSS樣式，在media query下不同屏幕要對css進行重寫或者增強
同樣的圖片可能需要兩套 （小屏幕，大屏幕)
Sprite IMG 無法得到充分的利用， Background Size ， Position微小像素差等問題
其實根本沒有人會閒的蛋疼的去不停的縮放屏幕
兩套事件綁定（Click，Tap） 偷懶的話只用Click事件，導致點擊觸控方面體驗極差
資源文件體積過大， 不利於優化, 手機加載解析速度慢
7. 活用LocalStorage, 存儲用戶狀態, 組件狀態，而非JS或者模板
之前看到有文章說“利用LocalStorage存儲JS”， 當然這種做法是錯誤的，極其不靠譜，問題就在於把JS存在LocalStorage中很容易遭到XSS攻擊，另外，存儲模板也不靠譜，模板最好是直接輸出在頁面後直接進行編譯，不要存儲在LocalStorage中，會涉及到模板緩存，佔用空間， 暴露視圖邏輯等問題. 同時，存儲時最好進行加密（關鍵字段）
經過長時間的實踐， LocalStorage最適合存儲用戶狀態， 組件狀態（和業務邏輯，數據邏輯無半毛錢關係的狀態），等不涉及到業務數據存儲的字段 比如：
用戶的搜索記錄
用戶的名稱，ID，上一次訪問的URL地址
組件的使用記錄（狀態）
用戶的UA
後臺輸出的固定數據，需要在請求時帶回去的字段
8. 給視圖根元素定義固定的Height和Width
一直以來，重繪和迴流都是前端很討厭的問題， 很多網站，加載之後，佈局樣式會出現 “抖” 一下的情況，甚至整個頁面“閃一下“，”跳一下” ？ 其實都是出現了嚴重的重繪，為了防止出現這種情況，我們給每一個可以預測板式的元素都定義固定的高度和寬度，保證內部的元素在懶加載（LazyLoad) 或者直接渲染時, 不會造成視圖根元素的抖動，從而間接的影響到周圍元素的排版，詳情你可以參考一下天貓首頁樣式
9. DNS 網絡解析加速, 並且利用好站長工具
此優化屬於網絡層面，當然也是值得一提的，具體這裡不闡述，提一下.
利用好站長工具，這裡不是指提高訪問量或者SEO。