La page apparaît rapidement. Puis vous touchez le menu et rien ne semble se passer. Vous appuyez une seconde fois ; il s’ouvre enfin, avant de se refermer. Le chargement initial était rapide. L’expérience, elle, ne l’est pas.
Ce décalage explique pourquoi une bonne vitesse d’affichage ne suffit pas à juger un site. Le LCP, consacré à l’apparition du contenu principal, et l’INP, qui évalue la réactivité aux interactions, observent deux moments différents du parcours. Une page peut réussir le premier et décevoir le second.
Pour une équipe marketing, la conséquence est pratique : optimiser l’image d’ouverture ne résout pas forcément le bouton qui répond trop tard. Il faut tester ce que le visiteur fait après son arrivée, et pas seulement le temps nécessaire pour voir le haut de la page.
Ce que l’INP regarde après le chargement
Dans sa documentation web.dev, Google décrit l’Interaction to Next Paint comme une mesure de la réactivité au cours de la vie de la page. Elle s’intéresse au délai jusqu’au prochain affichage après les interactions concernées. Elle ne mesure pas à elle seule tout le temps nécessaire pour terminer une opération distante.
Autrement dit, un formulaire peut réagir visuellement tout de suite, puis attendre une réponse du serveur. L’utilisateur comprend alors qu’un traitement est en cours. À l’inverse, une interface qui ne donne aucun retour peut sembler bloquée, même si l’action finira par réussir.
Les repères documentés pour une bonne expérience sont un LCP de 2,5 secondes ou moins et un INP de 200 millisecondes ou moins, évalués au 75e percentile des expériences pertinentes, avec distinction entre mobile et ordinateur. Ces seuils ne constituent ni une promesse de vente supplémentaire ni une note globale de qualité éditoriale.
Ils ne sont pas interchangeables.
La bonne question n’est donc pas seulement « la page est-elle rapide ? », mais « répond-elle correctement quand une personne l’utilise ? ». Ce changement de perspective conduit à examiner les menus, les filtres, les formulaires et les éléments qui se chargent après l’ouverture.
Ouvrez une page importante sur mobile, puis effectuez un parcours réel : déployer le menu, appliquer un filtre, ajouter un produit ou remplir un formulaire. Continuez après quelques secondes. Certains scripts ne démarrent qu’après le chargement initial et peuvent modifier la réactivité plus tard.
N’en concluez pas qu’un délai observé provient forcément d’une extension précise. Le navigateur peut devoir exécuter beaucoup de JavaScript, recalculer une interface ou traiter des éléments simultanés. Le diagnostic technique doit identifier ce qui retarde réellement l’affichage avant de décider quoi retirer.
Un scénario de contrôle fictif peut suivre quatre actions : ouvrir le menu, changer une option, ajouter un article au panier et afficher les frais de livraison. Notez à chaque fois si l’interface donne un retour, si l’action réussit et si un second clic produit un doublon. Ce relevé décrit une expérience ; ce n’est pas une mesure normalisée de l’INP.
Les deux approches se complètent. La mesure aide à localiser une dégradation sur des usages réels ; le parcours permet de comprendre pourquoi elle gêne une personne. Une moyenne confortable peut masquer un bouton crucial qui fonctionne mal dans certaines conditions.
Lorsque des données de terrain sont disponibles, examinez leur périmètre. Un petit site ou une page peu visitée peut ne pas disposer d’un volume suffisant dans les rapports publics. L’absence de données ne prouve ni la rapidité ni la lenteur du site.
Ce qu’il faut demander au développeur
Demandez d’abord une reproduction du problème sur le parcours concerné. « Améliorer PageSpeed » est trop large ; « le filtre produit reste sans retour sur mobile pendant l’interaction » permet de chercher une cause précise. Ajoutez le type de page, l’appareil et les conditions observées.
La correction peut passer par une réduction du travail exécuté au mauvais moment, une simplification de l’interface ou un meilleur découpage des traitements. La solution dépend de la cause. Supprimer au hasard tous les services tiers peut casser des fonctions utiles sans corriger le délai principal.
Le retour visuel mérite aussi d’être pensé. Si une action exige une attente légitime, l’utilisateur doit comprendre son état et éviter de la répéter involontairement. Mais un indicateur de chargement ne doit pas servir à maquiller une réponse fonctionnelle défaillante : le résultat doit toujours être vérifié.
Après modification, rejouez les mêmes interactions et contrôlez les cas voisins. Un menu plus réactif ne doit pas devenir inaccessible au clavier ; un panier plus rapide ne doit pas oublier une option. La performance fait partie de la qualité du parcours, elle ne la remplace pas.
Enfin, gardez les deux indicateurs dans leur rôle. Un bon LCP rassure sur l’arrivée du contenu. Un bon INP renseigne sur la capacité à répondre aux interactions. Votre visiteur, lui, n’a pas à connaître ces sigles : il attend simplement que la page soit lisible, qu’un bouton réponde et que l’action annoncée aboutisse.
Pour éviter les discussions abstraites, conservez une courte liste de parcours à rejouer après chaque changement important du site. Elle peut tenir sur une page : action attendue, retour visible et résultat obtenu. Ce contrôle ne remplace pas les mesures techniques. Il permet de garder leur finalité en tête lorsque plusieurs prestataires travaillent sur la même interface.
