Un site e-commerce affiche un taux de rebond en hausse sur mobile, sans raison apparente côté contenu. On vérifie les fiches produits, les prix, les visuels. Tout semble correct. Le temps de réponse des interactions est en cause : chaque clic sur un filtre ou un bouton d’ajout au panier met trop longtemps à produire un retour visuel. Sans outil de mesure adapté, on chercherait la cause au mauvais endroit pendant des semaines.
INP : comprendre la métrique de réactivité des Core Web Vitals
Depuis le 12 mars 2024, Google a remplacé le First Input Delay (FID) par Interaction to Next Paint (INP) comme troisième métrique des Core Web Vitals, aux côtés du LCP et du CLS. Le changement n’est pas cosmétique : le FID ne mesurait que le délai de la toute première interaction. L’INP évalue la réactivité de toutes les interactions sur la page, au 75e percentile des visites réelles.
A lire en complément : Optimiser les images pour accélérer le chargement d'un site
Concrètement, un site pouvait obtenir un bon score FID tout en offrant une expérience dégradée après le premier clic. Un formulaire de recherche rapide à la première frappe mais lent à chaque filtrage passait entre les mailles. L’INP corrige cet angle mort en prenant en compte chaque tap, chaque scroll interactif, chaque ouverture de menu déroulant.
Pour diagnostiquer un mauvais INP, on ne peut pas se contenter de tests en laboratoire. Les outils de mesure synthétique (ceux qui simulent une visite dans un navigateur contrôlé) ne reproduisent pas la diversité des appareils réels. Il faut croiser avec des données terrain, celles collectées auprès d’utilisateurs réels via le Chrome User Experience Report ou des solutions de Real User Monitoring.
Lire également : Qu'est-ce qu'un site Web blockchain ?
Core Web Vitals sur mobile : l’écart de performance que l’on sous-estime
La plupart des tests de performance sont réalisés depuis un ordinateur de bureau connecté en fibre. Ces conditions masquent les problèmes que rencontrent les visiteurs sur smartphone.
En janvier 2026, environ 55 à 56 % des origines web atteignent les seuils « bons » sur les trois Core Web Vitals. Les sites mobiles restent en retrait d’environ 8 points par rapport au desktop, malgré une progression continue depuis 2021. Autrement dit, près de la moitié du web mobile ne satisfait pas les critères de Google.
Cette différence s’explique par plusieurs facteurs cumulés :
- Les processeurs des smartphones d’entrée et milieu de gamme peinent à exécuter du JavaScript lourd, ce qui dégrade directement le LCP et l’INP.
- Les connexions mobiles introduisent une latence réseau variable que les tests en wifi ne captent jamais.
- Les mises en page responsive mal optimisées provoquent des décalages de contenu (CLS) lors du chargement d’images ou de publicités insérées dynamiquement.
Tester uniquement en desktop revient à auditer un magasin en dehors des heures d’affluence. On a l’impression que tout fonctionne, mais l’expérience utilisateur réelle sur mobile reste dégradée.
Données de laboratoire et données terrain : savoir lire les deux
PageSpeed Insights affiche deux types de scores que beaucoup confondent. En haut de la page, les données de terrain proviennent du Chrome User Experience Report, agrégées sur 28 jours de navigation réelle. En dessous, le diagnostic de laboratoire provient d’une simulation Lighthouse dans un environnement contrôlé.
Un score Lighthouse de 90 ne garantit rien si les données de terrain affichent un INP « à améliorer ». L’inverse est aussi vrai : un score labo médiocre sur une page très riche en JavaScript peut coexister avec de bonnes métriques terrain si la majorité des visiteurs utilise des appareils performants.
Quand prioriser l’un ou l’autre
Les données de laboratoire sont utiles pour identifier des problèmes techniques précis : une image non compressée, un script bloquant le rendu, une police chargée de manière synchrone. On les utilise au moment du développement ou après une mise en production pour repérer des régressions.
Les données terrain guident les décisions stratégiques. Si le LCP terrain dépasse le seuil acceptable alors que le labo affiche un bon score, on sait que le problème vient de l’infrastructure (serveur lent, CDN mal configuré) ou du profil des visiteurs (appareils anciens, connexion lente). Ce diagnostic change radicalement le plan d’action.
Configurer un suivi de performance web sans se noyer dans les tableaux
Collecter des données, tout le monde peut le faire. La difficulté, c’est de ne suivre que ce qui déclenche une action. Surveiller 40 indicateurs sans seuil d’alerte, c’est du bruit.
On recommande de se concentrer sur trois métriques terrain et deux métriques business :
- LCP, INP et CLS comme indicateurs techniques, avec un seuil d’alerte calé sur les limites Google (« bon » / « à améliorer » / « mauvais »).
- Le taux de rebond par page et le taux de conversion par appareil comme indicateurs business, pour corréler une dégradation technique avec un impact réel sur les résultats.
- Un relevé hebdomadaire via la Search Console (rapport Core Web Vitals) suffit pour détecter une dérive. Un suivi quotidien n’a de sens que sur les sites à fort trafic ou après un déploiement majeur.
L’outil gratuit de Google (Search Console + PageSpeed Insights) couvre la majorité des besoins. Les solutions de Real User Monitoring payantes ajoutent de la granularité, notamment la segmentation par pays, par type d’appareil ou par parcours utilisateur. Mais un outil de monitoring ne vaut que par les actions qu’il déclenche : des tableaux de bord consultés sans plan de correction restent des données mortes.
Transformer un diagnostic en plan d’action
Un mauvais LCP pointe vers les images, le temps serveur ou le rendu CSS. Un mauvais INP cible le JavaScript exécuté pendant les interactions. Un mauvais CLS renvoie aux éléments insérés dynamiquement sans dimensions réservées.
Chaque métrique oriente vers une famille de corrections. C’est précisément ce qui rend les Core Web Vitals utiles en contexte opérationnel : ils réduisent le champ d’investigation au lieu de l’élargir.
Un audit de performance ne produit de valeur que s’il débouche sur des corrections priorisées. Mesurer le LCP, l’INP et le CLS sur données terrain, comparer mobile et desktop, puis traiter les problèmes par ordre d’impact sur le taux de conversion : cette séquence structure le passage du diagnostic technique à l’amélioration mesurable.
