用戶對App或者web的響應速度決定是否留下訪問的各種大數據已經很多,這里就不說性能的重要性了.
1.要從哪開始思考這個問題呢?
2.深入淺出問題的根本
3.再結合STAR法則回答該問題
1.我個人是從IP協議、TCP協議、DNS服務、各協議在使用HTTP協議通信的過程開始思考這個問題的。直接上圖
那么我們可以理解為發送端從低到高封裝，接收端從高到低解封。直接上圖
那么知道了HTTP協議要經過這么多步驟，才能把一個請求發送到服務器，再經過這么多步驟響應回來我們的瀏覽器。再不說還有HTTPS了，步驟更為復雜，耗時更長，響應要比HTTP慢兩到三倍！
那么優化的方法有很多，首先要從代碼規范開始
（1）避免javascript操作DOM
大家都會想到這點，那么一定要操作的話，如何去降低成本的操作DOM呢？
（1.1）不要頻繁的用js修改元素的樣式，那么當修改多條樣式的時候可以直接編寫一個class，為需要操作的元素添加class即可！
element.style.background="...";x
element.style.border="...";x
element.style.color="...";x
element.className="...";//使用jQuery
（1.2）緩存操作結果，避免重復計算。從頁面獲取一個元素是很累的，計算寬高之類的操作也是很繁重的，還有取length，ajax的響應也都統統緩存起來，講一個最經典的demo——Fibonacci
我們都知道Fibonacci是要不斷的重復計算的，那么我們就可以把每次計算的結果緩存到數組里面，下次計算直接取，這樣就方便高效很多了
var Fibonacci=function(){
cache=[0,1];
return function(n){
if (n<2) {
return n;
}
var temp=Fibonacci(n-1)+Fibonacci(n-2);
cache[n]=temp;
return temp;
}
}();
（1.3）可以使用worker！進行巨量計算。之前文章提過worker
（1.4）使用documentFragment進行頻繁操作，操作完再一次添加到頁面
document.createDocumentFragment
（1.5）如果要對頁面元素頻繁操作的時候，為了避免不必要的重繪和重排可以先將元素display:none;再進行頻繁的操作，操作完了再把元素顯示回頁面，那么久可以縮小到兩次的重繪或者重排
（2）使用懶加載：觸發條件后動態添加img的src，可以有效加快首屏的響應速度
（3）使用圖片服務器
（4）布置CDN，
（5）整合壓縮代碼，減少請求，減少請求體積
。。。等等等等，想起來再寫了
那么遵循STAR法則回答問題比如：
場景：我們的網站有很多很多的圖片，加載很慢
方案：使用了懶加載與圖片服務器的優化方案
結果：使用前加載首屏需要一個小時，優化后只用0.035ms
后續更新修改
