公開日: 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 結果は次のスクリーンショットのようになります。
この監査結果の詳細については、クリティカル リクエスト チェーンをご覧ください。
Navigation Timing API でコードを計測する
Navigation Timing API と、ページの読み込み時に発行されたその他のブラウザ イベントを組み合わせると、任意のページでの実際の CRP パフォーマンスを取得および記録できます。
上の図の各ラベルは、ブラウザが読み込むすべてのページについてトラックする、詳細なタイムスタンプに相当します。実は、この具体例では、さまざまなタイムスタンプの一部だけを表示しています。ここではネットワーク関連タイムスタンプはすべて省略してあります。ただし、後の演習で扱う予定です。
ところで、これらのタイムスタンプは何を意味しているでしょうか。
domLoading: これは、プロセス全体の始動タイムスタンプであり、ブラウザが最初に受け取った HTML ドキュメントのバイトの解析を開始する時点を示します。domInteractive: ブラウザが HTML の解析をすべて完了し、DOM の構築を完了した時点を示します。domContentLoaded: DOM の準備が整い、JavaScript の実行をブロックするスタイルシートが存在しなくなった時点を示します。つまり、これ以降、レンダリング ツリーの構築を開始できます。- 多くの JavaScript フレームワークでは、このイベントを待ったうえで、それ自体のロジックの実行を開始します。このため、ブラウザでは、
EventStartとEventEndのタイムスタンプをキャプチャすることで、この処理の所要時間をトラッキングできるようにしています。
- 多くの JavaScript フレームワークでは、このイベントを待ったうえで、それ自体のロジックの実行を開始します。このため、ブラウザでは、
domComplete: 名前が示すように、すべての処理が完了し、ページ上にあるすべてのリソース（画像など）のダウンロードが完了したことを示します。つまり、読み込み中のマークの回転が止まった状態です。loadEvent: ページごとの読み込みの最終ステップとして、ブラウザはonloadイベントを発行します。これにより、追加のアプリケーション ロジックがトリガーされることがあります。
HTML 仕様では、イベントを発行するタイミング、満たすべき条件など、すべてのイベントごとに具体的な条件が規定されています。ここでは目的に合わせて、クリティカル レンダリング パスに関係する主なマイルストーンだけに焦点を当てます。
domInteractiveは DOM の準備ができた時点を示します。domContentLoadedは通常、DOM と CSSOM の両方の準備ができた時点を示します。- パーサー ブロック JavaScript が存在しない場合、
DOMContentLoadedはdomInteractiveの直後に発行されます。
- パーサー ブロック JavaScript が存在しない場合、
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 の後で発行）、さまざまなタイムスタンプ間の差を計算しています。
以上です。これで、トラッキング対象の具体的なマイルストーンと、その測定値を出力する基本的な関数がそろいました。これらの指標をページに表示する代わりに、コードを変更してこれらの指標をアナリティクス サーバーに送信することもできます（Google アナリティクスではこの処理が自動的に行われます）。これは、ページのパフォーマンスを常に把握し、最適化の対象となるページを特定するのに役立ちます。
DevTools はどうですか？
このようなドキュメントでは、Chrome DevTools の [Network] パネルを使用して、CRP のコンセプトを説明している場合がありますが、DevTools は現在、CRP の測定に最適というわけではありません。クリティカルなリソースを特定する仕組みが組み込まれていないためです。このようなリソースを特定するには、Lighthouse 監査を実行します。