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