디바운스와 쓰로틀
웹에서 사용자의 입력이나 스크롤 이벤트는 매우 빠르게, 때로는 초당 수십~수백 번씩 발생한다.
이런 이벤트를 매번 처리한다면 성능 저하와 불필요한 네트워크 요청으로 이어지게 된다.
이를 방지하기 위해 대표적으로 사용하는 최적화 기법이 디바운스(debounce) 와 쓰로틀(throttle) 이다.
⚡ 디바운스(Debounce) — 이벤트가 멈출 때까지 기다리는 방식
디바운스는 “사용자의 행동이 잠잠해질 때까지 기다렸다가 한 번 실행”
연속해서 이벤트가 발생하면 타이머를 계속 초기화하기 때문에 마지막 이벤트가 끝난 뒤 일정 시간 후에 실행된다.
예를 들어:
- 검색창 입력 → 입력을 멈춘 뒤 300ms 후 검색 API 실행
- 윈도우 리사이즈 → 더 이상 리사이즈하지 않을 때 레이아웃 계산
🟢 장점
- 불필요한 호출을 최소화함
- 사용자 동작이 끝난 뒤 확실히 한 번만 실행됨
🔴 단점
- 이벤트 실행이 지연됨
- 즉각적인 반응이 필요한 곳에서는 부적합
⚡ 쓰로틀(Throttle) — 일정 주기마다 한 번만 실행하는 방식
쓰로틀은 “일정 시간 동안은 이벤트 핸들러를 최대 한 번만 실행”
즉, 이벤트가 아무리 많이 발생해도 지정한 시간(예: 300ms) 동안은 추가 실행이 막힌다.
예를 들어:
- 스크롤 이벤트 → 200ms 간격으로만 실행
- 연속 클릭 방지 → 일정 시간 내 1회만 처리
🟢 장점
- 빠르게 발생하는 이벤트에서도 성능 유지
- 반응이 지연되지 않고 주기적으로 실행됨
🔴 단점
- 지정된 시간 사이에 발생한 이벤트 대부분은 무시됨
- 아주 정확한 “마지막 이벤트” 타이밍이 필요할 때는 부적합
무한 스크롤에는 무엇을 써야 할까?
정답은 쓰로틀(throttle)이다.
왜 디바운스는 적합하지 않을까?
무한 스크롤에서 가장 중요한 포인트는 사용자가 페이지 하단에 도달했을 때 즉시 데이터를 불러오는 것이다.
하지만 디바운스를 사용하면:
- 스크롤이 끝났다고 판단한 시점 이후에야 이벤트가 실행되므로 데이터 로딩이 지연되어 느린 UX 가 된다.
즉,
디바운스 = “멈춘 뒤 실행 → 반응이 늦다”
반면, 쓰로틀을 사용하면?
쓰로틀은 스크롤 이벤트가 계속 발생해도 주기적으로 실행되기 때문에, 사용자가 하단에 가까워지는 순간 빠르게 로딩을 트리거할 수 있습니다.
예를 들어:
- 200ms 간격으로 스크롤 상태를 체크
- 화면 끝에 도달하면 즉시 데이터 로딩
결과적으로,
쓰로틀 = “빠르게 반응하면서도 과도한 호출을 막는다”
🧩 결론
| 상황 | 적합한 기법 | 이유 |
|---|---|---|
| 검색창 입력, 자동완성 | 디바운스 | 입력이 끝난 뒤 한 번만 실행 |
| 윈도우 리사이즈 | 디바운스 | 마지막 상태에 맞춰 계산 |
| 스크롤 이벤트 최적화 | 쓰로틀 | 즉각 반응 + 과도한 호출 방지 |
| 무한 스크롤 | 🔥 쓰로틀 추천 | 빠른 반응성, 자연스러운 UX |
무한 스크롤은 “사용자의 스크롤 동작에 빠르게 반응해야 하는 기능”이기 때문에, 지연을 유발하는 디바운스보다는 쓰로틀이 훨씬 더 자연스러운 경험을 제공한다.
하지만, 요즘 프로젝트에서는 바닥에 닿으면 데이터가 나오는 최신 무한 스크롤 구현에서는 쓰로틀이 필요하지 않다. 대신 Intersection Observer를 쓴다.