requestAnimationFrameとブラウザの描画リズム同期

rAFは「描画の直前」に呼ばれる

requestAnimationFrame（以下 rAF）は、登録したコールバックを次のフレームを描く直前に1回だけ呼んでもらうAPIです。重要なのは呼ばれるタイミングで、これはイベントループのアルゴリズムに組み込まれています。1反復ごとにブラウザは「マクロタスクを1個実行 → マイクロタスクを空になるまで全消化 → 必要ならレンダリング」を回しますが、rAFのコールバックはこの最後のレンダリング段の入口、すなわちスタイル計算・レイアウト・ペイントの直前でまとめて実行されます。順序の土台は イベントループの内部構造 を前提にします。

この配置には明確な意味があります。コールバックがDOMやスタイルを書き換えても、その結果は同じフレームのレンダリング段でそのまま画面へ反映されるため、書き換えと描画が1フレーム内で完結します。setTimeout(fn, 16) のように描画と無関係なタイマーで動かすと、書き換えとフレーム生成の位相がずれ、1フレームに2回走って無駄になったり、逆に間に合わず飛んだりします。

vsyncとフレーム間隔の同期

画面は一定周期で書き換えられます。ディスプレイが内部バッファを走査して表示を更新し終える区切りが垂直同期（vsync）で、リフレッシュレートが60Hzなら約16.7ms（1000 / 60）ごと、120Hzなら約8.3msごとに訪れます。ブラウザのフレーム生成はこのvsyncに合わせて駆動され、rAFのコールバックは各フレームの先頭付近で呼ばれます。

なぜvsyncに揃えるかというと、表示更新の区切りと無関係なタイミングで描き換えても、その更新は次の走査まで画面に出ず、間隔より細かく描いても見えないからです。vsyncより速く描けば無駄、遅ければ取りこぼし。だから「画面が更新できる瞬間に1回だけ、最新状態を用意する」のが合理的で、rAFはそのための入口になっています。

リフレッシュレートは端末で異なるため、rAFの呼び出し間隔も一定ではありません。60Hzで約16.7ms、120Hzで約8.3ms、可変リフレッシュレート（VRR）ならさらに揺れます。間隔を16.7ms固定だと決め打ちしてはいけない理由がここにあり、後述の時間ベース設計が必須になります。

長タスクによるフレーム落ち（ジャンク）

rAFが規則正しく呼ばれる前提は、メインスレッドが空いていることです。スタイル計算・レイアウト・ペイント・JS実行はすべて同じメインスレッド上で直列に走るため、1つの長タスクがスレッドを占有すると、その間はrAFも回りません。

フレームの予算は単純です。60Hzなら1フレームあたり約16.7ms。この中でJS実行・スタイル・レイアウト・ペイントを終えてフレームを提出できなければ、そのvsyncに間に合わず、画面は前のフレームのまま据え置かれます。これが**フレーム落ち（dropped frame）／ジャンク（jank）**です。

理想（60Hz, 予算16.7ms）:
 |--rAF--style--layout--paint--| 提出 |--rAF--...--| 提出 |--...
   ↑各フレームでrAFが呼ばれ、予算内に提出 → 滑らか

長タスクで詰まる:
 |======= 50ms の同期処理（巨大ループ等）=======| ...rAF...
   ↑この間vsyncを2〜3回跨いでもrAFは呼ばれず、画面は据え置き → カクつき

// 悪い：rAF内で重い同期処理。フレーム予算を食い潰しジャンクの原因になる
function frame() {
  heavyLayoutThrash();      // 同期で数十ms。ここでフレームを落とす
  requestAnimationFrame(frame);
}

// 良い：重い計算はrAFの外（アイドル時やWorker）へ逃がし、rAF内は描画更新だけ
function frame(now) {
  applyPrecomputedState(now);  // 軽い反映のみ
  requestAnimationFrame(frame);
}

メインスレッドを長く占有するタスクは、ユーザー操作への反応性（INP）も悪化させます。フレーム落ちと入力遅延は同じ「メインスレッドの混雑」という根を持つため、計測の観点は Core Web Vitalsの計測アルゴリズム と合わせて捉えると一貫します。

時間ベース設計でフレーム落ちに耐える

フレーム間隔が一定でない以上、「1フレームごとに +1px 動かす」ようなフレーム数ベースの更新は破綻します。120Hzでは60Hzの倍速になり、フレームが落ちれば見かけが遅くなる。正しくは経過時間ベースで位置を決めます。

rAFのコールバックは引数として高精度のタイムスタンプ（DOMHighResTimeStamp、ミリ秒・小数あり、performance.now() と同じ時間基準）を受け取ります。これを使い、前フレームからの経過時間 dt を出して「速度 × 経過時間」で進めれば、フレーム間隔や落ちに依存せず見かけの速度を一定に保てます。

let prev = null;
const SPEED = 0.2; // px / ms（= 200px/秒）

function frame(now) {
  if (prev !== null) {
    const dt = now - prev;          // 前フレームからの実経過時間(ms)
    x += SPEED * dt;                // フレーム間隔に依存せず一定速度
  }
  prev = now;
  el.style.transform = `translateX(${x}px)`;
  requestAnimationFrame(frame);
}
requestAnimationFrame(frame);

この設計なら、60Hzでも120Hzでも、途中で1〜2フレーム落ちても、同じ時間で同じ距離進みます。落ちたフレームの分だけ次の dt が大きくなり、位置が一段とびに進むためです。フレーム数で数える実装だと、落ちた分は単純に遅れてしまいます。

CSSの transition / animation を使えば、これらの時間管理とコンポジタ最適化はブラウザが自動で行います。JS制御が必要な場合（物理・ゲーム・スクロール連動など）にrAFを使い、上記の時間ベース設計を徹底するのが原則です。合成の最適化は ブラウザのレイヤー化とGPUコンポジット を併読してください。

まとめ