クリティカル レンダリング パスの測定

Ilya Grigorik

公開日: 2014 年 3 月 31 日

確固としたパフォーマンス戦略の基盤には、常に正確な計測があります。測定できないものは最適化できない。このガイド CRP パフォーマンスを測定するさまざまな方法を解説しています。

  • Lighthouse のアプローチでは、ページに対して一連の自動テストを実行します。 ページの CRP パフォーマンスに関するレポートを生成します。このアプローチを採用すると、ブラウザで読み込んだ特定のページの CRP パフォーマンスの概要をすばやく簡単に把握できるため、テスト、反復、パフォーマンス改善を迅速に行うことができます。
  • Navigation Timing API のアプローチは、実際のユーザー モニタリング（RUM） できます。名前のとおり、これらの指標は実際のユーザーから取得されます。 サイトで発生したユーザーのインタラクションを 正確に把握し さまざまな業界でユーザーが経験した実際の CRP パフォーマンス ネットワーク状態を確認できます。

一般的には、Lighthouse を使用して明らかな CRP を特定することをおすすめします。 を使用してコードをインストルメント化する方法を Navigation Timing API を使用して、実際のアプリのパフォーマンスをモニタリングします。

Lighthouse を使用したページの監査

Lighthouse は、指定したページに対して一連のテストを実行し、ページの結果をレポートにまとめて表示するウェブアプリの監査ツールです。マイページ Lighthouse を Chrome 拡張機能または NPM モジュールとして実行できるため、 Lighthouse を継続的インテグレーション システムと統合する場合に役立ちます。

詳しくは、Lighthouse を使用したウェブアプリの監査をご覧ください。

Lighthouse を Chrome 拡張機能として実行すると、ページの CRP 結果は次のスクリーンショットのようになります。

Lighthouse の CRP 監査

この監査の結果の詳細については、クリティカル リクエスト チェーンをご覧ください。

Navigation Timing API と発生したその他のブラウザ イベントの組み合わせ 実際の CRP を取得して記録できます 表示できるようになります

Navigation Timing

上の図の各ラベルは、ブラウザが読み込むページごとに追跡する高解像度のタイムスタンプに対応しています。実は、この具体例では、さまざまなタイムスタンプの一部だけを表示しています。ここではネットワーク関連タイムスタンプはすべて省略してあります。ただし、後の演習で扱う予定です。

では、これらのタイムスタンプは何を意味するのでしょうか。

  • domLoading: プロセス全体の開始タイムスタンプ。 ブラウザが、最初に受け取った HTML バイトの解析を開始しようとしている ドキュメントをご覧ください。
  • domInteractive: ブラウザが HTML の解析をすべて完了し、DOM の構築を完了した時点を示します。
  • domContentLoaded: 両方の DOM の準備が整い、JavaScript の実行をブロックしているスタイルシートがないことを示します。つまり、（潜在的に）レンダリング ツリーを構築できるようになりました。
    • 多くの JavaScript フレームワークは、このイベントを待機してから独自のロジックの実行を開始します。このため、ブラウザは EventStart と EventEnd のタイムスタンプをキャプチャして、この実行にかかった時間を追跡できるようにしています。
  • domComplete: 名前が示すように、すべての処理が完了し、ページ上にあるすべてのリソース（画像など）のダウンロードが完了したことを示します。つまり、読み込み中のマークの回転が止まった状態です。
  • loadEvent: ページごとの読み込みの最終ステップとして、ブラウザは onload イベントを発行します。これにより、追加のアプリケーション ロジックがトリガーされることがあります。

HTML 仕様では、イベントを発行するタイミング、満たすべき条件など、すべてのイベントごとに具体的な条件が規定されています。ここでは目的に合わせて、クリティカル レンダリング パスに関係する主なマイルストーンだけに焦点を当てます。

  • domInteractive は DOM の準備ができた時点を示します。
  • domContentLoaded は通常、DOM と CSSOM の両方の準備ができた時点を示します。
    • パーサーをブロックする JavaScript がない場合、DOMContentLoaded は domInteractive の直後に呼び出されます。
  • domComplete は、ページとそのすべてのサブリソースの準備ができた時点を示します。
<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <script>
      function measureCRP() {
        var t = window.performance.timing,
          interactive = t.domInteractive - t.domLoading,
          dcl = t.domContentLoadedEventStart - t.domLoading,
          complete = t.domComplete - t.domLoading;
        var stats = document.createElement('p');
        stats.textContent =
          'interactive: ' +
          interactive +
          'ms, ' +
          'dcl: ' +
          dcl +
          'ms, complete: ' +
          complete +
          'ms';
        document.body.appendChild(stats);
      }
    </script>
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

試してみる

前の例は一見すると厄介に思えるかもしれませんが、実際にはかなり簡単です。Navigation Timing API は関連するすべてのタイムスタンプをキャプチャし、コードは onload イベントが発生するのを待機します（onload イベントは domInteractive、domContentLoaded、domComplete の後に起動し、さまざまなタイムスタンプの差を計算します）。

NavTiming デモ

こうして、追跡すべき具体的なマイルストーンと、これらの測定値を出力するための基本関数が用意できました。これらの指標をページに表示する代わりに、コードを変更してこれらの指標をアナリティクス サーバーに送信することもできます（Google アナリティクスではこの処理が自動的に行われます）。これは、ページのパフォーマンスを常に把握し、最適化の対象となるページを特定するのに役立ちます。

DevTools はどうですか？

これらのドキュメントでは、Chrome DevTools の [Network] パネルを使用して CRP のコンセプトを示しているが、DevTools は CRP には適していない 分離するためのメカニズムが組み込まれていないため、 重要なリソースです。このようなリソースを特定するには、Lighthouse 監査を実行します。

フィードバック