Interaction to Next Paint (INP) : ce que c'est, comment le mesurer et l'améliorer

Interaction to Next Paint (INP) est une Core Web Vital qui mesure la rapidité avec laquelle une page web répond aux interactions utilisateur telles que les clics, les appuis et les pressions de touches. L'INP capture la latence totale depuis l'entrée utilisateur en passant par le traitement JavaScript jusqu'à la mise à jour visuelle finale à l'écran. Un bon score INP est de 200 millisecondes ou moins au 75e percentile. L'INP a remplacé le First Input Delay (FID) comme Core Web Vital en mars 2024.

Qu'est-ce que l'Interaction to Next Paint (INP) ?

Interaction to Next Paint (INP) est une métrique Core Web Vital qui mesure la réactivité d'une page web tout au long de la visite de l'utilisateur. Contrairement à son prédécesseur First Input Delay (FID), qui ne mesurait que le délai avant le début du gestionnaire d'événements de la première interaction, l'INP évalue chaque interaction qu'un utilisateur effectue avec la page et rapporte une valeur unique qui représente la réactivité globale de la page.

Chaque fois qu'un utilisateur clique sur un bouton, appuie sur un lien, presse une touche du clavier ou interagit avec un contrôle personnalisé, le navigateur mesure le temps total entre le moment de l'entrée et le moment où le prochain frame est affiché à l'écran. L'INP sélectionne l'une des interactions les plus lentes comme score de réactivité de la page. Pour les pages avec moins de 50 interactions totales, l'INP rapporte la pire interaction. Pour les pages avec de nombreuses interactions, l'INP utilise généralement le 98e percentile pour filtrer les valeurs aberrantes occasionnelles.

Un INP bas signifie que la page répond de manière fiable aux entrées utilisateur en temps opportun. Un INP élevé signifie que la page semble lente, non réactive ou « saccadée » car le navigateur ne peut pas traiter les interactions et mettre à jour l'écran assez rapidement.

INP vs FID : ce qui a changé et pourquoi

L'INP a officiellement remplacé le First Input Delay (FID) comme Core Web Vital en mars 2024. Google a retiré le FID car il avait deux limitations fondamentales qui en faisaient une mesure incomplète de la réactivité des pages.

Premièrement, le FID ne mesurait que la première interaction sur une page. Si le premier clic d'un utilisateur était rapide mais que les interactions suivantes étaient lentes, le FID aurait rapporté un score acceptable malgré la mauvaise expérience. L'INP mesure toutes les interactions tout au long de la session, fournissant une image bien plus précise de la réactivité réelle.

Deuxièmement, le FID ne mesurait que la phase d'input delay, c'est-à-dire qu'il capturait le temps que le navigateur passait à attendre avant de commencer à traiter l'événement. Il ignorait complètement le temps passé à exécuter le code du gestionnaire d'événements (processing time) et le temps nécessaire pour afficher le résultat visuel à l'écran (presentation delay). L'INP capture les trois phases, donnant aux développeurs une vue complète de la latence d'interaction.

La transition du FID vers l'INP a provoqué une baisse d'environ 5 points de pourcentage des taux de réussite des Core Web Vitals sur mobile, selon le HTTP Archive 2025 Web Almanac. Cela s'est produit parce que de nombreux sites qui semblaient réactifs sous le FID avaient des interactions ultérieures lentes que l'INP capture désormais.

Quelles interactions l'INP mesure-t-il ?

L'INP ne mesure que les interactions impliquant une entrée utilisateur discrète que le navigateur peut observer via les gestionnaires d'événements. Comprendre quelles interactions comptent est essentiel pour un débogage et une optimisation précis.

Interactions qui comptent pour l'INP

• Clics de souris (y compris les clics sur les boutons, liens, cases à cocher et contrôles personnalisés)
• Appuis sur écrans tactiles (équivalent des clics sur appareils mobiles)
• Pressions de touches sur un clavier physique ou virtuel (y compris la saisie dans les champs de formulaire, l'appui sur Entrée, l'utilisation de raccourcis clavier)

