ウェブパフォーマンスを解き明かす：Performance Observer API 詳細解説

今日のペースの速いデジタルの世界において、ウェブパフォーマンスは贅沢品ではなく、必需品です。ウェブサイトが遅い、または反応しないと、ユーザーの不満、直帰率の上昇、そして売上、広告収入、ユーザーエンゲージメントといったビジネス目標への直接的な悪影響につながります。長年、開発者は通常、最初のページ読み込み時という単一の時点でのパフォーマンスを測定するツールに頼ってきました。これは有用ではあるものの、ユーザーがページと対話する中での全体的な体験という、物語の重要な部分を見逃してしまいます。ここでランタイムのパフォーマンス監視が登場し、その最も強力なツールがPerformance Observer APIです。

従来の方法では、performance.getEntries()のような関数でパフォーマンスデータをポーリングすることがよくありました。これは非効率的で、ポーリングの合間に発生する重要なイベントを見逃しがちであり、測定しようとしているパフォーマンスオーバーヘッド自体を増加させることさえあります。Performance Observer APIは、パフォーマンスイベントが発生したときにそれを購読するための、非同期的で低オーバーヘッドのメカニズムを提供することで、このプロセスに革命をもたらします。このガイドでは、この不可欠なAPIを深く掘り下げ、その力を活用してコアウェブバイタルを監視し、ボトルネックを特定し、最終的には世界中のユーザーのためにより速く、より快適なウェブ体験を構築する方法を示します。

Performance Observer APIとは？

その核心において、Performance Observer APIは、パフォーマンスエントリとして知られるパフォーマンス測定イベントを監視し、収集する方法を提供するインターフェースです。ブラウザ内でのパフォーマンス関連のアクティビティ専用のリスナーと考えてください。あなたが積極的にブラウザに「何か起こりましたか？」と尋ねる代わりに、ブラウザが積極的に「新しいパフォーマンスイベントが発生しました！詳細はこちらです」と教えてくれるのです。

これはオブザーバーパターンによって実現されます。オブザーバーのインスタンスを作成し、どのタイプのパフォーマンスイベントに興味があるか（例：大きなペイント、ユーザー入力、レイアウトシフトなど）を伝え、コールバック関数を提供します。指定されたタイプの新しいイベントがブラウザのパフォーマンスタイムラインに記録されるたびに、あなたのコールバック関数が新しいエントリのリストとともに呼び出されます。この非同期的なプッシュベースのモデルは、performance.getEntries()を繰り返し呼び出す古いプルベースのモデルよりもはるかに効率的で信頼性があります。

古い方法 vs. 新しい方法

Performance Observerの革新性を理解するために、2つのアプローチを対比してみましょう：

• 古い方法（ポーリング）： setTimeoutやrequestAnimationFrameを使用して定期的にperformance.getEntriesByName('my-metric')を呼び出し、メトリックが記録されたかどうかを確認するかもしれません。これは、チェックが遅すぎてイベントを見逃したり、頻繁にチェックしすぎてCPUサイクルを無駄にしたりする可能性があるため、問題があります。また、定期的にエントリをクリアしないと、ブラウザのパフォーマンスバッファを一杯にしてしまうリスクもあります。
• 新しい方法（監視）： PerformanceObserverを一度設定します。それはバックグラウンドで静かに待機し、最小限のリソースを消費します。関連するパフォーマンスエントリが記録されるとすぐに（それがページ読み込み後1ミリ秒であろうと、ユーザーセッション開始後10分であろうと）、あなたのコードは即座に通知されます。これにより、イベントを見逃すことがなくなり、監視コードは可能な限り効率的になります。

なぜPerformance Observerを使うべきなのか

Performance Observer APIを開発ワークフローに統合することは、グローバルな展開を目指す現代のウェブアプリケーションにとって不可欠な多くの利点を提供します。

