パフォーマンス計測API（PerformanceObserverとTiming）

計測の土台：performance timeline とエントリバッファ

Web のパフォーマンス計測APIは、JavaScript で時間を測る仕組みではなく、ブラウザが描画・ネットワーク・タスク処理の各段で記録した結果を後から読み出す仕組みです。レンダリングエンジンやネットワークスタックが内部で計測した値を、種別ごとに performance entry（PerformanceEntry） としてタイムラインに積み、アプリはそれを読みます。基礎となる描画工程は レンダリングパイプライン詳説 を参照してください。

各エントリは共通の4フィールドを持ちます。

name      : エントリを識別する文字列（URL や "first-contentful-paint" など）
entryType : 種別（"navigation" / "resource" / "paint" / "longtask" ...）
startTime : 開始時刻（time origin からの相対ミリ秒）
duration  : 継続時間（ミリ秒。瞬間イベントは 0）

時刻はすべて DOMHighResTimeStamp、すなわち performance.timeOrigin（ナビゲーション開始の時点）を 0 とした**単調増加のミリ秒（小数つき）**です。Date.now() のようなシステム時計ではないため、NTP補正や時刻変更の影響を受けず、区間の引き算が安定します。

PerformanceObserver とバッファの取りこぼし問題

エントリを読む経路は2つあります。performance.getEntriesByType() で今ある分を一括取得する方法と、PerformanceObserver で今後積まれる分を購読する方法です。実務で重要なのは、多くの計測対象がスクリプト実行より前に確定している点です。Navigation や First Paint は、計測コードが走り始める前にすでに記録済みのことが多く、素朴に Observer を張るだけでは取りこぼします。

これを解決するのが buffered: true です。

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.entryType ごとに処理
  }
}).observe({ type: "largest-contentful-paint", buffered: true });

buffered: true を付けると、observe を呼ぶ前にバッファへ積まれていた過去エントリも、最初のコールバックでまとめて配られます。これにより「計測コードを後から読み込んでも過去のイベントを拾える」設計になります。

observe() の指定方法には2系統あり、{ type: "..." , buffered: ... }（単一種別・buffered指定可）と { entryTypes: ["...", "..."] }（複数種別・buffered不可）が排他です。複数種別を一度に見つつ過去分も欲しいときは、type 指定の observe を種別ごとに複数回呼ぶのが正攻法です。

主要なエントリ型と計測モデル

エントリは entryType で分かれ、それぞれ専用のインターフェース（フィールド集合）を持ちます。

Navigation Timing

PerformanceNavigationTiming は、メインドキュメントの取得から load までを1本のタイムライン上の時刻列として持ちます。Resource Timing を継承しているため、リダイレクト・DNS・接続・TTFB の各時刻に加えて、domInteractive / domContentLoadedEventStart / loadEventEnd といったドキュメント固有のマイルストーンを含みます。すべて time origin 相対なので、responseStart - requestStart のように段を引き算して各フェーズの所要時間を出します。

const nav = performance.getEntriesByType("navigation")[0];
const ttfb = nav.responseStart;          // 受信開始（=TTFB相当）
const dcl  = nav.domContentLoadedEventEnd;
const load = nav.loadEventEnd;

Resource Timing

PerformanceResourceTiming は、画像・スクリプト・フェッチなどサブリソース1件ごとのフェーズ別時刻です。同じ段（redirect→DNS→TCP→TLS→request→response）を持ち、ここから接続再利用やキャッシュヒットの有無を読みます。ネットワーク取得そのものの仕組みは Fetch API の内部動作 を参照してください。

Paint / Element Timing

paint 種別は FP（first-paint） と FCP（first-contentful-paint） の2エントリを提供し、startTime がそれぞれの描画時刻です。一方 element 種別（Element Timing）は、自分で計測したい要素を elementtiming 属性で明示指定して初めて記録されます。ヒーロー画像や主要見出しの描画時刻を、LCP とは独立に取りたいときに使います。

<img src="hero.webp" elementtiming="hero-image" />

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    // e.identifier === "hero-image", e.renderTime が描画時刻
  }
}).observe({ type: "element", buffered: true });

Long Tasks

longtask は、メインスレッドを 50ms 以上連続で占有したタスクを1件ずつ記録します。50ms という閾値は、その間ユーザー入力に応答できない＝知覚可能な詰まり、という基準です。startTime と duration で「いつ・どれだけ詰まったか」を、attribution でおおまかな原因コンテキストを得ます。応答性（INP）が悪化する根本は多くがこの長タスクで、背景の実行モデルは イベントループの内部構造 が土台になります。

フィールド計測の設計

ラボ計測（Lighthouse 等）は端末・回線・操作を固定した再現環境で測りますが、フィールド計測（RUM）は実利用者の多様な条件下の値を集めます。同じ計測アルゴリズムでも入力が違うため値はばらつき、平均ではなくパーセンタイルで評価するのが原則です。

設計の核は「いつ集計し、いつ送るか」です。LCP や CLS や INP はページ滞在の最後まで確定しないため、各操作のたびに送ると最終値が取れません。定石は、Observer で値を更新し続け、ページがバックグラウンド化または破棄される瞬間に一度だけ送ることです。

let lcp = 0;
new PerformanceObserver((list) => {
  for (const e of list.getEntries()) lcp = e.startTime; // 最後の候補で上書き
}).observe({ type: "largest-contentful-paint", buffered: true });

addEventListener("pagehide", () => {
  navigator.sendBeacon("/rum", JSON.stringify({ lcp }));
}, { once: true });

送信トリガは unload ではなく pagehide または visibilitychange（hidden化）が推奨です。unload は BFCache を無効化するうえ、モバイルでは発火が保証されないためです。

まとめ