Interactions qui NE comptent PAS pour l'INP

• Le défilement ne compte pas car il est géré par le thread du compositeur du navigateur et ne bloque généralement pas le thread principal
• Le survol (mouseover) ne compte pas car c'est un état continu du pointeur, pas une interaction utilisateur discrète
• Les gestes de glissement ne comptent pas, bien que le pointerdown initial qui commence un glissement puisse déclencher une entrée INP
• Les transitions et animations CSS qui se produisent sans entrée utilisateur ne sont pas des interactions

Une idée reçue courante est que le défilement affecte l'INP. Ce n'est pas le cas. Cependant, si votre page utilise un défilement basé sur JavaScript au lieu du défilement natif du navigateur, ces gestionnaires de défilement JavaScript peuvent déclencher des callbacks d'événements que le navigateur mesure comme des interactions. C'est l'une des raisons pour lesquelles le défilement CSS natif surpasse systématiquement le défilement JavaScript en termes de réactivité.

Les trois phases d'une interaction INP

Chaque interaction mesurée par l'INP se compose de trois phases séquentielles. La valeur totale de l'INP est la somme des trois. Comprendre chaque phase est crucial car la stratégie d'optimisation diffère pour chacune.

1. Input Delay

L'input delay est le temps entre le moment où l'utilisateur interagit avec la page et le moment où le navigateur commence à exécuter les gestionnaires d'événements associés. Ce délai se produit parce que le thread principal du navigateur peut être occupé par d'autres tâches, comme l'analyse de JavaScript, l'exécution de tâches précédemment planifiées ou le traitement d'autres callbacks d'événements.

L'input delay est particulièrement problématique pendant la phase de chargement de la page, lorsque de nombreux scripts sont analysés et exécutés simultanément. Les données CoreDash montrent que les interactions pendant la phase de chargement ont un INP p75 de 132ms, contre seulement 50ms pour les interactions après le chargement complet de la page. C'est une différence de 2,6x. Réduire la contention du thread principal pendant le démarrage de la page est l'un des moyens les plus efficaces d'améliorer l'INP.

À la médiane, l'input delay est la plus petite sous-partie de l'INP. Mais au 90e percentile, l'input delay devient le contributeur dominant car les tâches longues sur le thread principal peuvent retarder le traitement des événements de centaines de millisecondes. Le HTTP Archive 2025 Web Almanac a constaté que moins de 25% des sites web maintiennent la durée des tâches en dessous du seuil recommandé de 50ms.

2. Processing Time

Le processing time est le temps total que le navigateur passe à exécuter tous les callbacks des gestionnaires d'événements associés à l'interaction. Cela inclut tout JavaScript qui s'exécute en réponse à l'événement, de la validation de formulaire aux mises à jour d'état en passant par les appels de suivi analytique.

Le processing time représente une part importante de l'INP total. Si un gestionnaire d'événements effectue des opérations DOM coûteuses, fait des appels API synchrones ou exécute des boucles inefficaces, le processing time va gonfler. Un modèle courant qui gonfle le processing time est l'exécution de code non essentiel (comme des événements analytiques ou des callbacks de tags tiers) dans le même gestionnaire d'événements que la mise à jour visuelle critique.

3. Presentation Delay

Le presentation delay est le temps entre le moment où tous les gestionnaires d'événements ont fini de s'exécuter et le moment où le navigateur présente le prochain frame contenant la mise à jour visuelle. Cette phase comprend le recalcul des styles, le calcul de la mise en page, la peinture et la composition.

À la médiane, le presentation delay est la plus grande sous-partie de l'INP car chaque interaction nécessite au moins une passe de rendu. Les pages avec un DOM large ou profondément imbriqué prennent plus de temps pour recalculer les styles et effectuer la mise en page. Les applications monopage qui re-rendent de grands arbres de composants après des changements d'état sont particulièrement susceptibles d'avoir un presentation delay élevé.

Quels sont les bons et mauvais scores INP ?