• 非侵入的なモニタリング： オブザーバーのコールバックは通常、アイドル期間中に実行されるため、パフォーマンス監視コードがユーザーエクスペリエンスを妨げたり、メインスレッドをブロックしたりすることがありません。軽量で、パフォーマンスへの影響が無視できるほど小さくなるように設計されています。
• 包括的なランタイムデータ： ウェブは動的です。パフォーマンスの問題は読み込み時にだけ発生するわけではありません。ユーザーは複雑なアニメーションをトリガーしたり、スクロールしてさらにコンテンツを読み込んだり、最初のページが落ち着いたずっと後で重いコンポーネントと対話したりするかもしれません。Performance Observerはこれらのランタイムイベントをキャプチャし、ユーザーセッション全体の完全な状況を提供します。
• 将来性があり標準化されている： これはW3Cが推奨するパフォーマンスデータ収集の標準です。新しいパフォーマンスメトリックやAPIはこれと統合するように設計されており、プロジェクトにとって持続可能で将来を見据えた選択肢となります。
• リアルユーザーモニタリング（RUM）の基盤： さまざまな国、デバイス、ネットワーク条件のユーザーにとってサイトがどのように動作するかを真に理解するためには、実際のセッションからのデータが必要です。Performance Observerは、堅牢なRUMソリューションを構築するための理想的なツールであり、重要なメトリックを収集し、集計と分析のために分析サービスに送信することができます。
• 競合状態の排除： ポーリングでは、パフォーマンスエントリが記録される前にアクセスしようとすることがあります。オブザーバーモデルは、エントリが利用可能になった後にのみコードが実行されるため、この競合状態を完全に排除します。

はじめに：Performance Observerの基本

APIの使用は簡単です。プロセスには主に3つのステップが含まれます：オブザーバーの作成、コールバックの定義、そしてオブザーバーに何を監視するかを伝えることです。

1. コールバックを持つオブザーバーの作成

まず、PerformanceObserverオブジェクトをインスタンス化し、コールバック関数を渡します。この関数は、新しいエントリが検出されるたびに実行されます。

const observer = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log('エントリータイプ:', entry.entryType); console.log('エントリー名:', entry.name); console.log('開始時間:', entry.startTime); console.log('持続時間:', entry.duration); } });

コールバックはPerformanceObserverEntryListオブジェクトを受け取ります。このリストのgetEntries()メソッドを呼び出すことで、新しく監視されたすべてのパフォーマンスエントリの配列を取得できます。

2. 特定のエントリタイプを監視する

オブザーバーは、何を監視するかを指示されるまで何もしません。これには.observe()メソッドを使用します。このメソッドは、監視したいパフォーマンスエントリタイプを表す文字列の配列であるentryTypesプロパティ（または現代的なケースでは単一タイプの場合type）を持つオブジェクトを受け取ります。

// 2種類のエントリの監視を開始 observer.observe({ entryTypes: ['mark', 'measure'] });

最も一般的なエントリタイプには以下のようなものがあります：

• 'resource': スクリプト、画像、スタイルシートなどのアセットに対するネットワークリクエストの詳細。
• 'paint': first-paintおよびfirst-contentful-paintのタイミング。
• 'largest-contentful-paint': 体感的な読み込み速度に関するコアウェブバイタルのメトリック。
• 'layout-shift': 視覚的な安定性に関するコアウェブバイタルのメトリック。
• 'first-input': First Input Delayというコアウェブバイタルに使用される、最初のユーザーインタラクションに関する情報。
• 'longtask': メインスレッド上で50ミリ秒以上かかるタスクを特定し、応答性の低下を引き起こす可能性があります。
• 'mark' & 'measure': User Timing APIを使用して独自のコードで定義するカスタムマーカーと測定。

3. オブザーバーの停止

データの収集が不要になった場合は、リソースを解放するためにオブザーバーを切断することが良い習慣です。

observer.disconnect();

実践的なユースケース：コアウェブバイタルのモニタリング

コアウェブバイタルは、Googleがウェブページの全体的なユーザーエクスペリエンスにおいて重要と考える特定の要因のセットです。これらを監視することは、Performance Observer APIの最も強力な応用例の一つです。それぞれを測定する方法を見ていきましょう。

Largest Contentful Paint (LCP) のモニタリング

LCPは読み込みパフォーマンスを測定します。これは、ページ読み込みのタイムライン上でメインコンテンツがおそらく読み込まれた時点を示します。良好なLCPスコアは2.5秒以下です。

LCP要素はページの読み込み中に変わることがあります。最初は見出しがLCP要素かもしれませんが、後でより大きな画像が読み込まれて新しいLCP要素になることがあります。これがPerformance Observerが完璧である理由です—レンダリングされるたびに、それぞれの潜在的なLCP候補を通知してくれます。

// LCPを監視し、最終的な値をログに出力する let lcpValue = 0; const lcpObserver = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); // 最後のエントリが最新のLCP候補 const lastEntry = entries[entries.length - 1]; lcpValue = lastEntry.startTime; console.log(`LCPが更新されました: ${lcpValue.toFixed(2)}ms`, lastEntry.element); }); lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true }); // ユーザーがインタラクションを行うと新しいLCP候補のディスパッチが停止することがあるため、 // ユーザーのインタラクション後にオブザーバーを切断するのが良い習慣です。 // window.addEventListener('beforeunload', () => lcpObserver.disconnect());

