[サンプルを見る](https://googlesamples.github.io/web-fundamentals/fundamentals/performance/critical-rendering-path/script.html){: target="_blank" .external }

* JavaScript では、DOM の要素の新規作成、スタイル設定、追加、削除を行うこともできます。技術的には、ページ全体を単一の大きな JavaScript ファイルにして、1 つずつ要素を作成してスタイル設定を行うことも可能です。ただし、実際には HTML や CSS と連携させる方がはるかに簡単です。この JavaScript 関数の後半では、新しい div 要素を作成し、テキスト コンテンツ、スタイルの設定を行って、body に追加しています。

* サーバーまでのネットワーク ラウンドトリップ（プロパゲーション レイテンシ）は 100 ms

* サーバーの応答時間は、HTML ドキュメントの場合は 100 ms、その他のファイルの場合は 10 ms

<pre class="prettyprint">

{% includecode content_path="web/fundamentals/performance/critical-rendering-path/_code/basic_dom_nostyle.html" region_tag="full" adjust_indentation="auto" %}

ただし、`load` イベント（`onload`）は、画像によってブロックされます。DevTools では、335 ms で `onload` イベントが記録されています。前に説明したとおり、`onload` イベントは、ページに必要な**すべてのリソース**がダウンロードされ、処理が完了した時点を表します。この段階で、ブラウザの読み込み中マークの回転が止まります（ウォーターフォール上の赤色の縦線に相当）。

「Hello World サンプル」ページは、一見するとシンプルに見えますが、内部ではさまざまな処理が実行されていました。また、現実的には HTML 以外の要素も必要になります。CSS スタイルシートと 1 つ以上のスクリプトを組み合わせて、インタラクティブなページにするケースも多くあります。この両者をサンプルに追加して、どうなるか見てみましょう。

[サンプルを見る](https://googlesamples.github.io/web-fundamentals/fundamentals/performance/critical-rendering-path/measure_crp_timing.html){: target="_blank" .external }

<img src="images/waterfall-dom.png" alt="DOM の CRP" >

<img src="images/waterfall-dom-css-inline-js-inline.png" alt="DOM、インライン CSS、インライン JS" >

以上のように、非常にシンプルなページでも、クリティカル レンダリング パスの最適化は簡単ではありません。さまざまなリソース間の依存関係図を把握し、どのリソースが「クリティカル」であるか特定し、そのようなリソースをページに組み込む方法をさまざまな戦略の中から選ぶ必要があります。ただし、ページごとに違いがあるため、対策は 1 つではありません。最適な戦略を特定するには、このようなプロセスを自身で実践する必要があります。

では、これらのことを踏まえて、一般的なパフォーマンス パターンを特定していきましょう。

最もシンプルなページは、CSS、JavaScript、その他のリソースを含まず、HTML マークアップだけで構成されているページです。このページをレンダリングするために、ブラウザはリクエストを開始し、HTML ドキュメントが届くのを待ち、それを解析し、DOM を構築して、ようやく画面上にレンダリングします。

{# wf_updated_on: 2014-09-11 #}

{# wf_published_on: 2014-03-31 #}

{% include "web/_shared/contributors/ilyagrigorik.html" %}

Chrome DevTools を開き、ページの読み込み時にタイムラインを記録すると、そのステップを実行するために実際にかかった時間を確認できます。上記のサンプルの場合、一連の HTML を DOM ツリーに変換するのに 5 ms 近くかかっています。さらに大きなページの場合は、このプロセスが大幅に長くなる可能性があります。スムーズなアニメーションを作成するとき、ブラウザが大量の HTML を処理しなければならない場合に、この仕組みによって容易にボトルネックが生じるおそれがあります。

ブラウザで、このシンプルなページの DOM を構築している間に、ドキュメントの head セクションで link タグに遭遇しました。このタグは、外部の CSS スタイルシート style.css を参照しています。ブラウザは、ページのレンダリングにはこのリソースが必要であると想定して、このリソースに対するリクエストを即座にディスパッチします。これにより、次のコンテンツが返されます。

また、上記のツリーは、完全な CSSOM ツリーではなく、独自のスタイルシートでオーバーライドすると決めたスタイルだけが表示されています。各ブラウザには、「ユーザー エージェント スタイル」というデフォルトの一連のスタイルが用意されています。独自のスタイルを指定していない場合は、このスタイルで表示されます。スタイルを指定すると、このデフォルト（[デフォルト IE スタイル](http://www.iecss.com/){: .external }など）が単純にオーバーライドされます。

<img src="images/cssom-timeline.png" alt="DevTools での CSSOM 構築のトレース">

<a href="render-tree-construction" class="gc-analytics-event"

data-category="CRP" data-label="Next / Render-Tree Construction">

{# wf_updated_on: 2015-10-05 #}

{# wf_published_on: 2014-03-31 #}

{% include "web/_shared/contributors/ilyagrigorik.html" %}

Lighthouse は、指定したページに対して一連のテストを実行し、ページの結果をレポートにまとめて表示するウェブアプリの監査ツールです。

Lighthouse は Chrome 拡張機能または NPM モジュールとして実行できるため、Lighthouse を継続的インテグレーション システムと統合する場合に便利です。

[crc]: /web/tools/lighthouse/audits/critical-request-chains

Navigation Timing API と、ページの読み込み時に発行されたその他のブラウザ イベントを組み合わせると、任意のページでの実際の CRP パフォーマンスを取得および記録できます。

以上です。これで、トラッキング対象の具体的なマイルストーンと、その測定値を出力するシンプルな関数がそろいました。これらのメトリックをページに出力する代わりに、コードを修正してアナリティクス サーバーに送信することもできます（[Google アナリティクスではこれを自動で実行](https://support.google.com/analytics/answer/1205784)）。これは、ページのパフォーマンスを正しく把握し、最適化作業によってメリットが生じそうなページを特定する方法として優れています。

このようなドキュメントでは、Chrome DevTools の [Network] パネルを使用して、CRP のコンセプトを説明している場合がありますが、DevTools は現在、CRP の測定に最適というわけではありません。クリティカルなリソースを特定する仕組みが組み込まれていないためです。

クリティカルなリソースを特定するには、[Lighthouse](#lighthouse) の監査を実行します。