INP Presentation Delay : taille du DOM, travail de mise en page et optimisation du rendu

Problèmes d'Interaction to Next Paint (INP) causés par le presentation delay

Cette page fait partie de notre série Interaction to Next Paint (INP). L'INP mesure le temps total entre une interaction utilisateur et la prochaine mise à jour visuelle. Le presentation delay est la troisième et dernière phase de l'INP, suivant l'input delay et le processing time. Si vous êtes nouveau avec l'INP, lisez d'abord notre guide sur comment identifier et corriger les problèmes d'INP.

En résumé : l'Interaction to Next Paint (INP) mesure le temps qu'il faut à un utilisateur pour voir un changement visuel sur une page après avoir interagi avec celle-ci. Cet INP peut être décomposé en 3 composants : "input delay", "processing time" et "presentation delay".

Le presentation delay est le principal contributeur au temps total d'INP, représentant environ 42% du temps total d'INP en moyenne. Optimiser votre pipeline de rendu et simplifier votre structure HTML est le levier le plus important pour améliorer l'INP.

Presentation Delay : Vous avez déjà cliqué sur un bouton et vous êtes demandé pourquoi il a fallu une fraction de seconde de trop pour voir le résultat ? C'est l'Interaction to Next Paint (INP) en action. Le presentation delay est la dernière étape du processus d'interaction, intervenant après le traitement de votre clic mais avant que vous ne voyiez des changements visuels.

Comprendre le presentation delay

La présentation est la phase finale d'une interaction. Le presentation delay représente le temps nécessaire au navigateur pour effectuer les mises à jour visuelles qui suivent l'interaction. Le presentation delay commence lorsque les gestionnaires d'événements de l'interaction ont terminé leur exécution et se termine lorsque la trame suivante (contenant les changements visuels) est peinte. Le presentation delay peut être affecté par divers facteurs, notamment la complexité de la mise en page, la taille du DOM et la quantité de travail de rendu nécessaire.

L'Interaction to Next Paint (INP) peut être décomposé en 3 sous-parties : "Input Delay", "Processing Time" et "Presentation Delay".

Presentation delay et l'INP

Le presentation delay est la dernière phase de l'INP. En moyenne, le presentation delay représente environ 42% du temps total d'INP, ce qui en fait le plus grand contributeur aux interactions lentes.

Chez CoreDash nous collectons des millions de points de données Core Web Vitals chaque heure. Sur la base de ces données, le presentation delay représente 42% de l'Interaction to Next Paint. C'est plus que le processing time (40%) et significativement plus que l'input delay (18%). Bien qu'il soit le plus grand contributeur, le presentation delay est souvent la phase la plus difficile à optimiser car il implique le pipeline de rendu du navigateur plutôt que le code de votre application.

Exemple de presentation delay : Imaginez que vous êtes sur votre téléphone en train de parcourir un site e-commerce à la recherche d'une nouvelle paire de chaussures. Vous appuyez sur une image de produit pour voir plus de détails. Cependant, votre téléphone est un peu ancien et a du mal à suivre. Vous appuyez sur l'image (Interaction). Le téléphone prend du temps pour traiter la demande et mettre à jour l'affichage (Processing Time). Le site web doit rendre la nouvelle page avec l'image agrandie et les détails. Enfin, il faut un temps notable pour que les nouveaux détails du produit et l'image apparaissent sur votre écran (Presentation Delay). Ce délai dans l'INP peut être frustrant pour les utilisateurs et c'est pourquoi il est important de le corriger.

Qu'est-ce qui cause un presentation delay élevé ?

Le presentation delay englobe tout le travail que le navigateur effectue après la fin de vos gestionnaires d'événements et avant que les pixels n'apparaissent à l'écran. Cela inclut le recalcul des styles, le calcul de la mise en page, la peinture et la composition. Plusieurs facteurs contribuent à un presentation delay élevé :

Taille du DOM importante

Un DOM volumineux ou profondément imbriqué est l'une des causes les plus courantes d'un presentation delay élevé. Chaque fois que le navigateur doit mettre à jour l'état visuel de la page après une interaction, il doit recalculer les styles, calculer la mise en page et repeindre les éléments affectés. Le coût de chacune de ces étapes augmente avec le nombre de nœuds DOM affectés.

