摘要：頁面性能優化學而不思則惘，思而不學則殆前幾天接到一個頁面效果優化的任務，邊做邊查閱了一些關于頁面性能的資料。可能只需要在中使用這類屬性，即可開啟硬件加速硬件加速真的那么好嗎從本人在移動端開發的實踐來看，硬件加速是比較坑的。

學而不思則惘，思而不學則殆

前幾天接到一個頁面效果優化的任務，邊做邊查閱了一些關于頁面性能的資料。做完任務之后，抽空寫了一篇總結，梳理一下思路，加深自己的理解。

先思考這樣的一個問題：

什么叫頁面性能好？如何進行評判？

直觀上講，我們通常會通過一個頁面流不流暢來判斷一個頁面的性能好不好。但是開發中，總不能這么隨意吧。

FPS(frame per second)，即一秒之間能夠完成多少次重新渲染.

網頁動畫的每一幀（frame）都是一次重新渲染，每秒低于24幀的動畫，人眼就能感受到停頓。一般的網頁動畫，需要達到每秒30幀到60幀的頻率，才能比較流暢。

而大多數顯示器的刷新頻率是60Hz，為了與系統一致，以及節省電力，瀏覽器會自動按照這個頻率，刷新動畫。所以，如果網頁能夠做到每秒60幀，就會跟顯示器同步刷新，達到最佳的視覺效果。這意味著，一秒之內進行60次重新渲染，每次重新渲染的時間不能超過16.66ms。

在實際的開發，只要達到30fps就可以了

強大的chrome給我們提供了一個工具，叫做timeline，在幀模式下，我們可以看到代碼的執行情況

柱狀"frame"：表示渲染過程中的一幀，也就是瀏覽器為了渲染單個內容塊而必須要做的工作，包括：執行js，處理事件，修改DOM，更改樣式和布局，繪制頁面等。幀柱的高度表示了該幀的總耗時，幀柱中的顏色分別對應該幀中包含的不停類型的事件。我們的目標就是控制其在30fps，即1000ms / 30 = 33.34ms

藍色: 網絡和HTML解析

黃色: JavaScript 腳本運行

紫色: 樣式重計算和布局 ( Layout , Recaculate Style, Update Layer tree)

綠色: 繪制和合成 ( Paint , Composite Layers)

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的操作的含義，那么可以思考這樣的一個問題：

什么樣的代碼會觸發這么耗時的操作，導致我們的頁面卡頓？

網頁生成的時候，至少會渲染一次。而我們需要關注的是用戶訪問過程中，那些會導致網頁重新渲染的行為：

修改DOM

修改樣式表

用戶事件（例如鼠標懸停，頁面滾動，輸入框輸入文字等）

重新渲染，就涉及重排和重繪

重排（reflow）

即重新生成布局，重排必然導致重繪，如元素位置的改變，就會觸發重排和重繪。

會觸發重排的的屬性：

盒子模型相關屬性會觸發重布局：

width

height

padding

margin

display

border-width

border

min-height

定位屬性及浮動也會觸發重布局：

top

bottom

left

right

position

float

clear

改變節點內部文字結構也會觸發重布局：

text-align

overflow-y

font-weight

overflow

font-family

line-height

vertival-align

white-space

font-size

重繪（repaint）

即重新繪制，需要注意的是，重繪不一定需要重排，比如改變某個元素的顏色，就只會觸發重繪，而不會觸發重排。

會觸發重繪的屬性

color

border-style

border-radius

visibility

text-decoration

background

background-image

background-position

background-repeat

background-size

outline-color

outline

outline-style

outline-width

box-shadow

手機就算重繪也很慢

重排和重繪會不斷觸發，這是不可避免的，但是它們非常消耗資源，是導致網頁性能低下的根本原因。

提高網頁性能，就是要降低重排和重繪的頻率和成本，盡量少觸發重新渲染。

大部分瀏覽器通過隊列化修改和批量顯示優化重排版過程。然而有些操作會強迫刷新并要求所有計劃改變的部分立刻應用。

1. 創建圖層有什么用？

我們知道瀏覽器layout和paint是在每一個圖層上進行的，當有一個元素經常變化，為了減少這個元素對頁面的影響，我們可以為這個元素創建一個多帶帶的圖層，來提供頁面的性能。

2. 在什么時候會創建圖層？

3D或透視變換（perspective transform）CSS屬性（例如translateZ(0)/translate3d(0,0,0)）

使用加速視頻解碼的

擁有3D（WebGL）上下文或加速的2D上下文的節點

混合插件（如Flash）

對自己的opacity做CSS動畫或使用一個動畫webkit變換的元素

擁有加速CSS過濾器的元素

元素有一個包含復合層的后代節點（一個元素擁有一個子元素，該子元素在自己的層里）

元素有一個z-index較低且包含一個復合層的兄弟元素（換句話說就是該元素在復合層上面渲染）

position為fixed也會創建圖層，而absolute則不會

3. 創建圖層的弊端

圖層的創建也需要一定的開銷，太多的圖層會消耗過多的內存。這可能導致出現預期之外的行為，可能會導致潛在的崩潰。

1. 什么是硬件加速？

現代瀏覽器大都可以利用GPU來加速頁面渲染。在GPU的眾多特性之中，它可以存儲一定數量的紋理（一個矩形的像素點集合）并且高效地操作這些紋理（比如進行特定的移動、縮放和旋轉操作）。這些特性在實現一個流暢的動畫時特別有用。瀏覽器不會在動畫的每一幀都繪制一次，而是生成DOM元素的快照，并作為GPU紋理（也被叫做層）存儲起來。之后瀏覽器只需要告訴GPU去轉換指定的紋理來實現DOM元素的動畫效果。這就叫做GPU合成，也經常被稱作硬件加速。

2. 怎么啟用硬件加速？

CSS animations, transforms 以及 transitions 不會自動開啟GPU加速，而是由瀏覽器的緩慢的軟件渲染引擎來執行。那我們怎樣才可以切換到GPU模式呢，很多瀏覽器提供了某些觸發的CSS規則。

translate3d(0,0,0)

rotate3d(0,0,0,0)

scale3d(0,0,0)

translateZ(0)【可能】

只需要在css中使用這類屬性，即可開啟硬件加速

3. 硬件加速真的那么好嗎？

從本人在移動端開發的實踐來看，硬件加速是比較坑的。開啟硬件加速會占有手機過多的內存而導致手機卡頓（這個時候頁面也肯定卡頓了），因此在我們團隊中，是禁止掉硬件加速的。

具體的原理可以參考鏈接5

做完這個任務之后， 才覺得自己真正是在做開發。嚴謹細致的工匠精神，把控好自己的每一行代碼。面對復雜的問題，一步步分析情況，查閱資料，不斷地debug，感覺提高不少。希望自己繼續加油，也與抽空看這篇文章的你共勉。

http://frontenddev.org/link/the-timeline-panel-of-the-chrome-developer-tools.html#heading-1-2

https://segmentfault.com/a/1190000003991459

http://gold.xitu.io/entry/5584c9a2e4b06b8a728fe53d

https://segmentfault.com/a/1190000000490328

http://efe.baidu.com/blog/hardware-accelerated-css-the-nice-vs-the-naughty/