Pour réussir l'évaluation des Core Web Vitals pour la métrique Interaction to Next Paint, le 75e percentile de toutes les interactions enregistrées sur le terrain doit rester en dessous de 200 millisecondes :

• Un INP inférieur ou égal à 200 millisecondes signifie que votre page a une bonne réactivité.
• Un INP entre 200 et 500 millisecondes signifie que la réactivité de votre page nécessite des améliorations.
• Un INP supérieur à 500 millisecondes signifie que votre page a une mauvaise réactivité.

Il est important de comprendre que l'INP utilise le 75e percentile, pas la moyenne. Cela signifie que 75% de vos utilisateurs réels doivent expérimenter des interactions plus rapides que 200ms. La méthodologie du 75e percentile garantit que la métrique reflète l'expérience des utilisateurs sur des appareils plus lents et des connexions plus faibles, pas seulement ceux avec du matériel haut de gamme.

Comment mesurer l'Interaction to Next Paint (INP)

L'Interaction to Next Paint ne peut être mesuré qu'avec des outils de terrain qui capturent les interactions réelles des utilisateurs. Contrairement aux métriques de laboratoire qui simulent un seul chargement de page, l'INP nécessite de vrais visiteurs qui cliquent, appuient et tapent sur vos pages. Il n'y a aucun moyen d'obtenir un score INP significatif à partir d'un test synthétique car l'INP dépend du comportement humain réel.

Obtenir les métriques INP officielles

Vous pouvez obtenir les métriques INP officielles depuis PageSpeed Insights ou le tableau de bord CrUX et Google BigQuery. PageSpeed Insights rapporte le score au 75e percentile basé sur les 28 derniers jours de données utilisateur Chrome. Google BigQuery fournit plus de contexte historique et permet des requêtes personnalisées sur l'ensemble du jeu de données CrUX.

Google Search Console rapporte également les problèmes d'INP dans la section Core Web Vitals, regroupant les URL affectées et signalant les pages nécessitant des améliorations ou ayant une mauvaise réactivité.

Suivre l'INP avec le Real User Monitoring

Bien que le jeu de données CrUX officiel soit la source définitive pour les scores Core Web Vitals, il est fortement anonymisé et ne prend pas en charge la surveillance en temps réel ou le filtrage détaillé. C'est pourquoi les professionnels de la performance web s'appuient sur des outils de Real User Monitoring (RUM) comme CoreDash pour obtenir des données INP pratiques en temps réel. Les outils RUM collectent les mesures INP de chaque chargement de page, les attribuent à des éléments spécifiques, des états de chargement et des types d'appareils, et vous permettent de diagnostiquer exactement quelles interactions causent des problèmes.

Mesurer l'INP pour la session en cours

La façon la plus simple de déboguer l'INP pendant le développement est via les Chrome DevTools. Ouvrez le panneau Performance et utilisez le mode « timespan » dans Lighthouse pour enregistrer les interactions et voir leur latence. Vous pouvez également utiliser l'extension Core Web Vitals Visualizer, qui superpose les scores INP sur la page lors de vos interactions.

Pour un débogage pratique, utilisez la bibliothèque JavaScript Web Vitals de Google pour enregistrer les interactions individuelles dans la console :

Enregistrer l'INP dans la console avec la bibliothèque JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Comment améliorer l'Interaction to Next Paint

Améliorer l'Interaction to Next Paint nécessite d'optimiser les trois phases : input delay, processing time et presentation delay. Votre page peut répondre instantanément à la plupart des interactions, mais si ne serait-ce qu'une interaction est lente, elle peut définir l'ensemble du score INP. C'est pourquoi une approche systématique est nécessaire.

Conseil PageSpeed : la plupart du temps, l'INP sera bien pire lorsqu'un utilisateur interagit avec la page pendant la phase de démarrage du chargement de la page. C'est pourquoi, lors du débogage de l'INP, il est logique d'enregistrer toutes les interactions ainsi que l'état de chargement de la page !

1. Minimiser l'Input Delay : empêcher les tâches longues sur le thread principal

