DevToolsのTimelineパネルを見ながら、レンダリングの仕組みを理解する

[CYBIRDエンジニア Advent Calendar 2015](http://qiita.com/advent-calendar/2015/cybird) 23日目を担当する@cy-mitsukiです。

昨日は@cy-yuto-kurosawaさんの[サーベルが振りたかった](http://qiita.com/cy-yuto-kurosawa/items/47dd4cc9a837c93d56ac)でした。
私も先週から寝込んでいたので[Lightsaber Escape](https://lightsaber.withgoogle.com/)を知らなかったんですけど、なにこれすごい！
Webの技術はどんどん進化していってますねー。@cy-yuto-kurosawaさんの続報に期待します！

# はじめに
ブラウザのレンダリングの仕組みについては[HTML5 Rocks](http://www.html5rocks.com/ja/tutorials/internals/howbrowserswork/)で詳細な解説がされています。
とても丁寧に書かれているのですが、ちゃんと理解できている自信がないです。。
そこで、DevToolsのTimelineパネルを見ながら、実際にどのような処理が行われているのか確認していきます。

この確認手法を知っておくと、Webパフォーマンスの改善にも役立てることができますよ！

なお本記事では、レンダリングエンジンのメインフローのみを扱います。
**クリティカルレンダリングパス**とも呼ばれている下記の領域です。

![image4.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/a5a11183-a638-e79f-b18a-1779a7fd89d2.jpeg)
画像引用元：[Optimizing the Critical Rendering Path](https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present?slide=id.p19)

入門的な内容にしたいので、HTMLとCSSの話が中心です。
JavaScriptに関しては取り扱いません。

あと、[Chrome Canary](https://www.google.co.jp/chrome/browser/canary.html)  (version 49)を使用していきますよ。

やや推測も入っているので、間違いがありましたらご指摘お願いします。m(_ _)m

# Timelineパネルの使い方
初期状態では何も表示されていないので、ページをリロードしましょう。
すると、ページの表示で発生した処理（イベント）レコードを見ることができます。
ページ表示後の処理を確認したい場合は、Recordボタンを押すと記録が始まります。
本記事では**Event Logタブ**を開いて、発生時間でソートします。

![image-1.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/29f140c6-9075-8c6c-b5cc-5e1a5b2542e8.jpeg)


# レコードの種類
レコードは4種類にカテゴライズされています。
内容は下記の通りです。

![image2.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/87ac87ed-7a94-0989-5245-7707b96c7263.jpeg)

|レコードの種類|内容|
|---|---|---|
|Loading (青)| ネットワークの送受信。HTMLのパース |
|Scripting (橙)| JavaScriptの実行。イベント処理や関数呼び出し |
|Rendering (紫)| DOMのスタイルやレイアウトに関する処理 |
|Painting (緑)| 画面への描画に関する処理 |


# HTMLを読み込んで、仕組みを理解する
今回読み込むHTMLは下記になります。非常にシンプルです。

```HTML
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Sample</title>
  </head>
  <body>
    <p>Text</p>
  </body>
</html>
```
## 結果
![image3.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/09821708-1274-de46-a808-ad2d6e9d1f82.jpeg)

## 解説
上から順に要所を絞って見ていきます。
「Finish Loading」レコードまでの説明は省略します。

**Parse HTML**
取得したHTMLファイルを解析しています。
レコードを展開すると、5つのScriptingと２つのRenderingが発生しています。
上から2つ目のEventは**DOMContentLoaded**だったので、Parse HTMLのレコード（Self Time 0.3ms）でDOMツリーの構築は完了しているようです。

**Recalculate Style**
要素（DOM）とスタイル（CSSOM）を結びつけています。
ここでレンダーツリーの構築が行われています。
※ 今回のHTMLにCSSは書いていませんが、ブラウザにはデフォルトスタイルがあります。

**Layout**
レンダーツリーの各DOMのスタイル情報をもとに、レイアウト（位置）を決定しています。

**Update Layer Tree**
GPUが処理を行うレイヤを更新しています。
レイヤという概念が元記事に書かれていなかった気がするので後ほど説明します。

**Paint**
DOMに対してピクセルを埋め込んで画面に描画します。

**Composite Layers**
GPUが処理するレイヤーを描画しています。

以上が、レンダリングの基本的な流れになります。

### レイヤとは何か
**レイヤ**とは、GPUが処理する領域を意味します。
レイヤは下記の手順で可視化することができます。

1. chrome://flags/ を開く
2. 合成された表示レイヤの境界線 (#composited-layer-borders) を有効にする

これを実施すると、ドキュメント上にタイルが表示されるようになります。
（このタイルは直接関係ありません）

オレンジ色の境界線で囲われた部分がレイヤになります。
ドキュメント全体もレイヤになっていることが分かります。
（ページスクロールもGPUの処理です）

![image12.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/226ecd30-4806-3b50-9642-dc5098833a92.jpeg)

右の画面は、p要素にtransformプロパティをあてています。
tranformプロパティはGPUで処理されていることが分かります。

```html
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Sample</title>
    <style>
    .text {
      width: 100px;
      transform: rotateY(30deg) rotateX(-30deg);
    }
    </style>
  </head>
  <body>
    <p class="text">Text</p>
  </body>
</html>
```

GPUって何？という方は、こちらの記事がとても分かりやすかったので紹介します。
[スムーズなアニメーションを実装するコツと仕組みを説明するよ。CPUとGPUを理解しハードウェアアクセラレーションを駆使するのだ！（Frontrend Advent Calendar 2013 – 06日目） | Ginpen.com](http://ginpen.com/2013/12/06/hardware-acceleration/)


### Layout、Paint、Compositeに影響するCSSプロパティ
**Layout**は位置や大きさに関するプロパティが影響します。
`width`, `height`, `margin`, `padding`, `top/left`...などです。

**Paint**は色や見た目に関するプロパティが影響します。
`color`, `background`, `border-radius`, `box-shadow`...などです。

**Composite (Layer)**は`transform`, `opacity`などのプロパティが影響します。

影響するCSSプロパティを調査をしたいときは[CSS Triggers...](http://csstriggers.com/)が便利です。


# バッドプラクティスの検証
なんとなくわかってきたところで、よく耳にする簡単なバッドプラクティスを検証してみます。
今回は2つの例を取り上げます。

## img要素にサイズを明示しない
img要素のサイズを明示しないとパフォーマンスが落ちるという話

```html
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Sample</title>
  </head>
  <body>
    <img src="image.jpg">
  </body>
</html>
```

### 結果
![img1.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/439b8bae-cd6d-0071-3db3-b8cb3dcc398d.jpeg)
※ Scriptingの表示をOFFにしています

Parse HTML内のSend Requestで画像をリクエストしています。
画像のレスポンスを受け取っているのは、Layoutが終わったあとなので、
受け取った画像のサイズをもとに、再度Layoutからのレンダリングをおこなっています。
これは非効率ですね。

最初から画像のサイズを指定しておけば、再度Layoutは行われません。

```html
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Sample</title>
  </head>
  <body>
    <img src="image.jpg" width="240px" height="240px">
  </body>
</html>
```
### 最適化した結果
![img2.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/82b47569-d445-8f1f-05c4-f55d5f844698.jpeg)


## アニメーションにGPUを使用しない
アニメーションはGPUで実装しないとパフォーマンスが落ちるという話

```html
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Sample</title>
    <style>
    .box {
      width: 50px;
      height: 50px;
      background-color: blue;
      position: absolute;
      animation: anime 5s ease -2s infinite alternate;
    }
    @keyframes anime {
        0% {left: 0;}
      100% {left: 200px;}
    }
    </style>
  </head>
  <body>
    <div class="box"></div>
  </body>
</html>
```

### 結果
![anim1.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/ab9e178d-c7a9-7a5a-5a83-9551d75f7ea0.jpeg)

Recalculate Styleからの処理を何度も繰り返しているので、
パフォーマンスが大きく低下していることが一目同然です。
この繰り返し処理は永遠に続きます。

このような処理はレイヤを生成してくれるGPUに任せるのが定石ですね。

```html
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Sample</title>
    <style>
    .box {
      width: 50px;
      height: 50px;
      background-color: blue;
      position: absolute;
      animation: anime 5s ease -2s infinite alternate;
    }
    @keyframes anime {
        0% {transform: translate(0px, 0px);}
      100% {transform: translate(200px, 0px);}
    }
    </style>
  </head>
  <body>
    <div class="box"></div>
  </body>
</html>
```

### 最適化した結果
![anim2.jpg](https://qiita-image-store.s3.amazonaws.com/0/59974/b36a23dc-5f38-f08a-d701-a5928f9e995e.jpeg)

# 最後に
いかがでしたでしょうか。
今日はTimelineパネルの見方と、「レンダリング」で行われていることについてまとめてみました。

シンプルなHTMLとCSSのみでの解説でしたが、実際にはもっと大量で複雑なレコードが生成されます。
まずは基本をしっかり理解して、パフォーマンスの改善に取り組んでいきましょう！
より深い情報を知りたい場合は、このあとに記載する参考資料を要チェックです。

明日の[CYBIRDエンジニア Advent Calendar 2015](http://qiita.com/advent-calendar/2015/cybird)は、 1日目も担当した@gotyooooさんの再登場です。
1日目では[最近のCYBIRDゲームインフラ環境を晒してくれましたが、](http://qiita.com/gotyoooo/items/70e98e058ce0344c9cba)次回はどんな記事になるのでしょうか。楽しみですね。

#参考資料
- [ブラウザのしくみ: 最新ウェブブラウザの内部構造 - HTML5 Rocks](http://www.html5rocks.com/ja/tutorials/internals/howbrowserswork/)
- [Chrome Developer Toolsを使いこなそう！ - SlideShare](http://www.slideshare.net/yoshikawa_t/chrome-developer-tools-17787728)
- [ハイパフォーマンス・アニメーション - HTML5 Rocks](http://www.html5rocks.com/ja/tutorials/speed/high-performance-animations/)
- [Accelerated Rendering in Chrome: The Layer Model - HTML5 Rocks](http://www.html5rocks.com/ja/tutorials/speed/layers/)
- [CSS will-changeプロパティについて知っておくべきこと - Dev.Opera](https://dev.opera.com/articles/ja/css-will-change-property/)
- [パフォーマンスの最適化 | Web Fundamentals - Google Developers](https://developers.google.com/web/fundamentals/performance/?hl=ja)