buffered: trueの使用に注意してください。これは、observe()メソッドが呼び出される*前*に記録されたエントリを含めるようにオブザーバーに指示する重要なオプションです。これにより、初期のLCPイベントを見逃すのを防ぎます。

First Input Delay (FID) と Interaction to Next Paint (INP) のモニタリング

これらのメトリックはインタラクティビティを測定します。ユーザーが最初にページと対話しようとしたときの体験を定量化します。

First Input Delay (FID) は、ユーザーが最初にページと対話した時（例：ボタンをクリック）から、ブラウザが実際にそのインタラクションに応答してイベントハンドラを処理し始めるまでの時間を測定します。良好なFIDは100ミリ秒以下です。

Interaction to Next Paint (INP) は、2024年3月にFIDに代わってコアウェブバイタルとなった、より新しく包括的なメトリックです。FIDが*最初*のインタラクションの*遅延*のみを測定するのに対し、INPはページのライフサイクル全体にわたる*すべて*のユーザーインタラクションの*総レイテンシ*を評価し、最も悪いものを報告します。これにより、全体的な応答性のより良い全体像が得られます。良好なINPは200ミリ秒以下です。

'first-input'エントリタイプを使用してFIDを監視できます：

// FIDを監視する const fidObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { const fid = entry.processingStart - entry.startTime; console.log(`FID: ${fid.toFixed(2)}ms`); // 最初の入力が報告されたら切断する fidObserver.disconnect(); } }); fidObserver.observe({ type: 'first-input', buffered: true });

INPの監視は、イベントの全期間を見るため、少し複雑になります。'event'エントリタイプを監視し、持続時間を計算し、最も長いものを追跡します。

// INP監視の簡略化された例 let worstInp = 0; const inpObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // INPはイベントの持続時間 const inp = entry.duration; // 現在の最悪値よりも長いインタラクションにのみ関心がある if (inp > worstInp) { worstInp = inp; console.log(`新しい最悪のINP: ${worstInp.toFixed(2)}ms`); } } }); inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true }); // durationThresholdは、非常に短く、おそらく重要でないイベントを除外するのに役立ちます。

Cumulative Layout Shift (CLS) のモニタリング

CLSは視覚的な安定性を測定します。ユーザーが予期しないレイアウトのずれ（警告なしにページ上のコンテンツが移動するイライラする体験）をどれくらいの頻度で経験するかを定量化するのに役立ちます。良好なCLSスコアは0.1以下です。

スコアは、個々のすべてのレイアウトシフトスコアの集計です。Performance Observerは、各シフトが発生するたびに報告するため、ここでは不可欠です。

// 合計CLSスコアを監視および計算する let clsScore = 0; const clsObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // ユーザー入力によって引き起こされたシフトはカウントしたくない if (!entry.hadRecentInput) { clsScore += entry.value; console.log(`現在のCLSスコア: ${clsScore.toFixed(4)}`); } } }); clsObserver.observe({ type: 'layout-shift', buffered: true });

hadRecentInputプロパティは重要です。ユーザーのアクション（メニューを展開するボタンをクリックするなど）に応答して発生する正当なレイアウトシフトを除外するのに役立ち、これらはCLSスコアにカウントされるべきではありません。

コアウェブバイタルを超えて：その他の強力なエントリタイプ

コアウェブバイタルは素晴らしい出発点ですが、Performance Observerはさらに多くのことを監視できます。ここでは、他に非常に便利なエントリタイプをいくつか紹介します。

ロングタスクの追跡（`longtask`）

Long Tasks APIは、メインスレッドを50ミリ秒以上占有するタスクを公開します。メインスレッドがビジー状態の間、ページはユーザー入力に応答できないため、これらは問題となり、遅延やフリーズしたような体験につながります。これらのタスクを特定することは、INPを改善するための鍵です。

// ロングタスクを監視する const longTaskObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { console.log(`ロングタスクを検出: ${entry.duration.toFixed(2)}ms`); // 'attribution'プロパティは、ロングタスクの原因を教えてくれることがある console.log('帰属:', entry.attribution); } }); longTaskObserver.observe({ type: 'longtask', buffered: true });

リソースタイミングの分析（`resource`）

アセットがどのように読み込まれているかを理解することは、パフォーマンスチューニングの基本です。'resource'エントリタイプは、DNSルックアップ、TCP接続、コンテンツダウンロード時間など、ページ上のすべてのリソースに関する詳細なネットワークタイミングデータを提供します。

