IntersectionObserverとResizeObserverの非同期計測モデル

なぜ「イベント」ではなく「Observer」なのか

要素が画面に入ったか、要素の寸法が変わったかを知りたいとき、素朴には scroll / resize イベントを購読し、その中で getBoundingClientRect() を呼んで判定します。しかしこの方式は二重に高コストです。第一に、これらのイベントは同期的に高頻度で発火し、ハンドラがメインスレッドを奪います。第二に、ハンドラ内でジオメトリを読むと、保留中のスタイル変更を確定させるための強制同期レイアウトが走り、書き込みと交互になればレイアウトスラッシングに直結します（この往復構造は リフローとリペイントのコスト で詳述）。

IntersectionObserver と ResizeObserver は、この計測をブラウザ側に寄せて非同期化する設計です。判定はブラウザがレイアウトを確定させた後に1回まとめて行い、結果だけをコールバックで配ります。アプリ側はジオメトリを読みに行かないので、強制同期レイアウトの起点が消えます。

レンダリングループのどこで計測されるか

両Observerの計測は、HTMLの**レンダリング更新（update the rendering）**という一連のステップの一部として、フレームごとに走ります。1フレームの大まかな並びは次の通りです。

1. タスク/マイクロタスクの実行（JS）
2. requestAnimationFrame コールバック
3. スタイル計算 → レイアウト確定
4. ResizeObserver の処理（gather → broadcast）
5. IntersectionObserver の交差判定（描画機会ごと）
6. ペイント → コンポジット

ポイントは、計測がレイアウト確定後に置かれていることです。この時点でブラウザは各要素の最新の矩形を内部に持っているため、Observerは追加のレイアウトを起こさずにサイズや交差を読めます。アプリが getBoundingClientRect() を呼ぶと保留レイアウトを完了させてしまうのに対し、Observerは「すでに確定した値」を参照するだけ、という非対称がコストの差を生みます。各ステップがどのフェーズに属するかは レンダリングパイプライン詳説 と、コールバックの実行順序という観点では イベントループの内部構造 が背景になります。

ResizeObserverのループと深さ（depth）

ResizeObserver 固有の難しさは、コールバック内でサイズを変えられる点にあります。観測中の要素のサイズが変わったからコールバックが呼ばれ、その中でDOMをいじって別の要素（あるいは自分）のサイズを変えると、同じフレーム内で再びレイアウトが必要になり、新しいサイズをまた通知しなければなりません。素朴に作ると無限ループになります。

仕様はこれを深さ（depth）という概念で制御します。1フレーム内で「レイアウト→アクティブな観測を収集→コールバックでブロードキャスト」を繰り返しますが、各反復で通知する対象を、前回より深い位置（DOMツリーで下）にある要素だけに絞ります。これにより、親のサイズ変化が子に波及する一方向の連鎖は同フレーム内で収束し、無限の往復だけが排除されます。

const ro = new ResizeObserver((entries) => {
  for (const entry of entries) {
    // contentBoxSize / borderBoxSize は確定済みの寸法。
    // ここで再度 getBoundingClientRect を呼ぶ必要はない。
    const w = entry.contentBoxSize[0].inlineSize;
    layout(entry.target, w); // ← ここで要素のサイズを変えると再通知が要る
  }
});

それでも収束しない書き方（コールバックのたびに浅い要素のサイズを揺らし続ける等）を作ると、ブラウザは安全のためにそのフレームでの追加処理を打ち切り、コンソールに ResizeObserver loop limit exceeded（または loop completed with undelivered notifications）を出します。これはクラッシュではなくループ抑止が働いた合図で、残りの通知は次のフレームに繰り越されます。

IntersectionObserverの判定モデル

IntersectionObserver は、ターゲット矩形とルート矩形（既定はビューポート、root 指定で任意のスクロールコンテナ）の交差を計算します。判定は描画の機会ごとにバッチで行われ、交差比率が threshold で指定した境界を跨いだときにだけコールバックを積みます。連続スクロール中に毎ピクセル発火するのではなく、しきい値の通過という離散イベントに変換されるのが効率の核です。

エントリは確定済みのジオメトリを持って渡されます。

isIntersecting     : ルートと少しでも交差しているか（boolean）
intersectionRatio  : ターゲット面積に対する交差面積の比（0〜1）
boundingClientRect : ターゲットの矩形
intersectionRect   : 実際に交差している矩形
rootBounds         : ルートの矩形

rootMargin はルート矩形を膨らませ／縮めてから交差を取るための余白で、画像の遅延読み込みで「画面に入る少し手前で読み始める」先読みに使います。intersectionRatio はターゲット面積を分母にした比なので、ターゲットがルートより大きい場合は完全表示でも 1 に達しない、という直感に反する挙動も理解しておく価値があります。

レイアウトスラッシングを避ける実装原則

両Observerを使う最大の動機は、計測フェーズと更新フェーズを物理的に分離できることです。Observerが「レイアウト後に確定値を配る」役を担うので、アプリのコールバックは読み取りをせず書き込みだけに専念できます。これは リフローとリペイントのコスト で述べた read→write 分離を、ブラウザの仕組みで強制した形と言えます。

実務では、IntersectionObserver は遅延読み込み・無限スクロール・表示計測（広告/アナリティクス）・スクロールスパイに、ResizeObserver はコンテナクエリ的な追従・キャンバスやチャートのリサイズ・要素単位のレイアウト調整に使います。いずれも scroll / resize のグローバルイベントを要素単位の宣言的な観測へ置き換えることで、ハンドラの間引き（throttle/debounce）を自前で書く必要をなくします。間引きはタイミングを荒くするだけで強制同期レイアウトの根を断てませんが、Observerは計測のタイミングそのものをレイアウト確定後に移すため、根本から問題を消します。

まとめ