Généralement, toute page est moins réactive pendant la phase de démarrage, lorsque la plupart du travail du thread principal se produit (analyse, décodage, rendu et scripting). Pour garder le thread principal aussi libre que possible :

• Supprimez le code inutilisé. Utilisez le tree shaking pour éliminer le code mort et le code splitting pour diviser votre bundle en plus petits morceaux qui se chargent à la demande. Auditez la couverture de votre code avec Chrome DevTools pour identifier les scripts qui se chargent mais ne s'exécutent jamais.
• Chargez le code non essentiel pendant le temps d'inactivité du navigateur. Avez-vous vraiment besoin d'un widget de chat pendant les 500 premières ms du chargement de la page ? Planifiez les scripts non critiques avec requestIdleCallback() pour qu'ils ne s'exécutent que lorsque le navigateur est inactif.
• Identifiez et réécrivez les scripts lents qui consomment des ressources CPU excessives. Utilisez le panneau Performance de Chrome pour trouver les scripts avec des temps d'exécution longs et ciblez-les pour l'optimisation.
• Gardez votre page facile à rendre. Évitez les DOM de grande taille, les images excessives, trop de vidéos et les animations CSS gourmandes en CPU.
• Utilisez async et defer sur les balises script pour empêcher JavaScript de bloquer l'analyseur HTML. Envisagez de différer le JavaScript non critique entièrement jusqu'à ce que la page soit devenue interactive.

Découper les tâches longues avec scheduler.yield()

JavaScript s'exécute sur le thread principal du navigateur en utilisant un modèle « exécuter jusqu'à la fin » : une fois qu'une tâche démarre, elle bloque le thread principal jusqu'à ce qu'elle se termine. Les tâches longues (plus de 50ms) empêchent le navigateur de répondre aux entrées utilisateur. L'API scheduler.yield() vous permet de créer explicitement des points de yield dans du code à longue exécution, donnant au navigateur l'opportunité de traiter les interactions utilisateur en attente avant de continuer.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Différer le travail non critique avec requestIdleCallback

Utilisez requestIdleCallback() pour planifier les tâches non essentielles (analytics, télémétrie, prefetching) lorsque le navigateur est inactif. Cela garde le thread principal libre pour les interactions utilisateur et réduit directement l'input delay.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Utiliser les écouteurs d'événements passifs

Pour les événements qui n'ont pas besoin d'appeler preventDefault(), marquez vos écouteurs d'événements comme passifs. Cela indique au navigateur qu'il n'a pas besoin d'attendre que votre gestionnaire décide s'il annule le comportement par défaut, permettant un défilement plus fluide et une réponse tactile plus rapide.

// Passive listener: browser does not wait for preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Minimiser le Processing Time : fournir un retour immédiat

Lorsqu'un visiteur effectue une action comme soumettre un formulaire ou ajouter un article au panier, n'attendez pas la confirmation côté serveur avant de mettre à jour l'interface. Fournissez un retour visuel immédiat (« Envoi de votre formulaire... », « Ajout de l'article au panier... ») puis complétez l'opération en arrière-plan.

De plus, faites un yield vers le thread principal dès que possible après la mise à jour visuelle critique. Comme JavaScript suit un modèle « exécuter jusqu'à la fin », il bloque le thread principal jusqu'à ce que tout le code dans le callback ait été exécuté. Vous pouvez créer manuellement un point de yield où le navigateur peut mettre à jour la mise en page, puis continuer à exécuter le code non critique restant.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Minimiser le Presentation Delay : garder les choses simples

Lorsque la page doit se mettre à jour après une interaction, le navigateur doit recalculer les styles, effectuer la mise en page, peindre les pixels modifiés et composer le résultat. La complexité et la taille de votre DOM déterminent directement la durée de ce travail de rendu.

Certains environnements SPA mal optimisés re-rendent beaucoup trop de contenu après chaque interaction. Par exemple, lors de la mise à jour d'un compteur, assurez-vous de mettre à jour uniquement l'élément compteur, pas l'arbre de composants entier.

