HTMLツール

無料 PerformanceObserverスニペットジェネレーター

good/needs-improvement/poor閾値付きでCore Web Vitals(LCP、INP、CLS)のPerformanceObserverコードを生成します。

ツールを読み込み中...

PerformanceObserverスニペットジェネレーターとは

PerformanceObserverは、開発者がパフォーマンス測定イベントをリアルタイムで監視できるブラウザAPIです。パフォーマンスタイムラインをポーリングしたり手動のタイミング測定に依存したりする代わりに、PerformanceObserverは特定のエントリタイプ(largest-contentful-paint、layout-shift、first-input、paint、navigationなど)をサブスクライブし、記録された時点でエントリを受信します。これはWebパフォーマンスワーキンググループがCore Web Vitalsの測定に推奨する標準的なアプローチです。このAPIはバッファリングフラグをサポートしており、登録時に履歴エントリを即座に返すため、オブザーバーがセットアップされる前に発火したメトリクスを見逃しません。Baseline 2025、Chrome 73+、Edge 73+、Safari 14.1+、Firefox 84+でサポートされています。

クイックアンサー

PerformanceObserverは、効率的なオブザーバーパターンとバッファリングされたエントリサポートを通じて、リアルタイムのCore Web Vitals監視(LCP、INP、CLS、FID、FCP、TTFB)を提供します。Googleの良好/改善必要/不良のしきい値に対して各メトリクスを分類し、必要に応じてnavigator.sendBeaconを介して信頼性の高いアナリティクス配信のためにレポートします。Baseline 2025(Chrome 73+、Safari 14.1+、Firefox 84+)。ポーリングよりも効率的で、本番環境でのWeb Vitals測定に推奨されるアプローチです。

Last updated: 2026-06-02

制限事項

  • PerformanceObserverのエントリはページ遷移間で保持されません。各ページ読み込みは新しいタイムラインで始まります。SPAのルート変更では、新しいルートでのメトリクス追跡を継続するためにオブザーバーを手動で再接続する必要があります。
  • 一部のパフォーマンスエントリタイプはブラウザ固有の可用性や動作があります。たとえば、layout-shiftエントリはすべてのブラウザで利用できるわけではなく(Firefoxはバージョン134でサポートを追加)、INPの監視にはChrome 121+またはSafari 18+が必要です。オブザーバーを登録する前に必ずサポートを確認してください。
  • PerformanceObserverにはエントリタイプごとに限られたバッファがあります。オブザーバーが登録される前にバッファがいっぱいになり、buffered: trueが設定されていない場合、古いエントリが破棄される可能性があります。ページ読み込みライフサイクルの早い段階でオブザーバーを登録し、buffered: trueを使用してクリティカルレンダリングパス中に発火したエントリをキャプチャしてください。

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

使い方

  1. 監視するパフォーマンスメトリクスを選択します。Core Web Vitals(LCP、INP、CLS、FID、FCP、TTFB)または個別のエントリタイプ(paint、layout-shift、largest-contentful-paint、first-input、navigationなど)。
  2. しきい値分類を設定します。各メトリクスはGoogle Web Vitalsのしきい値に基づいて自動的に良好、改善必要、不良に分類されます。特定の要件に合わせてしきい値をオプションでカスタマイズできます。
  3. レポート方法を選択します。結果をコンソールにログ、analyticsエンドポイントにnavigator.sendBeaconでデータを送信、または既存の監視と統合するためのカスタムコールバック関数を提供。
  4. 生成されたJavaScriptスニペットをコピーします。出力には、複数のオブザーバー、バッファリングされたエントリサポート、しきい値分類、オプションのsendBeaconレポーティングを備えた完全なPerformanceObserverセットアップが含まれます。

主な用途

  • 本番環境でCore Web Vitalsを追跡し、信頼性が高くノンブロッキングなデータ送信のためにsendBeaconを使用してanalyticsエンドポイントにレポートします。ページのアンロード時でも機能します。
  • 開発中にLCPをリアルタイムで監視し、パフォーマンス最適化(画像圧縮、フォント読み込み、遅延読み込み)が実際にLCP時間を削減していることを確認します。
  • 各レイアウトシフトエントリをシフトスコアと影響を受けたノードとともにログ記録することで、ライブサイトで予期しないレイアウトシフト(CLS)を検出し、累積レイアウトシフトの原因を特定します。

用途

使用例

sendBeaconを使用した本番Core Web Vitals監視

eコマースサイトが製品ページに生成されたPerformanceObserverスニペットをデプロイします。オブザーバーはLCP、INP、CLS、FCP、TTFBを追跡します。各メトリクスはGoogleのしきい値に対して分類されます。良好なLCPは2500ms未満、改善必要は2500〜4000ms、不良は4000ms超。メトリクスは30秒ごとにnavigator.sendBeaconを介して/analytics/cwvに送信されます。チームは任意のページが10%を超える不良LCPまたは0.25を超える不良CLSを示したときにダッシュボードアラートを設定します。

