Livraison d’images orientée INP 2025 — Protéger la performance perçue via decode/priority/coordination avec les scripts

Introduction

Améliorer LCP est essentiel, mais en 2024–2025 beaucoup négligent l’INP (Interaction to Next Paint). Une décodification d’image lourde ou une initialisation bloquante autour de la première interaction peut dégrader la réactivité. Quand des « bouffées de lazy‑load », la décodification et l’initialisation de scripts s’empilent juste après le premier défilement/tap, on perd des frames et l’input devient lent.

Ce guide met d’abord « éliminer la sur‑diffusion depuis le layout », puis organise les pratiques qui protègent l’INP via decode/priority/lazy et coordination des scripts. Nous montrons le partage des rôles entre hero et images sous la ligne de flottaison, l’usage de Next.js (App Router) et des APIs navigateur, et la vérification par RUM.

TL;DR

• Supprimer la sur‑diffusion (concevoir sizes/srcset depuis le layout)
• priority/fetchPriority="high" uniquement pour les candidats LCP ; sinon decoding="async" + lazy
• Éviter la concurrence chargement/décodification/initialisation autour de la première interaction
• Le placeholder ne doit pas causer de CLS (LQIP/BlurHash)

Pour sizes/srcset détaillé, voir Conception d’images responsives 2025 — Guide pratique srcset/sizes et Flux de redimensionnement 2025 — Réduire 30–70 % en raisonnant depuis le layout.

Pourquoi les images peuvent dégrader l’INP (modèle mental)

Le navigateur procède « téléchargement → décodification → layout/peinture ». L’INP mesure de l’entrée au prochain paint. Si une décodification lourde ou un re‑layout intervient juste avant/après le traitement d’entrée, l’INP se dégrade.

• Si des lazy‑loads se déclenchent en masse après l’entrée, le thread principal se sature (decode/layout)
• Des images surdimensionnées se décodent plus lentement (sur‑diffusion = LCP et INP en baisse)
• L’initialisation des scripts (parallaxe, filtres, Canvas) entre en collision avec la décodification

Remède en trois: « taille juste », « priorité sélective », « séparation temporelle ».

Modèles Next.js (App Router)

<Image
  src="/hero-1536.avif"
  alt="Visuel hero produit"
  fill
  sizes="(max-width: 768px) 100vw, 768px"
  priority
  fetchPriority="high"
  decoding="sync"
/>

<Image
  src="/gallery-640.webp"
  alt="Galerie"
  width={640}
  height={360}
  sizes="(max-width: 768px) 100vw, 768px"
  loading="lazy"
  decoding="async"
/>

Notes :

• Seuls les LCP utilisent sync/priority/high
• Un sizes correct permet le choix optimal de la source (évite la sur‑diffusion)

Lazy granulaire et coordination scripts

• Éviter les tâches lourdes 300–500 ms autour de l’entrée
• IntersectionObserver : précharger juste avant visibilité et éviter les collisions post‑entrée
• Longues inits (Canvas/filtres) via idle/scheduler

let lastInput = 0;
['pointerdown','keydown','wheel','touchstart'].forEach((t) => {
  addEventListener(t, () => (lastInput = performance.now()), { passive: true });
});

export function scheduleAfterInput(task: () => void) {
  const dt = performance.now() - lastInput;
  if (dt < 300) setTimeout(task, 300 - dt);
  else requestIdleCallback(() => task());
}

Placeholders et CLS

Définir width/height ou aspect‑ratio, utiliser LQIP/BlurHash. Voir Conception de placeholders LQIP/SQIP/BlurHash — Guide pratique 2025.

Mesure

• RUM (web‑vitals) pour l’INP
• Long Tasks après entrée
• Lighthouse Timespan pour scénarios d’interaction

Résumé

Protégez l’INP avec « stop à la sur‑diffusion », « priorité correctement attribuée », « travaux lourds hors de la fenêtre d’entrée ». Ajoutez la coordination temporelle à vos efforts LCP, suivez en RUM et interdisez priority hors hero via lint/CI.