// リソースタイミングを監視する const resourceObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntries()) { // 読み込みの遅い画像を見つける if (entry.initiatorType === 'img' && entry.duration > 500) { console.warn(`読み込みの遅い画像を検出: ${entry.name}`, `所要時間: ${entry.duration.toFixed(2)}ms`); } } }); // このスクリプトが実行される前に読み込まれたアセットをキャッチするために、 // リソースタイミングには'buffered: true'がほぼ常に必要です。 resourceObserver.observe({ type: 'resource', buffered: true });

カスタムパフォーマンスマークの測定（`mark`と`measure`）

時には、アプリケーション固有のロジックのパフォーマンスを測定する必要があります。User Timing APIを使用すると、カスタムのタイムスタンプを作成し、それらの間の持続時間を測定できます。

• performance.mark('start-operation'): 'start-operation'という名前のタイムスタンプを作成します。
• performance.mark('end-operation'): 別のタイムスタンプを作成します。
• performance.measure('my-operation', 'start-operation', 'end-operation'): 2つのマーク間の測定を作成します。

Performance Observerは、これらのカスタムの'mark'および'measure'エントリをリッスンできます。これは、JavaScriptフレームワークでのコンポーネントのレンダリング時間や、重要なAPI呼び出しとその後のデータ処理の持続時間などのタイミングデータを収集するのに最適です。

// アプリケーションコード内: performance.mark('start-data-processing'); // ... 何らかの複雑なデータ処理 ... performance.mark('end-data-processing'); performance.measure('data-processing-duration', 'start-data-processing', 'end-data-processing'); // 監視スクリプト内: const customObserver = new PerformanceObserver((entryList) => { for (const entry of entryList.getEntriesByName('data-processing-duration')) { console.log(`カスタム測定 '${entry.name}': ${entry.duration.toFixed(2)}ms`); } }); customObserver.observe({ entryTypes: ['measure'] });

高度な概念とベストプラクティス

プロフェッショナルな本番環境でPerformance Observer APIを効果的に使用するためには、これらのベストプラクティスを考慮してください。

• 常に`buffered: true`を検討する: 'resource'、'paint'、'largest-contentful-paint'のように、ページ読み込みの早い段階で発生する可能性のあるエントリタイプの場合、bufferedフラグを使用することは、それらを見逃さないために不可欠です。
• ブラウザのサポートを確認する： 現代のブラウザでは広くサポートされていますが、使用する前にその存在を確認することは常に賢明です。また、特定のブラウザでどのエントリタイプがサポートされているかを確認することもできます。
• if ('PerformanceObserver' in window && PerformanceObserver.supportedEntryTypes.includes('longtask')) { // ロングタスクに対してPerformanceObserverを安全に使用できる }
• データを分析サービスに送信する： データをコンソールにログ出力することは開発には最適ですが、実際の監視のためにはこのデータを集計する必要があります。クライアントからこのテレメトリを送信する最良の方法は、navigator.sendBeacon() APIを使用することです。これは、少量のデータをサーバーに送信するために設計された非ブロッキングのメカニズムであり、ページがアンロードされるときでも確実に機能します。
• 関心事ごとにオブザーバーをグループ化する： 複数のエントリタイプに単一のオブザーバーを使用することもできますが、異なる関心事（例：コアウェブバイタル用、リソースタイミング用、カスタムメトリック用）に別々のオブザーバーを作成する方が、コードの可読性と保守性が向上します。
• パフォーマンスオーバーヘッドを理解する： このAPIは非常に低オーバーヘッドになるように設計されています。しかし、重い計算を行う非常に複雑なコールバック関数は、パフォーマンスに影響を与える可能性があります。オブザーバーのコールバックは簡潔で効率的に保ちましょう。重い処理はウェブワーカーに委譲するか、生のデータをバックエンドに送信してそこで処理します。

結論：パフォーマンス第一の文化を築く

Performance Observer APIは単なるツール以上のものであり、ウェブパフォーマンスへのアプローチ方法における根本的な変化です。それは、私たちを反応的で一度きりの測定から、世界中のユーザーの真の動的な体験を反映する、積極的で継続的な監視へと移行させます。コアウェブバイタル、ロングタスク、リソースタイミング、カスタムメトリックを確実に効率的にキャプチャする方法を提供することで、開発者が多数のユーザーに影響を与える前にパフォーマンスのボトルネックを特定し、解決できるようにします。

Performance Observer APIの採用は、あらゆる開発チームにおいてパフォーマンス第一の文化を築くための重要なステップです。重要なものを測定できれば、重要なものを改善できます。今日からこれらのオブザーバーをプロジェクトに統合し始めましょう。世界中のどこにいるユーザーも、より速く、よりスムーズで、より快適な体験に感謝するでしょう。