Google recommande de maintenir votre DOM sous 1 400 éléments, avec une profondeur maximale de 32 niveaux et pas plus de 60 éléments enfants par nœud parent (voir l'audit de taille du DOM Lighthouse). Lorsque votre DOM dépasse ces seuils, le navigateur passe beaucoup plus de temps au recalcul des styles et au calcul de la mise en page après chaque interaction.

Considérez ce scénario : un utilisateur clique sur un bouton qui bascule une classe CSS sur un élément conteneur. Si ce conteneur a 5 000 nœuds descendants, le navigateur doit recalculer les styles pour potentiellement tous, même si seulement quelques éléments changent visuellement. Ce recalcul de styles se produit de manière synchrone avant la prochaine peinture, augmentant directement le presentation delay.

Pour des techniques spécifiques pour réduire votre DOM, lisez notre guide sur corriger une taille excessive du DOM.

Travail de mise en page excessif

La mise en page (aussi appelée "reflow") est le processus par lequel le navigateur calcule la position et les dimensions de chaque élément visible sur la page. Après une interaction qui modifie le DOM ou change des propriétés CSS affectant la géométrie (width, height, margin, padding, top, left), le navigateur doit effectuer la mise en page avant de pouvoir peindre la trame mise à jour.

Deux patterns sont particulièrement nocifs pour le presentation delay :

La mise en page synchrone forcée se produit lorsque JavaScript lit une propriété de mise en page (comme offsetHeight ou getBoundingClientRect()) après avoir effectué un changement DOM qui invalide la mise en page. Le navigateur est forcé d'effectuer la mise en page de manière synchrone, dans votre gestionnaire d'événements, pour retourner une valeur précise. Ce travail de mise en page fait alors partie du processing time, mais toute mise en page ultérieure déclenchée par d'autres changements DOM fait partie du presentation delay.

Le layout thrashing est le pattern répété d'écriture dans le DOM puis de lecture de propriétés de mise en page dans une boucle. Chaque lecture force le navigateur à recalculer la mise en page, et chaque écriture invalide la mise en page à nouveau. Cela peut causer des dizaines, voire des centaines de calculs de mise en page inutiles par interaction. Voici un exemple de layout thrashing et comment le corriger :

// BAD: Layout thrashing inside a loop
function resizeItems() {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    // Read (forces layout)
    const parentWidth = item.parentElement.offsetWidth;
    // Write (invalidates layout)
    item.style.width = parentWidth + 'px';
  });
}

// GOOD: Batch reads, then batch writes
function resizeItems() {
  const items = document.querySelectorAll('.item');
  // Read all values first
  const widths = Array.from(items).map(
    item => item.parentElement.offsetWidth
  );
  // Then write all values
  items.forEach((item, i) => {
    item.style.width = widths[i] + 'px';
  });
}

Rendu côté client dans les Single Page Applications

Le rendu côté client du HTML peut avoir un impact significatif sur le presentation delay, particulièrement dans les Single Page Applications (SPA). Lorsqu'une interaction utilisateur déclenche un changement de route ou une mise à jour importante de l'interface, le framework SPA doit :

1. Exécuter l'algorithme de comparaison du DOM virtuel pour déterminer ce qui a changé
2. Appliquer les mutations DOM résultantes au DOM réel
3. Déclencher le recalcul des styles et la mise en page pour tous les éléments affectés
4. Peindre la trame mise à jour

Dans les applications React, le processus de réconciliation du DOM virtuel fait partie du processing time, mais les mutations DOM résultantes et leur coût de rendu relèvent du presentation delay. Plus votre arbre de composants produit de nœuds DOM, plus la réconciliation et le travail de rendu subséquent sont coûteux.

Pour atténuer cela dans les applications React et Next.js :

• Utilisez React.memo() pour empêcher les re-rendus inutiles des composants enfants qui reçoivent les mêmes props.
• Utilisez useDeferredValue() pour les valeurs qui déclenchent des re-rendus coûteux, permettant à React de prioriser les mises à jour plus urgentes.
• Gardez les arbres de composants peu profonds. Les hiérarchies de composants profondément imbriquées produisent un DOM profondément imbriqué, ce qui augmente le coût à la fois de la réconciliation et du rendu du navigateur.
• Utilisez des bibliothèques de virtualisation (comme react-window ou @tanstack/react-virtual) pour les longues listes afin que le DOM ne contienne que les éléments visibles.

Réduire le presentation delay

Minimiser la taille du DOM

Le plus grand gain pour le presentation delay est de garder votre DOM petit :

• Supprimez les éléments HTML inutilisés, en particulier les divs d'encapsulation profondément imbriqués.
• Utilisez la virtualisation de liste pour les longues listes (rendez uniquement les éléments visibles plus un petit tampon).
• Aplatissez les structures profondément imbriquées lorsque c'est possible.
• Utilisez CSS Grid et Flexbox au lieu de divs imbriqués pour la mise en page.

// Virtualize long lists to reduce DOM size
// Before: 10,000 items in the DOM

<ul>
  {allItems.map(item => 
     <li key="{item.id}">{item.name}</li>)
   }
</ul>

// After: only visible items in the DOM (using react-window)
import { FixedSizeList } from 'react-window';
<fixedsizelist height="{600}" 
               itemcount="{allItems.length}" 
               itemsize="{50}" width="100%">  
  {({ index, style }) => (
    <div style="{style}">{allItems[index].name}</div>
  )}
</fixedsizelist>

Utiliser content-visibility pour le rendu différé du contenu hors écran

La propriété CSS content-visibility indique au navigateur d'ignorer le rendu du contenu hors écran jusqu'à ce que l'utilisateur défile à proximité. Cela réduit la quantité de travail de rendu pendant les interactions en limitant la portée du recalcul des styles et de la mise en page à la partie visible de la page.

/* Apply content-visibility to sections below the fold */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

/* Apply to individual items in long lists */
.list-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 80px;
}

