Comment diagnostiquer le jank à l'exécution, les long tasks et un mauvais INP ?

Question

IT Interview Practice · Accepted Answer

Le jank à l'exécution vient des **long tasks qui bloquent le main thread** — l'unique thread qui gère le JS, le layout, le paint et les entrées. Quand une tâche s'exécute trop longtemps, les entrées ne peuvent pas être traitées, si bien que les interactions semblent figées et que l'**INP** grimpe.

## Le modèle central : le main thread

```text
Main thread: [ event handler 180ms ]  entrée en file... rendu ─▶ INP = temps jusqu'au prochain paint
             └── une « long task » (>50ms) bloque tout, y compris la réponse au clic
```

L'INP mesure le délai entre une interaction utilisateur et le prochain paint. Il comporte trois parties : le **input delay** (main thread occupé au moment du clic), le **processing time** (votre handler), et le **presentation delay** (style/layout/paint ensuite).

## Diagnostic

- **Panneau Performance** (Chrome DevTools) : enregistrez une interaction, cherchez les **Long Tasks** signalées en rouge (>50 ms) et les frames de handler larges.
- **PerformanceObserver** pour attraper les long tasks sur le terrain :

```js
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) report("longtask", entry.duration); // trouver les bloqueurs réels
  }
}).observe({ type: "longtask", buffered: true });
```

## Correctifs

- **Découpez les long tasks** — fractionnez le travail et cédez la main pour que les entrées puissent l'interrompre :

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

- **Déplacez les calculs lourds vers un Web Worker** — gardez le parsing/crunching hors du main thread.
- **Debounce/throttle** les handlers coûteux ; **virtualisez** les longues listes ; mémoïsez pour réduire les re-rendus.
- **Différez le travail non urgent** avec `requestIdleCallback` ou les priorités de `scheduler.postTask`.

## Pourquoi c'est important

L'INP est le plus récent Core Web Vital et le plus difficile à corriger car il concerne l'*exécution*, pas le chargement. On attend des seniors qu'ils raisonnent à partir du modèle mono-thread — les long tasks bloquent les entrées — et qu'ils recourent au yielding, aux workers et au scheduling plutôt que de se contenter d'« optimiser le code ».

Le modèle central : le main thread

Diagnostic

Correctifs

Pourquoi c'est important

Questions connexes