「スクロールのたびに処理が走って重いので、間引いてください」という依頼が来ます。実装する側は、デバウンスとスロットルのどちらかを選びます。そして毎回少し迷います。どちらも呼び出し回数を減らす手法に見えるからです。
迷ったときに「回数が減るならどちらでもいい」で決めたことがあります。結果として、間引けているのに要件を満たしていない状態になりました。リクエストは確かに減っていて、計測上は改善しています。しかし画面の挙動は依頼の意図と違っていました。
定義を読み直すと、2つが決めているのは回数ではありませんでした。本記事が立てる仮説はこれです——デバウンスとスロットルが分けているのは、どの時点の入力を正として採用するかと、連続しているあいだ途中経過を出す義務があるかであって、呼び出し回数の多寡は結果として付いてくるものではないか。
この見立てが当たっているなら、起きる失敗は具体的です。「リクエストが8割減りました」という報告が通る。しかし検索サジェストは入力途中の文字列で検索し続けており、スクロール追従の要素は指を止めた瞬間に飛ぶ。どちらも数字の上では改善していて、要件の上では失敗しているという状態です。
本記事は2つの選択に絞ります。読み込み速度や描画の最適化の進め方はWebパフォーマンス最適化：LCP・INP・CLSから原因を絞って改善するに預け、ここでは扱いません。特定のライブラリの実装や既定値も扱いません（一次情報が「通例」としてしか書いていない部分を仕様のように扱わないためです）。
30秒で要点
- 連続して呼ばれ続けているあいだ、スロットルは一定の最大レートでの実行を保証し、デバウンスは呼び出しが止まるまで無期限に待つ
- したがって採用される入力が違う。デバウンスは最終状態、スロットルは途中経過を出し続ける
- 待ち時間の起点も違う。デバウンスは「最後の呼び出し」から、スロットルは「最初の呼び出し」から計測される
- 判断は3問に還元できる。途中の出力に意味があるか／最後の値を必ず反映する必要があるか／実行までの待ち時間に上限が必要か
- 効果を「呼び出し回数の削減率」で測ると、取り違えが検出できない。測るべきは回数ではなく、採用された入力のほう
一次情報が書いている定義を先に置く
参照するのは MDN の用語集2ページ、Debounce と Throttle です（いずれも2026年10月21日に取得して確認。ページの最終更新表示はどちらも2025年7月11日）。
書かれている定義はそれぞれ1文です。
デバウンスとは、特定の間隔のうちに近接して発生した操作を捨て、それらを1回の呼び出しにまとめることです。
スロットルとは、ある操作が一定のレートでしか実行されないように処理を遅くすることです（原義として、障害物によって流体の流量を落とすことも併記されています）。
この2つを並べただけでは、まだ「どちらも減らす手法」に見えます。差がはっきりするのは、両ページが互いを参照して書いている対比の部分です。
呼び出しが連続して起きているとき、スロットルは操作が一定の最大レートで実行されることを保証し、デバウンスは呼び出しが一定時間止まるまで無期限に待つ。
ここが本記事の芯です。スロットルは「実行されること」を保証し、デバウンスは「止まること」を待ちます。 保証しているものが違うので、連続中の振る舞いが反対になります。
待ち時間の起点が違う
もう1つ、設計上影響の大きい非対称性が定義に含まれています。実行のタイミング（trailing edge）を測る起点です。
表が収まらない場合は、横にスクロールできます
| 同じバッチと判定する基準 | trailing edge の起点 | |
|---|---|---|
| デバウンス | 直前の呼び出しから一定時間以内 | 最後の呼び出しから一定時間が経過した時点 |
| スロットル | 最初の呼び出しから一定時間以内 | 最初の呼び出しから一定時間が経過した時点 |
一次情報は、デバウンスの例について「search への最後の呼び出しから10ミリ秒が経過し、他の呼び出しが起きていなければ trailing edge に到達した」と書き、スロットルの例について「onScrolled への最初の呼び出しから10ミリ秒が経過した時点で trailing edge に到達した」と書いています。10ミリ秒という値は説明のための例であり、値そのものに意味はありません。
この起点の違いが、2つの性質を決めています。デバウンスは最後の呼び出しを基準にするので、呼び出しが続くかぎり実行は後ろへずれます。実行までの待ち時間に上限がありません。 スロットルは最初の呼び出しを基準にするので、連続していても一定間隔で実行が来ます。
連続中に何が起きるかで、採用される入力が決まる
一次情報は、スロットルの連続中の振る舞いを具体的に書いています。スロットルを介しても処理の効果は連続的に更新・適用され続ける。たとえばドキュメントのスクロール位置に応じて別の要素を動かす処理なら、ページをスクロールしているあいだもその要素は動き続ける。ただし必要以上の頻度では実行されない、と。
一方デバウンスの典型的な用途として挙げられているのは、ユーザー入力への応答です。ユーザーがタイプしているあいだは、画面の操作感が重くならないように他の処理を行わない。タイプが止まったところで、入力の処理（結果の絞り込みや候補の提示など）を始める、と書かれています。
この2つを並べると、「どの時点の入力が採用されるか」という違いが見えます。
- デバウンス：連続中は何も出さず、止まってから1回出す → 採用されるのは最終状態
- スロットル：連続中も一定レートで出し続ける → 採用されるのは途中経過
依頼の言葉は「間引いてください」ですが、決めているのはこちらです。途中経過を出す義務があるかどうかを決めずに手法を選ぶと、回数は減るのに挙動が合わない状態になります。
間引けているのに要件を満たさない2例
取り違えの結果は、どちらも「数字は良くなったのに挙動が違う」という形で現れます。
例1：検索サジェストにスロットルを使う。 一定レートで実行が続くので、あ あお あおも のような入力途中の文字列でもリクエストが飛びます。回数は減っています。しかし「確定した入力に対して検索する」という要件は満たしていません。途中経過に意味が無い処理に、途中経過を出す手法を当てた状態です。
例2：スクロール追従の要素にデバウンスを使う。 スクロールしているあいだ、呼び出しが続くので実行は後ろへずれ続けます。つまりスクロール中は何も動かず、指を止めた瞬間に要素が飛びます。回数は減っています。しかし「スクロールに追従する」という要件は満たしていません。途中経過に意味がある処理から、途中経過を奪った状態です。
なお一次情報は、scroll イベントは1ピクセルのスクロールごとに発火しうるため非常に短い間隔で関数が呼ばれると書いています。そして処理が計算量的に重い場合、先の呼び出しが後の呼び出しを時間どおりに実行できなくしたり、そのあいだ他の処理の実行を妨げたりして、目に見えるジャンク（引っかかり）につながりうるとしています。間引く動機そのものは、ここに書かれているとおりです。動機は正しくても、手法の選択は別の判断です。
なぜ「どちらでもいい」に見えてしまうのか
ここまでの整理をしても、現場で2つが同じものに見える理由があります。観測される指標が同じだからです。
ネットワークタブを開けばリクエスト数が見えます。プロファイラを開けば関数の呼び出し回数が見えます。どちらの手法を入れても、これらの数字は下がります。下がる数字が共通なので、2つの手法は同じ効果を持つものとして記録されます。
採用された入力の時点は、どの計測ツールにも表示されません。表示されるのは回数です。見える指標で評価すると、2つは区別できない——という構造になっています。
もう1つは、言葉の側にあります。依頼は「間引いてください」で来ます。この言葉は回数の話をしているので、受け取る側も回数の問題として解きます。依頼の言葉が、判断すべき軸を隠してしまうわけです。本来確認すべきは「連続しているあいだ、出力は必要ですか」の1問です。
判断軸：3つの問いに還元する
選ぶときに立てる問いは3つです。
問い1：連続しているあいだの出力に、意味があるか。
意味があるならスロットル（スクロール連動の表示、進捗の更新、ドラッグ中のプレビュー）。意味がないならデバウンス（検索サジェスト、入力値の保存、フォームの検証）。1問目で向きが決まります。
問い2：最後の値を必ず反映する必要があるか。
スロットルを選んだ場合に効いてきます。一定レートでの実行は、連続が終わった最後の状態が実行済みであることを保証しません。最後の値を反映する必要があるなら、trailing edge 側での実行を有効にしておく必要があります。ここは使うライブラリの設定で確認する項目です（一次情報は、どのエッジで実行するかは用途次第であり、デバウンスは通例 trailing edge のみ、スロットルは通例 leading edge のみとしつつ、leading・trailing・両方のいずれもありうると書いています。つまり既定値は仕様ではありません）。
問い3：実行までの待ち時間に上限を置く必要があるか。
デバウンスを選んだ場合に効いてきます。待ち時間の起点が「最後の呼び出し」である以上、呼び出しが続くかぎり実行はずれ続けます。入力が長く続く状況で「最長でも○秒後には1回実行する」という要件があるなら、デバウンス単独ではその上限を保証できません。上限が必要なら、スロットルと組み合わせるか、要件そのものを見直す段階になります。
3問の答えが衝突する場合——途中経過も必要で、最後の値も必須で、待ち時間に上限も必要——は、間引き方の選択で解く問題ではありません。処理を分割し、軽い更新は連続中に、重い確定処理は停止後に、と役割を分ける段階に移ります。
「効いているか」を回数で測らない
ここが、この記事でいちばん実務に効く部分です。効果を測る指標を、手法ごとに変えます。
デバウンスの場合
- 分母：確定した入力の件数（単位は件。ユーザーが入力を止めた回数）
- 分子：その入力に対して実行された処理の回数（単位は回）
- 満たすべき条件：比が 1.0（1つの確定入力に対して1回）
スロットルの場合
- 測るもの1：連続中の実行間隔（単位はミリ秒）。満たすべき条件は、設定した上限以内に収まっていること
- 測るもの2：連続が終わった時点の状態が反映されているか（単位は真偽）。満たすべき条件は、最終状態が画面・保存値に反映されていること
この定義を置くと、「リクエストが8割減りました」が合格条件にならなくなります。削減率はどちらの手法でも下がるので、取り違えを検出できない指標です。一方、上の定義なら例1は比が1.0にならず、例2は実行間隔が上限を超えるので、どちらも不合格として現れます。
手元で試せる最小の確認
実装済みの箇所を1つ選んで、確認を1回だけ行います。
- その処理を連続して発生させる（入力欄に数文字を続けて打つ、ページを数秒スクロールし続ける）
- 連続しているあいだ、画面に変化が出ているかを見る
- 連続をやめた直後に、最後の状態が反映されているかを見る
2で変化が出ていて3も反映されていれば、スロットルで trailing edge 側も効いている状態です。2で何も出ず3で反映されるなら、デバウンスです。2で変化が出ているのに3が反映されていないなら、最後の値が落ちています。
そのうえで、2と3の結果が要件と合っているかを確認します。ここまでが1セットです。回数を数える必要はありません。見るのは、どの時点の入力が画面に残ったかです。
確かなことと、確かでないこと
確かなこと（2026年10月21日に一次情報を取得して確認した範囲）：デバウンスとスロットルそれぞれの定義、連続中はスロットルが一定の最大レートでの実行を保証しデバウンスは無期限に待つという対比、trailing edge の起点が「最後の呼び出し」と「最初の呼び出し」で異なること、スロットルでは効果が連続的に更新・適用されること、デバウンスの典型的な用途がユーザー入力への応答であること、scroll イベントが1ピクセルごとに発火しうることと重い処理がジャンクにつながりうること、どのエッジで実行するかが用途次第であること。
確かでないこと：どのエッジで実行するかについて、一次情報の記述は「通例」としての説明であり、仕様ではありません。したがって特定のライブラリの既定値がこれと一致する保証はありません。使うライブラリの設定は、そのライブラリの文書で確認する必要があります。
本記事が扱っていないこと：ページ離脱や画面遷移の際に trailing edge の実行が来るかどうか。一次情報にその記述はないため、本記事では断定も仮説の提示もしていません。実測の削減率やベンチマーク値も扱っていません（一次情報に計測結果がないためです）。本記事の例示はすべて説明のための作例で、一次情報に掲載されたコード例ではありません（両ページにコード例はありません）。また、どちらが速い・軽いという比較もしていません。一次情報はレートと待ち方の違いを述べており、性能の優劣を比較していないためです。
選ぶときに立ち返る問い
立ち返りたいのは、「この処理は、連続しているあいだ何を見せる義務があるか」という問いです。義務があるならスロットル、ないならデバウンス。回数の話はそのあとに付いてきます。
もう1つは、「採用されたのは、どの時点の入力か」という問いです。回数は減らせても、採用される時点は選ばないと決まりません。そして採用された時点は、計測ツールには表示されません。表示されないものを要件にしているとき、合否は自分で定義するしかありません。
「間引く」という言葉は、2つの手法の共通点だけを指しています。選ぶために必要な情報は、その言葉の外側にあります。
参考資料・引用元
- Debounce — MDN Glossary（ページの最終更新表示は2025年7月11日、2026年10月21日確認）
- Throttle — MDN Glossary（ページの最終更新表示は2025年7月11日、2026年10月21日確認）