パッシブ/アクティブイベントとスクロール性能の関係

スクロールがリスナを待つという問題

指でスクロールを始めた瞬間、ブラウザは画面を動かしたい。ところがページに touchstart や wheel のリスナが登録されていると、ブラウザはすぐには動かせません。理由は単純で、そのリスナが preventDefault() を呼んでスクロールを取り消すかもしれないからです。preventDefault() を呼ぶか呼ばないかは、リスナのコードを最後まで実行してみないと分かりません。

その結果、既定（passive を指定しない、いわゆるアクティブリスナ）の挙動はこうなります。

1. ユーザーが指を動かす / ホイールを回す
2. ブラウザは touchmove / wheel リスナをメインスレッドで実行
3. リスナが終わるまで待つ（preventDefault されるか不明なため）
4. preventDefault されなかったと確認 → ようやくスクロール開始

問題は手順3です。リスナの実行はメインスレッドで行われ、そこにレイアウトや他のJSが詰まっていれば、スクロールの開始がそのぶん遅れる。指は動いているのに画面が付いてこない、という典型的なジャンクの正体がこれです。スクロール自体は本来コンポジタスレッドで進められるのに、preventDefault() の可能性を確かめるためだけにメインスレッドの完了を待たされているわけです。

passive がリスナとスクロールを切り離す

addEventListener の第3引数オプション {passive: true} は、ブラウザへの**「このリスナは preventDefault() を呼びません」という約束**です。約束が立つと、ブラウザはリスナの完了を待つ必要がなくなります。

// passive:true — preventDefault しないと宣言。スクロールはブロックされない
window.addEventListener('touchmove', onTouchMove, { passive: true });

// passive:false（アクティブ）— preventDefault する可能性を残す。スクロールが待たされる
window.addEventListener('touchmove', onTouchMove, { passive: false });

passive 指定があると、ブラウザはリスナをメインスレッドで走らせつつ、スクロールはコンポジタスレッドで並行して進められます。スクロールの合成自体がメインスレッドから独立して動く仕組みは レイヤー化とGPUコンポジット と同根で、passive はその独立性をスクロール開始判定にまで広げる宣言だと捉えると分かりやすいでしょう。

決定的なのは、passive がスクロールの開始タイミングを変える点です。リスナの中身を軽くする最適化（処理の間引き等）はメインスレッドの仕事を減らしますが、それでも「リスナ完了を待つ」構造自体は消えません。passive はその待ち合わせ構造ごと取り払うため、効き方が質的に違います。

passive で preventDefault が効かない理由

passive リスナの中で preventDefault() を呼ぶと、その呼び出しは黙殺され、ブラウザはコンソールに「Unable to preventDefault inside passive event listener」といった警告を出します。スクロールは止まりません。

これは矛盾ではなく、約束の整合性を保つための必然です。ブラウザは passive 宣言を信じて、リスナの完了を待たずにスクロールをもう始めてしまっているかもしれない。そこから遡って「やっぱり止めて」を受け付けたら、約束が無意味になり、待ち合わせを省いた意味も消えます。だから passive リスナの preventDefault() は仕様上no-opと定められています。

既定で passive 化される対象

スクロール性能を底上げするため、近年のブラウザは一部のリスナを既定で passive 扱いにするようになりました。Chrome や Firefox では、window / document / document.body に直接登録された touchstart / touchmove（および wheel / mousewheel）リスナの passive 既定値が、未指定のとき false ではなく true に切り替わっています。

// 旧来の意図：このリスナでスクロールを止めたい
// だが document 直付けで passive 未指定だと、既定 passive:true により
// preventDefault が効かず、警告だけ出てスクロールは止まらない
document.addEventListener('touchmove', e => {
  e.preventDefault();   // 既定 passive 化された環境では無視される
});

// 正しい：止める意図があるなら passive:false を明示する
document.addEventListener('touchmove', e => {
  e.preventDefault();
}, { passive: false });

コンポジタスクロールを妨げない設計

passive を正しく使うことは、スクロールをメインスレッドから解放してコンポジタスレッドに任せる設計と同義です。指針は次の通りです。

• デフォルトは passive に倒す：スクロール監視・遅延読み込み・視差効果など「観測するだけ」のリスナは、すべて {passive: true} を明示する。既定 passive 化に頼らず明示することで、子要素登録でも一貫した挙動になります。
• 止めるときだけ passive:false：preventDefault() でスクロールを実際に抑止する箇所のみアクティブにする。範囲は最小限に絞る。
• 抑止は touch-action を第一候補に：横スクロールだけ許す・ズームを禁じるといった意図は、JSの preventDefault() ではなくCSSの touch-action（例 touch-action: pan-y）で宣言する。これはコンポジタ側で完結し、リスナをアクティブにせずに済みます。
• リスナの中身も軽く保つ：passive でもリスナはメインスレッドで走ります。スクロールハンドラ内での読み取りがレイアウトを強制同期させないよう、計測は IntersectionObserver/ResizeObserver に寄せると、ジャンク要因をさらに減らせます。

// 観測専用ハンドラは passive、レイアウト読みは観測APIに逃がす
window.addEventListener('scroll', updateProgressBar, { passive: true });

// ズーム禁止・縦スクロールのみ許可は CSS で宣言（JS の preventDefault 不要）
// .stage { touch-action: pan-y; }

まとめ