scrollイベントが重い・発火しすぎる原因と対策（デモ付き）

症状：スクロールに処理を連動させたらカクついた

ページのスクロールに合わせて何かを動かす実装はよくあります。目次の「今どこを読んでいるか」をハイライトするスクロールスパイ、上部の進捗バー、要素をふわっと動かす視差効果などです。こうした処理を window や要素の scroll イベントに書くと、スクロールがなめらかに動かず、指で弾いた勢いにハイライトの更新が遅れてついてくる、いわゆる「カクつき」が起きることがあります。特にスマートフォンや、要素数の多い長いページで顕在化します。

原因を一言でまとめると、scrollイベントは1回のスクロールで大量に発火し、そのハンドラの中に「重い処理」を書いてしまっていることにあります。ただし「発火が多い」ことと「1回が重い」ことは別の問題で、効く対策も違います。まずはこの2つを切り分けます。

原因：「発火が多い」×「1回が重い」の掛け算

scrollのカクつきは、次の要因が重なって起きます。原因は大きく分けて次の4つです。

つまりカクつきは「発火が多い」×「1回が重い」の掛け算です。発火回数を減らす（間引く）だけでも、1回を軽くする（レイアウト読み取りを減らす）だけでも効きますが、両輪でやるのが基本です。そしてもう一段上に、そもそもscrollイベントを使わずに済ませられないかという選択肢があります。多くのケースは、これが最も効きます。

デモ：発火回数を見比べる

下は目次付きの本文（スクロールスパイ）です。右側をスクロールすると、左のナビが現在地に合わせてハイライトされます。上のタブで実装を切り替えられます。「scrollイベント発火」と「現在地の測定（レイアウト読み取り）」の回数がそれぞれカウントされるので、スクロールしながら数字を見比べてください。

ガードなしでは、scrollが発火するたびに全セクションの getBoundingClientRect() を読んで現在地を計算しているため、2つの数字がぴったり同じペースで増えます。この測定が原因2の強制同期レイアウトで、要素が多いページほど1回のコストが上がり、発火回数と掛け算されてカクつきになります。

対策1：処理を間引く（throttle＋requestAnimationFrame）

scrollイベント自体を減らすことはできませんが、ハンドラの中身を毎回動かさないことはできます。画面の更新は1フレーム（約16ミリ秒）に1回で十分なので、requestAnimationFrame で「次の描画タイミングまでに1回だけ」実行するようまとめます。これがスクロール連動でのthrottle（間引き）の定番です。

// scrollは何度でも発火してよい。実処理はrAFで1フレーム1回に間引く
var ticking = false;

scrollEl.addEventListener('scroll', function () {
  if (ticking) return;        // 予約済みなら何もしない
  ticking = true;
  requestAnimationFrame(function () {
    updateActive();           // 重い処理（現在地の測定）はここで1回だけ
    ticking = false;
  });
}, { passive: true });        // ← passiveも付ける（対策3）

ここで大事な注意点があります。モダンブラウザのscrollイベントは、もともと描画の直前にまとめて発火するため、実質1フレームに約1回しか飛びません。そのためデモのthrottleタブでも、scroll発火と測定の回数はガードなしと近い値で並走します。「rAFで間引いたのに回数が減らない」のは正しい挙動で、ブラウザがすでにフレーム単位まで間引いているからです。

では何のためにrAFで包むのか。ひとつは上限の保証です。古いブラウザや一部のデバイスがscrollを1フレームに何度も飛ばす環境でも、測定を1フレーム1回に抑えられます。もうひとつは実行タイミングで、レイアウトの読み取りをscrollイベント内で同期的に走らせず、描画の直前にまとめて行うことで、対策2のスラッシングを避けられます。requestAnimationFrame は画面のリフレッシュと歩調が合うため、スクロール連動の見た目更新にはこれが素直です。

逆に、回数そのものを目に見えて減らしたい場面は、ブラウザがフレーム同期させない resize や mousemove／pointermove、あるいは setTimeout で「100msに1回」のようにフレームより粗く間引くケースです。そこではthrottleの効果がカウントにはっきり表れます。scrollに関しては、回数はもとからフレーム同期なので、狙いは「回数を減らす」より「重い処理を正しいタイミングで1回だけ動かす」に置きます。

対策2：1回を軽くする（読み取りと書き込みを分ける）

間引いても、1回の処理が重ければカクつきは残ります。原因3のレイアウトスラッシングを避けるには、「読む」フェーズと「書く」フェーズを分けるのが基本です。位置の読み取りを先にまとめて済ませ、そのあとにスタイルの書き換えをまとめて行います。

// NG: 読む→書く→読む…で毎回レイアウトが再計算される
items.forEach(function (el) {
  var top = el.getBoundingClientRect().top; // 読む
  el.style.opacity = top < 300 ? 1 : 0.3;  // 書く（次の読み取りを重くする）
});

