Une page de destination rapide à charger peut contenir un formulaire lent à réagir. L’INP mesure la réactivité de toute la page ; le formulaire peut expliquer une mauvaise valeur.
Commencez par votre compte Google Ads et sa répartition par appareil : clics, dépenses, demandes reçues et leur qualité. Les mesures de vraies visites se lisent ensuite séparément, sur mobile et sur ordinateur. Certains appareils ont moins de puissance, mais seules vos mesures montrent si votre page en souffre.
Afficher vite ou répondre vite : deux mesures
Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus grand élément visible, par exemple une image ou un bloc de texte. L’INP mesure autre chose : le délai de réponse après une action du visiteur. Une page peut donc s’afficher vite, puis répondre lentement à une saisie ou à un clic. L’inverse est aussi possible.
PageSpeed Insights affiche les données de terrain, mesurées sur de vraies visites dans Chrome. Elles n’apparaissent que si la page ou le site en compte assez. L’outil ajoute un test de laboratoire, qui simule une seule visite. Search Console, elle, regroupe les pages semblables et ne montre que des données de terrain.
Les deux outils affichent aussi le LCP et la stabilité visuelle : lisez les trois Core Web Vitals ensemble, avec la même méthode de diagnostic.
Où se perd le temps après un clic
Le fil principal, première piste à vérifier
Le navigateur exécute l’essentiel du travail d’une page sur un seul fil principal. C’est là que tournent les scripts qui réagissent aux clics, le calcul de la mise en forme et une partie de l’affichage. Quand un long script occupe ce fil, la réponse au visiteur attend son tour.
Cette piste est fréquente, mais seule une trace du navigateur la confirme, car d’autres processus interviennent aussi. Un script du site, une bibliothèque ou l’ouverture d’une fenêtre peut ralentir une interaction.
Les balises de mesure installées sur le site peuvent aussi ajouter du travail. Qu’elles soient chargées ne prouve pas qu’elles ralentissent le formulaire. Avant d’en retirer une, faites mesurer son temps d’exécution : cela aide à mesurer l’impact des scripts tiers avant de tester une correction.
Le cache et un réseau de diffusion de contenu accélèrent surtout l’affichage : mettre un site en cache ne corrige pas directement un script lent. Un site construit dans le navigateur peut au contraire ajouter du travail après le chargement.
Les trois étapes d’une réponse
Chaque interaction se découpe en trois étapes. Leur durée varie selon l’action : une saisie, le passage à l’écran suivant du formulaire ou l’envoi.
| Étape | Ce qui se passe | Cause à vérifier |
|---|---|---|
| Délai d’entrée | L’attente avant que le script du clic démarre | Une tâche déjà en cours occupe le fil principal |
| Durée de traitement | L’exécution des scripts liés à l’action | Un contrôle des champs qui bloque tout, ou un calcul répété |
| Délai de présentation | Le temps jusqu’à l’affichage suivant | Une mise en forme ou une mise en page coûteuse |
Une requête asynchrone ne bloque pas le fil principal pendant l’attente du serveur, contrairement à une requête synchrone. En revanche, préparer les données ou lire une réponse volumineuse peut allonger le traitement. La trace doit donc séparer l’attente du réseau et le travail réel.
Le retour visuel du formulaire
Après les scripts, le navigateur peut recalculer la mise en forme, refaire la mise en page et redessiner l’écran. Le coût dépend de ce qui change dans le DOM, la structure de la page que le navigateur garde en mémoire. Sur un formulaire, les changements suivants sont à vérifier dans une trace, sans être forcément en cause :
- afficher plusieurs messages d’erreur, surtout s’ils changent la hauteur du formulaire ;
- faire apparaître une étape, dont le coût dépend de sa taille et de sa mise en forme ;
- remplacer le formulaire par un message de confirmation après la réponse du serveur.
Affichez d’abord un indicateur d’attente léger, puis le résultat du serveur. Le réglage content-visibility: auto permet au navigateur de ne pas dessiner une zone hors écran, sans la retirer de la page. Il ne remplace pas le masquage d’une étape inactive. Faites vérifier que la zone reste accessible au clavier, à la recherche dans la page et aux lecteurs d’écran. Si la page saute au défilement, contain-intrinsic-size réserve la place de la zone.
Mesurer l’INP de votre formulaire
PageSpeed Insights signale un problème possible, mais ses chiffres d’ensemble n’indiquent ni le champ, ni la tâche, ni la source du trafic.
- Mesurez vos vraies visites. La bibliothèque officielle
web-vitals, avec son moduleweb-vitals/attribution, renvoie le type d’interaction, l’élément touché et la durée de chaque étape. - Protégez les données. Une partie des visites suffit, sans jamais collecter le contenu saisi ni une donnée personnelle, et dans le respect du choix du visiteur sur les cookies.
- Reproduisez l’interaction. Le panneau Performance de Chrome sert à enregistrer un parcours réaliste, pendant le chargement puis une fois la page stable. Ralentir le processeur et le réseau permet de simuler un appareil moins puissant ou une connexion lente.
- Lisez la trace. On sélectionne l’interaction lente, on compare ses trois étapes, puis on remonte au script en cause dans le fil principal. L’étape lente oriente la recherche, mais elle ne désigne pas la cause.
Quel correctif pour quelle étape ?
- Si le délai d’entrée domine, regardez ce qui tournait juste avant le clic. Repérez les balises qui causent le blocage et différez le travail non urgent, sans casser le consentement ni la mesure.
- Si le traitement domine, commencez par supprimer le calcul inutile et garder en mémoire ce qui peut l’être. Le travail restant se découpe ensuite. Retarder un contrôle convient aux vérifications fréquentes et non urgentes, pas au retour visuel que le visiteur attend tout de suite.
- Si la présentation domine, limitez les changements du DOM et les recalculs de mise en forme, puis testez chacun sur l’interaction concernée.
- Ne confondez pas « asynchrone » et « rapide ». Un script qui attend une réponse du serveur peut quand même enchaîner un long calcul avant ou après cette attente.
Le balisage côté serveur fait passer la mesure par votre propre serveur. Il n’aide la page que s’il retire vraiment du code du navigateur, car une balise reste souvent nécessaire pour envoyer les événements. Il ne corrige donc ni un script lent, ni une mise en forme coûteuse, ni des changements excessifs du DOM.
Découper un long calcul
scheduler.yield() permet à un script de rendre la main au navigateur, puis de reprendre en priorité sur les tâches comparables, sans garantie absolue d’ordre. Le navigateur peut ainsi afficher un retour avant la fin du calcul, qui reste sur le fil principal. Au 18 septembre 2026, MDN classe encore cette fonction en disponibilité limitée. Faites donc détecter sa présence et prévoyez une solution de repli testée.
L’ancienne méthode setTimeout(fn, 0) rend aussi la main, mais la suite passe après les tâches en attente. La fonction scheduler.postTask(), elle aussi en disponibilité limitée, range les tâches selon trois niveaux de priorité. Elle ne garantit aucun délai d’affichage. Employez la priorité la plus haute avec parcimonie, puis mesurez de nouveau. La première correction reste de réduire le travail.
Déporter un calcul lourd
Un Web Worker exécute du JavaScript en parallèle du fil principal, sans accès direct à la page. Il est utile quand la trace montre un calcul lourd et répété, par exemple une expression régulière complexe ou l’analyse d’une grosse réponse. Les échanges avec la page ajoutent du travail, notamment quand les données doivent être copiées. Le formulaire peut devenir plus réactif même si le calcul total prend plus longtemps : mesurez les deux effets. Confirmez-le en laboratoire, puis sur vos vraies visites.
L’INP compte-t-il dans le niveau de qualité ?
Google note chaque mot clé de 1 à 10 selon la pertinence de l’annonce et de la page : c’est le niveau de qualité. Google le décrit comme un outil de diagnostic, non utilisé directement dans la mise aux enchères qui choisit les annonces affichées. Ses trois composantes sont le taux de clics attendu, la pertinence de l’annonce et l’expérience sur la page de destination.
Pour la page, les aides Google citent la pertinence, l’utilité et la facilité de navigation, au regard des attentes créées par l’annonce. Au 18 septembre 2026, aucune ne cite l’INP comme critère, et l’interface n’affiche aucune colonne INP.
Si vous pensez qu’un formulaire lent freine les demandes après le clic, testez cette hypothèse par appareil et par interaction, sur des périodes comparables. À dépense comparable, moins de demandes signifie un coût par demande plus élevé. Pour attribuer un effet à la correction, vérifiez aussi les enchères, la répartition du trafic, votre offre et la saison.
Vérifier l’effet sur vos demandes
Quand l’envoi du formulaire est la conversion principale que Google Ads compte et que les enchères utilisent, ce parcours mérite un suivi à part. Un envoi lent peut décourager des visiteurs, mais l’effet sur vos demandes n’est pas automatique. Faites mesurer ces événements, sans enregistrer le contenu des champs :
- les tentatives d’envoi, y compris quand le formulaire refuse la demande ;
- les erreurs affichées quand un champ est mal rempli ;
- les envois réussis, c’est-à-dire les demandes vraiment reçues ;
- les abandons visibles, quand le visiteur quitte le formulaire en cours.
Après la correction : deux résultats à suivre
Une fois le correctif en ligne, suivez séparément l’INP avec ses trois étapes, puis la part des visiteurs qui envoient le formulaire et la qualité des demandes. Un progrès technique ne devient un gain commercial que si vos chiffres le montrent.