Suivez ces deux règles d'or pour un rendu plus rapide :

1. Gardez le DOM petit et simple. Il est beaucoup plus facile pour un navigateur de rendre une page avec moins d'éléments DOM (nœuds HTML) qu'une page avec des structures DOM complexes et profondément imbriquées. Visez moins de 1 400 éléments DOM au total et évitez l'imbrication au-delà de 32 niveaux.
2. Utilisez content-visibility pour le rendu différé du contenu hors écran. La propriété CSS content-visibility: auto accélère le rendu initial en différant le rendu du contenu hors écran jusqu'à ce que l'utilisateur défile à proximité.

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

Déboguer l'INP avec l'API Long Animation Frames (LoAF)

L'API Long Animation Frames (LoAF) est un outil puissant pour diagnostiquer les problèmes d'INP. Elle fournit des informations détaillées sur les frames qui prennent plus de 50ms à rendre, y compris des données d'attribution de scripts qui vous indiquent exactement quels scripts contribuent aux interactions lentes.

Contrairement à l'ancienne API Long Tasks, la LoAF capture le temps de rendu en plus du temps d'exécution des scripts, ce qui la rend particulièrement utile pour diagnostiquer les problèmes de presentation delay. Les entrées LoAF incluent la durée du frame, la durée de blocage et un tableau d'entrées de scripts montrant l'URL source, le nom de la fonction et le temps d'exécution de chaque script qui s'est exécuté pendant le frame.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

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

Les outils RUM comme CoreDash intègrent automatiquement les données LoAF, corrélant les frames d'animation longs avec des interactions utilisateur spécifiques pour que vous puissiez identifier exactement quel script, sur quelle page, pour quel type d'interaction, cause vos pires scores INP.

INP et LCP : la connexion des tâches longues

Les tâches longues sur le thread principal affectent à la fois l'INP et le Largest Contentful Paint (LCP). Une tâche JavaScript qui bloque le thread principal pendant 200ms retarde le traitement des événements (aggravant l'INP) et retarde également le navigateur dans le rendu de l'élément LCP (aggravant le LCP). Lorsque vous optimisez votre thread principal en découpant les tâches longues, en différant le JavaScript non critique et en réduisant le temps d'exécution des scripts, vous améliorez les deux métriques simultanément.

Études de cas : améliorations de l'INP en production

redBus : 80 à 100% d'amélioration de la conversion mobile

redBus, l'une des plus grandes plateformes de billetterie de bus en ligne au monde, a investi dans l'optimisation des Core Web Vitals sur ses marchés mondiaux. Leur focus sur la réduction du temps d'exécution JavaScript et l'optimisation des gestionnaires d'événements a contribué à une amélioration de 80 à 100% des taux de conversion mobile sur leurs marchés mondiaux. Les améliorations ont été portées par une combinaison de réduction du temps de blocage du thread principal, d'optimisation du chargement des scripts tiers et d'implémentation du code splitting pour réduire la quantité de JavaScript analysé pendant le démarrage de la page.

Preply : INP de 250ms à 185ms, 200 000 $ par an d'économies SEO estimées

Preply, une plateforme de tutorat linguistique en ligne, a amélioré l'INP de sa page d'accueil d'environ 250ms à 185ms et l'INP de sa page de recherche d'environ 250ms à 175ms. L'équipe a obtenu ces gains en profilant leur application React, en identifiant et éliminant les re-rendus inutiles, et en différant les callbacks d'événements non critiques. Les scores améliorés des Core Web Vitals se sont corrélés avec des classements de recherche plus élevés, se traduisant par une valeur estimée de 200 000 $ par an en recherche organique.

Ce que montrent les données réelles sur l'INP

L'écart INP entre mobile et desktop