詳細ログを使用した開発LCPデバッグ

画像最適化に取り組んでいる開発者が、largest-contentful-paintエントリ用のPerformanceObserverをコンソールログ付きで追加します。各LCPエントリは要素タグ、画像のURL、レンダリング時間、サイズを表示します。次世代フォーマットに切り替え、ヒーロー画像にfetchpriority=highを追加する前後のLCPエントリを比較することで、開発者はLCP時間の40%削減を確認します。

よくあるミス

  • バッファリングフラグなしでページ読み込み後にPerformanceObserverを登録する。FCPやTTFBなどのメトリクスは、ほとんどのJavaScriptが実行される前に発火します。オブザーバーオプションで常にbuffered: trueを設定して、オブザーバーが登録される前に記録された履歴エントリを受信してください。
  • hadRecentInputを確認せずにlayout-shiftエントリを監視する。多くのレイアウトシフトはユーザー操作(入力、クリック、リサイズ)中に発生し、CLSにカウントされるべきではありません。hadRecentInputがtrueのエントリをフィルタリングして、GoogleのCLS定義に一致させてください。
  • ページアンロード時にsendBeaconを使用せずにパフォーマンスデータを同期的に送信する。アンロード中の通常のfetchやXHRリクエストはブラウザによってキャンセルされる可能性があります。navigator.sendBeaconはブラウザのバックグラウンド処理キューを使用して配信を保証します。

検証

  1. 十分なコンテンツがあるページでChrome DevToolsを開き、生成されたHTMLを実行します。コンソールを開き、PerformanceObserverが登録された各メトリクスをその値、分類(良好/改善必要/不良)、エントリタイプとともにログすることを確認します。スクロールダウンしてページとインタラクションし、INPとCLSのエントリがユーザー操作後に表示されることを確認します。
  2. sendBeaconレポーティングを使用するようにオブザーバーを設定し、有効なエンドポイントURLを提供します。ページを読み込み、DevToolsのNetworkタブでパフォーマンスデータを含むビーコンリクエストを確認します。ペイロードにメトリクス名、値、しきい値分類、タイムスタンプが含まれていることを確認します。

FAQ

PerformanceObserverスニペットジェネレーターのFAQ

PerformanceObserverはCore Web Vitals以外にどのようなパフォーマンスメトリクスを監視できますか?

PerformanceObserverは、mark、measure、resource、navigation、paint、largest-contentful-paint、first-input、layout-shift、longtask、element、visibility-state、INP用のeventなど、15以上のエントリタイプをサポートしています。生成されたスニペットはCore Web Vitalsに焦点を当てていますが、監視するエントリタイプリストに適切なタイプ文字列を追加することで、サポートされている任意のエントリタイプを監視するように拡張できます。

PerformanceObserverは同じメトリクスタイプの複数のオブザーバーをどのように処理しますか?

複数のPerformanceObserverインスタンスが同じエントリタイプを同時に監視できます。各オブザーバーは独立してエントリのコピーを受信します。これは関心の分離に便利です。たとえば、1つのオブザーバーはデータをanalyticsに送信し、別のオブザーバーは詳細なデバッグ情報をコンソールにログします。各オブザーバーは不要になったらobserver.disconnect()で個別に切断する必要があります。

PerformanceObserverのエントリはSPAのページ遷移間で保持されますか?

いいえ。PerformanceObserverのエントリはナビゲーションごとに収集され、ページから移動するとクリアされます。クライアントサイドルーティングを使用するシングルページアプリケーションでは、ルート変更ごとにオブザーバーを再接続する必要があります。生成されたスニペットには、ルート変更イベントですべてのオブザーバーを再接続するヘルパー関数が含まれています。異なるオリジン間のナビゲーションでは、前のページのパフォーマンスエントリにはアクセスできません。

生成されたコードで使用される良好/改善必要/不良のしきい値は何ですか?

しきい値はGoogle Web Vitalsガイドラインに従います。LCPは2500ms未満が良好、2500〜4000msが改善必要、4000ms超が不良。FIDは100ms未満が良好、100〜300msが改善必要、300ms超が不良。CLSは0.1未満が良好、0.1〜0.25が改善必要、0.25超が不良。INPは200ms未満が良好、200〜500msが改善必要、500ms超が不良。FCPはLCPのしきい値(2500ms/4000ms)に従います。TTFBは800ms未満が良好、800〜1800msが改善必要、1800ms超が不良。すべてのしきい値は生成されたスニペットで設定可能です。

関連ツール

その他のhtmlツール

こちらもお試しください

こちらもお試しください