學而不思則惘，思而不學則殆
前幾天接到乙個頁面效果優化的任務，邊做邊查閱了一些關於頁面效能的資料。做完任務之後，抽空寫了一篇總結，梳理一下思路，加深自己的理解。
先思考這樣的乙個問題：
什麼叫頁面效能好？如何進行評判？
直觀上講，我們通常會通過乙個頁面流不流暢來判斷乙個頁面的效能好不好。但是開發中，總不能這麼隨意吧。
fps(frame per second)，即一秒之間能夠完成多少次重新渲染.
網頁動畫的每一幀（frame）都是一次重新渲染，每秒低於24幀的動畫，人眼就能感受到停頓。一般的網頁動畫，需要達到每秒30幀到60幀的頻率，才能比較流暢。
而大多數顯示器的重新整理頻率是60hz，為了與系統一致，以及節省電力，瀏覽器會自動按照這個頻率，重新整理動畫。所以，如果網頁能夠做到每秒60幀，就會跟顯示器同步重新整理，達到最佳的視覺效果。這意味著，一秒之內進行60次重新渲染，每次重新渲染的時間不能超過16.66ms。
在實際的開發，只要達到30fps就可以了
強大的chrome給我們提供了乙個工具，叫做timeline，在幀模式下，我們可以看到**的執**況
柱狀'frame'：表示渲染過程中的一幀，也就是瀏覽器為了渲染單個內容塊而必須要做的工作，包括：執行js，處理事件，修改dom，更改樣式和布局，繪製頁面等。幀柱的高度表示了該幀的總耗時，幀柱中的顏色分別對應該幀中包含的不停型別的事件。我們的目標就是控制其在30fps，即1000ms / 30 =33.34ms
30fps和60fps的基準線，可以直觀地看到頁面每一幀的情況
灰色區塊：那些沒有被devtools感知到的活動
空白區塊：顯示重新整理周期（display refresh cycles）中的空閒時間段？？
event ：事件，上面可以看到觸發了什麼的事件，然後執行的語句是哪些，
recalculate style: 重新計算樣式
update layer tree: 【耗時】
composite layers: 【耗時】
paint x n: 【耗時】
接下來思考這個問題：
什麼是update layer tree，什麼是compsite layers，它們為什麼那麼耗時？
要理解update layer tree和composite layers，我們必須了解頁面的渲染原理和過程。
我們都知道網頁生成過程，大致可以分成五步
html**轉化為dom
css**轉化成cssom（css object model）
結合dom和cssom，生成一棵渲染樹（包含每個節點的視覺資訊）
生成布局（layout），即將所有渲染樹的所有節點進行平面合成
將布局繪製（paint）在螢幕上
那麼，瀏覽器是如何進行渲染的？
瀏覽器在渲染乙個頁面時，會將頁面分為很多個圖層，圖層有大有小，每個圖層上有乙個或多個節點。瀏覽器實際所做的工作有：
獲取dom後分隔為多個圖層
對每個圖層的節點計算樣式結果（recalculate style）
為每個節點生成圖形和位置（layout即reflow和重布局）
將每個節點繪製填充到圖層位圖彙總（paint，repaint）
圖層作為紋理載入到gpu
合併多個圖層到頁面上，生成最終影象（composite layers）
渲染的過程通常是相當耗時，低效的**往往就是觸發過程的layout，paint，composite layers，導致頁面卡頓。
明白了整個渲染的過程和timeline的操作的含義，那麼可以思考這樣的乙個問題：
什麼樣的**會觸發這麼耗時的操作，導致我們的頁面卡頓？
網頁生成的時候，至少會渲染一次。而我們需要關注的是使用者訪問過程中，那些會導致網頁重新渲染的行為：
重新渲染，就涉及重排和重繪
重排（reflow）
即重新生成布局，重排必然導致重繪，如元素位置的改變，就會觸發重排和重繪。
會觸發重排的的屬性：
定位屬性及浮動也會觸發重布局：
改變節點內部文字結構也會觸發重布局：
重繪（repaint）
即重新繪製，需要注意的是，重繪不一定需要重排，比如改變某個元素的顏色，就只會觸發重繪，而不會觸發重排。
會觸發重繪的屬性
手機就算重繪也很慢
重排和重繪會不斷觸發，這是不可避免的，但是它們非常消耗資源，是導致網頁效能低下的根本原因。
提高網頁效能，就是要降低重排和重繪的頻率和成本，盡量少觸發重新渲染。
大部分瀏覽器通過佇列化修改和批量顯示優化重排版過程。然而有些操作會強迫重新整理並要求所有計畫改變的部分立刻應用。
1. 建立圖層有什麼用？
我們知道瀏覽器layout和paint是在每乙個圖層上進行的，當有乙個元素經常變化，為了減少這個元素對頁面的影響，我們可以為這個元素建立乙個單獨的圖層，來提供頁面的效能。
2. 在什麼時候會建立圖層？
position為fixed也會建立圖層，而absolute則不會
3. 建立圖層的弊端
圖層的建立也需要一定的開銷，太多的圖層會消耗過多的記憶體。這可能導致出現預期之外的行為，可能會導致潛在的崩潰。
1. 什麼是硬體加速？
現代瀏覽器大都可以利用gpu來加速頁面渲染。在gpu的眾多特性之中，它可以儲存一定數量的紋理（乙個矩形的畫素點集合）並且高效地操作這些紋理（比如進行特定的移動、縮放和旋轉操作）。這些特性在實現乙個流暢的動畫時特別有用。瀏覽器不會在動畫的每一幀都繪製一次，而是生成dom元素的快照，並作為gpu紋理（也被叫做層）儲存起來。之後瀏覽器只需要告訴gpu去轉換指定的紋理來實現dom元素的動畫效果。這就叫做gpu合成，也經常被稱作硬體加速。
2. 怎麼啟用硬體加速？
css animations, transforms 以及 transitions 不會自動開啟gpu加速，而是由瀏覽器的緩慢的軟體渲染引擎來執行。那我們怎樣才可以切換到gpu模式呢，很多瀏覽器提供了某些觸發的css規則。
只需要在css中使用這類屬性，即可開啟硬體加速
3. 硬體加速真的那麼好嗎？
從本人在移動端開發的實踐來看，硬體加速是比較坑的。開啟硬體加速會占有手機過多的記憶體而導致手機卡頓（這個時候頁面也肯定卡頓了），因此在我們團隊中，是禁止掉硬體加速的。
具體的原理可以參考鏈結5
做完這個任務之後， 才覺得自己真正是在做開發。嚴謹細緻的工匠精神，把控好自己的每一行**。面對複雜的問題，一步步分析情況，查閱資料，不斷地debug，感覺提高不少。希望自己繼續加油，也與抽空看這篇文章的你共勉。
效能優化實踐
由於系統表資料量達到百萬級別，所有就遇到了效能優化問題。總結解決問題思路如下 1 從使用者角度來說，介面的資料載入緩慢，超過5秒就是存在效能問題了。解決問題思路，首先，先確定瓶頸點在 確定是 的問題還是sql的問題，可以通過debug除錯或者日誌或者擷取堆疊資訊檢視耗時來確定。2 如果是 層面的問題...
頁面效能優化
以前的老大說過一句話，乙個頁面誰都能做。關鍵是誰能做好，乙個好是很關鍵的，首先是細節處理的好，效能優化的好。效能優化越來越重要，尤其是終端裝置越來越普及的今天，我也看了好多這方面的資料，總結一下有以下幾條 2 減少瀏覽器重繪和重排的次數 重繪會由改變元素的樣式如顏色visibility,重排是改變元...
頁面效能優化
提公升頁面效能的方法有哪些？1.資源壓縮合併，減少http請求 2.非核心 非同步載入 非同步載入的方式？1.動態指令碼載入 2.defer 直接在script標籤的上加 3.async 非同步載入的區別 1.defer是在html解析完之後才會去執行，如果是多個，按照載入的順序依次執行 2.asy...