Les données CoreDash révèlent que l'INP mobile (131ms au p75) est 2,8 fois pire que l'INP desktop (48ms au p75). C'est le plus grand écart entre appareils de toutes les métriques Core Web Vital. Les appareils mobiles ont des processeurs plus lents, moins de mémoire et une latence réseau plus élevée, tous ces facteurs contribuant à des temps de blocage du thread principal plus longs et un traitement des événements plus lent. Sur desktop, 95,6% des interactions atteignent un « bon » score INP, tandis que sur mobile ce chiffre tombe à 88,0%. Les utilisateurs mobiles subissent également 5 fois plus d'événements INP « mauvais » (9,6% vs 1,9%).

Interactions clavier vs pointeur

Les données CoreDash montrent que les interactions clavier (75ms p75) sont 56% plus lentes que les interactions pointeur (49ms p75). Les événements clavier ont aussi significativement plus d'expériences mauvaises : 7,4% des interactions clavier résultent en un INP mauvais, contre seulement 1,4% pour les interactions pointeur. Cet écart est probablement dû au fait que les événements clavier, en particulier dans les champs de formulaire, déclenchent un traitement plus complexe comme la validation d'entrée, les suggestions d'autocomplétion et les mises à jour d'état.

Interactions pendant le chargement vs après le chargement

Les interactions qui se produisent pendant le chargement de la page ont un INP dramatiquement plus élevé que celles après le chargement complet. Les données CoreDash montrent que les interactions pendant la phase de « loading » ont un INP p75 de 132ms, contre seulement 50ms pour les interactions post-chargement. C'est une différence de 2,6 fois. Même les interactions pendant la phase « dom-content-loaded » (75ms) montrent un INP élevé car les scripts asynchrones et les sous-ressources sont encore en cours de traitement. Ces données soutiennent fortement la recommandation de différer le JavaScript non critique pour réduire la contention du thread principal pendant le démarrage de la page.

Taux de réussite globaux de l'INP

Selon le HTTP Archive 2025 Web Almanac, 77% de toutes les pages mobiles atteignent un « bon » score INP (contre 55% en 2022). Cependant, seulement 53% des 1 000 sites les plus visités réussissent l'INP. Les sites à fort trafic ont tendance à avoir du JavaScript plus complexe, plus de scripts tiers et des structures DOM plus élaborées, tous contribuant à une pire réactivité. Sur desktop, 97% des pages atteignent de bons scores INP, soulignant l'énorme fossé de performance mobile-desktop. Le Total Blocking Time médian dans les tests de laboratoire est de 67ms sur desktop mais de 1 209ms sur mobile.

Questions fréquemment posées

Guides associés

Cette page hub couvre les fondamentaux de l'Interaction to Next Paint. Pour des conseils approfondis sur des aspects spécifiques de l'optimisation INP, explorez ces articles dédiés :

• <strong>Trouver et corriger les problèmes INP</strong> : Une méthodologie de diagnostic étape par étape utilisant Search Console, les données RUM et Chrome DevTools pour identifier exactement quelles interactions causent vos pires scores INP.
• <strong>INP Input Delay</strong> : Couvre la première phase de l'INP. Apprenez comment les tâches longues sur le thread principal bloquent le traitement des événements et comment minimiser l'input delay avec la planification des tâches, le code splitting et les web workers.
• <strong>INP Processing Time</strong> : Couvre la deuxième phase de l'INP. Apprenez comment optimiser les callbacks des gestionnaires d'événements, prioriser le code critique, différer le travail non essentiel et utiliser les fonctionnalités de concurrence de React pour réduire le processing time.
• <strong>INP Presentation Delay</strong> : Couvre la troisième phase de l'INP. Apprenez comment la taille du DOM, le layout thrashing et le rendu côté client contribuent aux mises à jour visuelles lentes et comment réduire le presentation delay.

Vous pourriez également trouver ces guides d'optimisation PageSpeed utiles pour améliorer l'INP :

• Améliorer l'INP : abandonner le défilement JavaScript
• Async vs Defer : stratégies de chargement JavaScript
• 14 méthodes pour différer JavaScript
• Widget de chat avec des Core Web Vitals parfaites
• Correction : éviter une taille de DOM excessive