La propriété contain-intrinsic-size fournit une hauteur estimée afin que le navigateur puisse calculer correctement la taille de la barre de défilement sans rendre le contenu. Cela empêche les décalages de mise en page lorsque l'utilisateur défile et que le contenu devient visible.

Pour plus de stratégies d'optimisation CSS qui réduisent le coût de rendu, consultez notre guide sur la suppression du CSS inutilisé.

Minimiser le travail de mise en page déclenché par les interactions

Lors de la conception des interactions, préférez les propriétés CSS qui ne déclenchent pas de mise en page. Les propriétés comme transform et opacity peuvent être gérées par le compositeur GPU sans déclencher de mise en page ou de peinture. Au lieu d'animer top, left, width ou height, utilisez transform: translate() et transform: scale(). Pour la liste complète des propriétés CSS qui déclenchent la mise en page, consultez le guide de performance de rendu web.dev.

Utilisez la propriété CSS will-change pour indiquer au navigateur qu'un élément sera animé. Cela permet au navigateur de créer une couche de compositeur séparée pour l'élément, isolant son rendu du reste de la page :

/* Promote elements to their own compositor layer */
.animated-element {
  will-change: transform, opacity;
}

/* Toggle visibility with opacity instead of display */
.modal {
  opacity: 0;
  pointer-events: none;
  transform: translateY(10px);
  transition: opacity 0.2s, transform 0.2s;
}

.modal.active {
  opacity: 1;
  pointer-events: auto;
  transform: translateY(0);
}

Identifier les longs presentation delays

Pour identifier les longs presentation delays, vous pouvez utiliser le profiler de performance de Chrome. Ouvrez DevTools (Ctrl+Shift+I), accédez à l'onglet Performance, lancez l'enregistrement et interagissez avec la page.

Vous pouvez ensuite analyser la chronologie d'une interaction et visualiser les différentes phases, y compris le presentation delay. En examinant les mises à jour de rendu qui se produisent après la fin des gestionnaires d'événements, vous pouvez identifier les goulots d'étranglement contribuant à un long presentation delay. Recherchez les entrées volumineuses "Recalculate Style", "Layout" et "Paint" dans la chronologie. Elles représentent le travail que le navigateur effectue pendant la phase de presentation delay.

Identifier le presentation delay avec les données RUM

Mesurer le presentation delay avec les Long Animation Frames (LoAF)

L'API Long Animation Frames (LoAF) montre exactement ce qui cause les retards de rendu pendant les interactions utilisateur. L'API vous fournit des données de timing pour séparer le processing time du presentation delay et identifier précisément quels scripts ralentissent le rendu.

Les propriétés clés de LoAF pour comprendre le presentation delay sont :

• renderStart : quand le navigateur a commencé la phase de rendu (recalcul des styles, mise en page, peinture)
• styleAndLayoutStart : quand le calcul des styles et de la mise en page a commencé
• duration : durée totale du long animation frame
• blockingDuration : quelle part de la trame a été bloquée par les scripts

LoAF est actuellement uniquement disponible sur Chromium (Chrome 123+). Pour les autres navigateurs, utilisez les traces du panneau Performance de Chrome DevTools pour analyser le travail de rendu.

La différence entre la fin de l'exécution du script et la fin de la trame représente le coût pur de rendu, qui est le presentation delay. Voici comment observer et enregistrer ces données :

// Measure presentation delay using LoAF API
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) {
      const scriptEnd = Math.max(
        ...entry.scripts.map(s => s.startTime + s.duration)
      );
      const presentationDelay = (
        entry.startTime + entry.duration
      ) - Math.max(scriptEnd, entry.renderStart);

      console.log('Presentation delay breakdown:', {
        totalDuration: entry.duration,
        renderStart: entry.renderStart,
        styleAndLayoutStart: entry.styleAndLayoutStart,
        estimatedPresentationDelay: presentationDelay,
        scriptCount: entry.scripts.length
      });
    }
  }
});

observer.observe({
  type: 'long-animation-frame',
  buffered: true
});

Les outils RUM comme CoreDash intègrent les données LoAF et vous montrent quels scripts et changements DOM causent les retards de rendu, avec une attribution complète des scripts.

Explorer les autres phases de l'INP

Pour maîtriser votre INP, abordez également les deux autres phases :

• Input Delay : Minimisez le temps d'attente avant que les gestionnaires d'événements ne commencent à s'exécuter. L'input delay est généralement la phase la plus petite mais augmente pendant le démarrage de la page lorsque le thread principal est occupé.
• Processing Time : Optimisez le code du gestionnaire d'événements qui s'exécute pendant l'interaction. Sur la plupart des pages, c'est là que la majorité de vos efforts d'optimisation porte ses fruits.

Pour un flux de travail de diagnostic complet, consultez notre guide sur comment trouver et corriger les problèmes d'INP. Pour des stratégies d'optimisation de rendu supplémentaires, explorez nos guides sur corriger une taille excessive du DOM et supprimer le CSS inutilisé. Retournez à la page hub INP pour l'aperçu complet.