イベントループの内部構造（タスクキューとマイクロタスク）

1つのスレッドで、すべてをさばく

JavaScript の実行モデルは シングルスレッドです。1つのコールスタックしか持たず、ある関数が動いている間、他のコードは割り込めません。それでもクリック・タイマー・通信・アニメーションを同時にさばけるのは、ブラウザが イベントループ（event loop） という調停役を回しているからです。

イベントループの仕事は単純で、「実行すべき仕事（タスク）を、決まった順序で1つずつコールスタックに載せる」だけです。ポイントは、この順序が WHATWG HTML 仕様で厳密に決められたアルゴリズムであること。setTimeout と Promise.then のどちらが先に走るかは、気分や運ではなく、仕様で一意に決まります。本記事はその順序を内部レベルで解きほぐします。基礎は JavaScript を前提にします。

2種類のキュー：タスクとマイクロタスク

イベントループが参照するキューは大きく2系統あります。この区別がすべての出発点です。

• タスクキュー（マクロタスク / task）：1反復で最大1個だけ取り出して実行する。setTimeout/setInterval のコールバック、DOM イベント（click 等）、fetch 完了の通知、<script> の実行などが入る。
• マイクロタスクキュー（microtask）：タスクを1個実行し終えた直後に、空になるまで全部を連続実行する。Promise の then/catch/finally、queueMicrotask()、MutationObserver のコールバックが入る。

イベントループの1反復（アルゴリズムの骨子）

仕様のイベントループ処理を、要点だけ疑似コードにすると次のようになります。地の文では集合記法を {task, microtask} のようにインラインコードで書きます（裸の波括弧は MDX が壊すため）。

loop:
  // 1) タスクを1つ取り出して実行（なければスキップ）
  task = タスクキューから1個取り出す
  if task: run(task)              // ここで同期的にスタックが空になるまで実行

  // 2) マイクロタスクを“空になるまで”全消化
  while マイクロタスクキューが空でない:
    m = 取り出す
    run(m)                        // 実行中に追加された分も同じループで消化される

  // 3) 必要ならレンダリング機会（描画する反復のみ）
  if 描画するタイミング:
    run requestAnimationFrame コールバック群
    スタイル計算 → レイアウト → ペイント

  goto loop

ここから導かれる鉄則は2つです。第一に、1反復でマクロタスクは1個、マイクロタスクは全部。第二に、マイクロタスクが残っている限り、次のマクロタスクにもレンダリングにも進まない。この非対称性が、実務で観測される順序のほぼすべてを説明します。

なぜ Promise は setTimeout より先に走るのか

この有名な挙動は、上のアルゴリズムからそのまま導けます。

console.log('A');                       // 同期
setTimeout(() => console.log('B'), 0);  // タスクキューへ
Promise.resolve().then(() => console.log('C')); // マイクロタスクキューへ
console.log('D');                       // 同期
// 出力順: A → D → C → B

順を追うと、まず現在のタスク（このスクリプト全体）が同期的に走り、A・D が出ます。この時点で B はタスクキュー、C はマイクロタスクキューに積まれています。スクリプトというタスクが終わった直後、ステップ2でマイクロタスクが全消化されるので C が先に出ます。B（次のタスク）はその後の反復まで待たされる――だから setTimeout(…, 0) でも Promise には勝てません。

requestAnimationFrame のタイミング

requestAnimationFrame（rAF）は、マクロタスクでもマイクロタスクでもありません。イベントループのステップ3（レンダリング機会）の冒頭、スタイル計算・レイアウト・ペイントの直前に呼ばれる、描画専用のコールバック群です。

• 画面更新の直前に1回だけ呼ばれるので、ここで DOM を変更すれば、その変更が同じフレームのペイントに間に合う。
• 呼び出し頻度はディスプレイのリフレッシュレートに同期する（多くは毎秒60回）。タブが非アクティブだと呼ばれないため、無駄な描画やバッテリ消費を避けられる。

// ❌ setTimeout でアニメーション：描画周期とズレてカクつく／裏タブでも回る
setTimeout(function loop() { move(); setTimeout(loop, 16); }, 16);

// ✅ rAF：ペイント直前に呼ばれ、リフレッシュレートに同期する
requestAnimationFrame(function loop() { move(); requestAnimationFrame(loop); });

setTimeout のタイマーは「最低でもこの時間後」を保証するだけで、描画周期とは無関係です。だからフレームと位相がずれてカクつきます。アニメーションや「DOM 変更を次の描画に確実に反映させたい」用途では rAF が正解です。レンダリング工程そのものは ブラウザのレンダリングの仕組み を参照してください。

全部を1つの時系列に並べる

ここまでの要素を、ボタンクリックを起点に1反復へ落とし込むと、優先順位がはっきりします。

button.addEventListener('click', () => {
  console.log('1: ハンドラ（タスク）');
  setTimeout(() => console.log('5: 次のタスク'), 0);
  requestAnimationFrame(() => console.log('4: 描画直前 rAF'));
  Promise.resolve().then(() => console.log('3: マイクロタスク'));
  console.log('2: ハンドラ内の同期コード末尾');
});
// クリック時の出力: 1 → 2 → 3 → 4 → 5

同期コード（1・2）がハンドラというタスク内で完走し、続いてマイクロタスク（3）、レンダリング機会の rAF（4）、そして次の反復でようやく別タスク（5）――この並びは仕様どおりで、ブラウザ間でぶれません。

Node.js との違い（混同しないために）

ブラウザと Node.js はどちらもイベントループを持ちますが、実装が別です。Node は libuv 由来の複数フェーズ（timers / pending / poll / check / close）を持ち、setImmediate（check フェーズ）や process.nextTick（マイクロタスクよりさらに優先される独自キュー）があります。ブラウザには setImmediate も process.nextTick も標準では存在しません。本記事のアルゴリズムは**ブラウザ（WHATWG HTML 仕様）**のものとして読んでください。共通するのは「同期 → マイクロタスク → 次のタスク」という大枠だけで、細部は環境依存です。

まとめ