// OK: 先に全部読んでから、まとめて書く
var tops = items.map(function (el) {
  return el.getBoundingClientRect().top;    // 読むだけ
});
items.forEach(function (el, i) {
  el.style.opacity = tops[i] < 300 ? 1 : 0.3; // 書くだけ
});

そもそもレイアウト値を読まずに済むなら、それがいちばん軽くなります。スクロール量だけが必要なら scrollEl.scrollTop（や window.scrollY）で足り、要素ごとの getBoundingClientRect() は不要なことも多いです。次の対策4のIntersectionObserverは、この「位置の読み取り自体をやめる」を仕組みで実現します。

対策3：passiveリスナーにする（ただし誤解に注意）

scrollやtouchのリスナーには { passive: true } を付けます。これは「このハンドラは preventDefault() を呼びません」という宣言で、ブラウザはハンドラの完了を待たずにスクロールを進められます。スクロールの引っかかり（原因4）を防ぐ効果があります。

scrollEl.addEventListener('scroll', onScroll, { passive: true });

passiveはスクロールを待たせないための宣言であって、ハンドラの中身を軽くするものではない。

ここが誤解されがちな点です。passiveを付けても、ハンドラ内の強制同期レイアウトや重い計算はそのままのコストで走ります。つまりpassiveは「対策1（間引き）」「対策2（軽くする）」の代わりにはなりません。3つはそれぞれ別の効き方をするので、併用します。なお touchstart / touchmove / wheel は主要ブラウザでは既定がpassive寄りに変わっている場合がありますが、明示しておくと意図が読み手に伝わり、環境差にも左右されません。挙動の最新の扱いはMDNのaddEventListenerで確認できます。

対策4：そもそもscrollイベントをやめる

ここまでは「scrollイベントを使い続ける前提」での手当てでした。ですが多くのUIは、scrollイベントを使わずに書けます。やりたいことから逆算して手段を選ぶと、そもそも重いハンドラを書かずに済みます。

追従だけなら position: sticky でJavaScriptは要りません（追従ヘッダーの事例）。要素が画面に入ったかを知りたいだけなら IntersectionObserver が最適で、遅延読み込みや無限スクロール（無限スクロールの事例）、デモのスクロールスパイもこれで書けます。scrollイベントが本当に必要なのは、進捗バーのように「スクロール量そのもの」に連続的に連動させたい場合に絞られます。

ここで throttleとdebounceの違いにも触れておきます。throttleは「一定間隔で定期的に実行する」間引きで、スクロール連動のように動いている最中も更新したい処理に向きます。debounceは「動きが止まってから1回だけ実行する」間引きで、検索入力やリサイズ完了後の処理に向きます（インクリメンタル検索の事例でdebounceを使っています）。スクロール中に更新したいのか、止まってからでよいのかで選び分けます。

修正デモの答え合わせ：IntersectionObserverで書く

デモのIntersectionObserverタブは、次のように書いています。scrollイベントを一切登録せず、各セクションを監視して、表示領域の指定した位置に入ったものを現在地にしています。rootMargin で「上のほうに来たら」というバンドを作るのがポイントです。

var io = new IntersectionObserver(function (entries) {
  entries.forEach(function (e) {
    if (e.isIntersecting) {
      setActive(sections.indexOf(e.target)); // 現在地を更新
    }
  });
}, {
  root: scrollEl,                  // スクロールする親（ページ全体ならnull）
  rootMargin: '-10% 0px -80% 0px', // 上端から10%〜20%の細いバンドで判定
  threshold: 0
});

sections.forEach(function (s) { io.observe(s); });

scrollイベントを使わないので、発火回数は0のまま。ブラウザが交差の監視を最適化してくれるため、こちらが位置を読み取る必要もありません。強制同期レイアウトもレイアウトスラッシングも、そもそも書きようがない構造になります。これが「重いハンドラを書かない」の意味です。

まとめ

scrollイベントが重い・カクつくのは、「発火が多い」ことと「ハンドラ1回が重い」ことの掛け算です。順番に手を打ちます。

まず「scrollイベントを使わずに済むか」を考える。使うなら、rAFで間引き、レイアウト読み取りを減らし、passiveを付ける。

最初に検討するのは、追従なら position: sticky、出現検知なら IntersectionObserver への置き換えです。scrollイベントがどうしても必要な処理だけを残し、そこに requestAnimationFrame での間引き、読み取りと書き込みの分離、{ passive: true } の3つを組み合わせます。passiveは万能薬ではなく、間引き・軽量化と役割が違う点だけ押さえておけば、たいていのカクつきは避けられます。

参考資料

スクロールとパフォーマンス周りは、次の一次情報で挙動を確認できます。

• MDN: Document: scroll イベント
• MDN: IntersectionObserver
• MDN: EventTarget.addEventListener（passiveオプション）