런타임 버벅임, long task, 나쁜 INP를 어떻게 진단하나요?

Question

IT Interview Practice · Accepted Answer

런타임 버벅임(jank)은 **메인 스레드를 막는 long task**에서 옵니다 — JS, 레이아웃, 페인트, 입력을 모두 처리하는 단일 스레드 말입니다. 태스크가 너무 오래 실행되면 입력을 처리할 수 없어 상호작용이 얼어붙은 듯 느껴지고 **INP**가 올라갑니다.

## 핵심 모델: 메인 스레드

```text
메인 스레드: [ 이벤트 핸들러 180ms ]  입력 큐잉... 렌더됨 ─▶ INP = 다음 페인트까지의 시간
             └── "long task"(>50ms)가 클릭 응답을 포함한 모든 것을 막음
```

INP는 사용자 상호작용부터 다음 페인트까지의 지연을 측정합니다. 세 부분으로 이루어집니다: **입력 지연**(클릭 시 메인 스레드가 바쁨), **처리 시간**(여러분의 핸들러), **표현 지연**(이후 스타일/레이아웃/페인트).

## 진단

- **Performance 패널**(Chrome DevTools): 상호작용을 기록하고 빨간 표시된 **Long Task**(>50ms)와 넓은 핸들러 프레임을 찾으세요.
- **PerformanceObserver**로 필드에서 long task를 포착:

```js
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) report("longtask", entry.duration); // 실제 사용자 차단 요소 찾기
  }
}).observe({ type: "longtask", buffered: true });
```

## 개선책

- **Long task를 쪼개세요** — 작업을 나누고 양보(yield)하여 입력이 끼어들 수 있게 하세요:

```js
async function process(items) {
  for (const item of items) {
    doWork(item);
    if (navigator.scheduling?.isInputPending?.()) await yieldToMain(); // 클릭을 통과시킴
  }
}
const yieldToMain = () => new Promise((r) => setTimeout(r, 0));
```

- **무거운 연산을 Web Worker로 이동** — 파싱/계산을 메인 스레드 밖으로.
- 비싼 핸들러를 **디바운스/스로틀**, 긴 리스트를 **가상화(virtualize)**, 재렌더링을 줄이려 메모이제이션.
- `requestIdleCallback`이나 `scheduler.postTask` 우선순위로 **급하지 않은 작업을 미루세요**.

## 왜 중요한가

INP는 가장 최신 Core Web Vital이자 고치기 가장 어렵습니다. 로드가 아니라 *런타임*에 관한 것이기 때문입니다. 시니어는 단일 스레드 모델에서 추론하고 — long task가 입력을 막는다 — 단순히 "코드를 최적화하라"가 아니라 양보, 워커, 스케줄링에 손을 뻗을 것으로 기대됩니다.

핵심 모델: 메인 스레드

진단

개선책

왜 중요한가

관련 질문