イベントループ実行モデルの状態遷移図

イベントループとは「1個ずつ回す」仕組み

JavaScript はブラウザのメインスレッドで動くシングルスレッドの言語です。にもかかわらず、クリック処理・タイマー・通信完了・アニメーションを同時にこなせるのは、イベントループがそれらを1個ずつ順番に取り出して回しているからです。

重要なのは、この回し方が HTML 仕様の Event loop processing model として厳密に決まっていることです。「なんとなく非同期」ではなく、毎ティック同じ順序で状態が遷移する。その順序を頭に入れると、Promise.then が setTimeout より先に走る理由も、requestAnimationFrame でアニメーションする理由も、すべて同じ1枚の図から説明できます。

キューは2種類ある：タスクとマイクロタスク

まず押さえるべきは、待ち行列が2種類あることです。両者は優先度も消化のされ方も違います。

ここで「タスクは1ティックに1個、マイクロタスクは空になるまで全部」という非対称が、後述の挙動すべての源になります。

1ティックの状態遷移

1回のループ（1ティック）は、おおむね次の順で状態が移ります。上から下へ一方向に進み、最後はまたタスクの取り出しへ戻る、という閉じたループです。

[1] タスクを1個取り出して実行
        ↓
[2] マイクロタスクを“空になるまで”全消化  ← await/then はここで連鎖
        ↓
[3] このティックで描画する？  ──いいえ──→ [1] へ戻る
        ↓ はい（描画タイミングが来た）
[4] requestAnimationFrame コールバック実行
        ↓
[5] スタイル計算 → レイアウト → ペイント
        ↓
[6] 余裕があれば requestIdleCallback 実行
        ↓
      [1] へ戻る

ポイントは2つです。第一に、[2] のマイクロタスク消化は途中で止まらない。消化中に新しいマイクロタスクが積まれたら、それも同じ [2] の中で消化します。第二に、描画（[3]〜[5]）は毎ティック起きるとは限らない。ディスプレイのリフレッシュ（多くは約16.7ms間隔）に合わせて「描画する番のティック」でだけ走ります。タイマーが連射されても、描画は間引かれるわけです。

なぜ Promise は setTimeout より先なのか

この順序が分かると、定番のクイズが機械的に解けます。

console.log('A: 同期');

setTimeout(() => console.log('D: タイマー(タスク)'), 0);

Promise.resolve().then(() => console.log('C: マイクロタスク'));

console.log('B: 同期');

出力は A → B → C → D です。理由はこうです。まず同期コード（現在のタスク本体）が走り A、B を出します。setTimeout はタスクキューへ、then はマイクロタスクキューへ積まれるだけ。同期コードが終わってタスクが空になると [2] に入り、マイクロタスクを全消化して C。setTimeout のコールバックは次のティックの [1] でようやく取り出され D。つまり「setTimeout(0) は0msではなく“最低でも次ティック以降”」が正確な理解です。

描画フェーズ：rAF →スタイル/レイアウト/ペイント

描画する番のティックでは、まず requestAnimationFrame（rAF） のコールバックがスタイル計算より前に呼ばれます。ここが rAF の存在意義です。「次のフレームを描く直前」に DOM をいじれるので、変更がそのフレームに確実に反映され、かつ1フレームに1回へ自然に間引かれます。

その直後に スタイル計算 → レイアウト → ペイント → 合成 が走ります（この後半パイプラインの詳細は ブラウザのレンダリングの仕組み を参照）。順序が「rAF が先、レイアウトが後」である点が実務上きわめて重要です。

// ❌ 読み→書き→読み… が交互。rAF内でレイアウトを何度も強制
function bad() {
  for (const el of items) {
    const w = el.offsetWidth;          // 読む（レイアウトを強制）
    el.style.width = w + 10 + 'px';    // 書く（次の読みでまた強制）
  }
  requestAnimationFrame(bad);
}

// ✅ 先に全部読む → 後で全部書く
function good() {
  const ws = items.map(el => el.offsetWidth); // 読みをまとめる
  items.forEach((el, i) => {                  // 書きをまとめる
    el.style.width = ws[i] + 10 + 'px';
  });
  requestAnimationFrame(good);
}

アイドルフェーズ：requestIdleCallback

描画まで終えて、次のフレームまでにまだ時間が余っているとき、ブラウザは requestIdleCallback に登録されたコールバックを呼びます。引数で渡される deadline.timeRemaining() は「あと何ミリ秒の余裕があるか」で、これを見ながら重くない仕事を少しずつこなすのが正しい使い方です。

向くのは「急がないが、いつかやりたい」処理です。ログのバッチ送信、プリフェッチ、アナリティクスの集計など。逆にDOM の更新や入力応答をここに置くのは禁物で、余裕がなければ何分も呼ばれないことがあります。締め切りを保証したいなら timeout オプションを付けます。

マイクロタスクはどこで消化されるか

「マイクロタスクはタスクの直後」と書きましたが、より正確にはコールスタックが空になった各チェックポイントで消化されます。タスク本体の終了時はもちろん、[4] の各 rAF コールバックの後など、仕様が定める区切りごとに「マイクロタスクが残っていれば全消化」が挟まります。だから await の続きは、わざわざ次のタスクを待たず、できるだけ早い区切りで再開されます。

まとめ