Como diagnosticar jank de runtime, long tasks e INP ruim?

Question

IT Interview Practice · Accepted Answer

Jank de runtime vem de **long tasks bloqueando a thread principal** — a única thread que trata JS, layout, paint e input. Quando uma task executa por tempo demais, o input não pode ser processado, então as interações parecem congeladas e o **INP** sobe.

## O modelo central: a thread principal

```text
Thread principal: [ event handler 180ms ]  input na fila... renderizado ─▶ INP = tempo até o próximo paint
                  └── uma "long task" (>50ms) bloqueia tudo, inclusive responder ao clique
```

O INP mede o atraso de uma interação do usuário até o próximo paint. Ele tem três partes: **atraso de input** (thread principal ocupada quando você clica), **tempo de processamento** (seu handler) e **atraso de apresentação** (style/layout/paint depois).

## Diagnosticando

- **Painel Performance** (Chrome DevTools): grave uma interação, procure por **Long Tasks** (>50ms) sinalizadas em vermelho e frames de handler largos.
- **PerformanceObserver** para capturar long tasks em campo:

```js
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) report("longtask", entry.duration); // encontra bloqueadores de usuários reais
  }
}).observe({ type: "longtask", buffered: true });
```

## Correções

- **Quebre long tasks** — divida o trabalho e ceda a vez para que o input possa interromper:

```js
async function process(items) {
  for (const item of items) {
    doWork(item);
    if (navigator.scheduling?.isInputPending?.()) await yieldToMain(); // deixa os cliques passarem
  }
}
const yieldToMain = () => new Promise((r) => setTimeout(r, 0));
```

- **Mova computação pesada para um Web Worker** — mantenha o parsing/processamento fora da thread principal.
- **Debounce/throttle** em handlers custosos; **virtualize** listas longas; memoize para cortar re-renders.
- **Adie trabalho não urgente** com `requestIdleCallback` ou prioridades do `scheduler.postTask`.

## Por que isso importa

O INP é o Core Web Vital mais novo e o mais difícil de corrigir porque é sobre *runtime*, não carregamento. Espera-se que seniores raciocinem a partir do modelo de thread única — long tasks bloqueiam o input — e recorram a ceder a vez, workers e scheduling em vez de apenas "otimizar o código."

O modelo central: a thread principal

Diagnosticando

Correções

Por que isso importa

Perguntas relacionadas