# Chute de position après l’installation d’un formulaire de devis lourd > Symptôme lié à un script bloquant ajouté par défaut sur une page de contact, diagnostic via l'onglet Performance du navigateur, correctif de chargement différé. - Auteur : Clément Hadrot - Publié le : 2025-09-27 - Mis à jour le : 2025-09-27 - Catégorie : SEO & GEO - URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/chute-position-formulaire-devis-lourd/ ## L’essentiel - Un script de formulaire peut bloquer le thread principal plusieurs centaines de millisecondes - L'onglet Performance du navigateur localise précisément la tâche fautive - Le chargement différé au premier clic règle le problème sans retirer le formulaire Une position qui recule de la troisième à la dixième place sur la requête principale d'une page de devis, en l'espace de deux semaines, sans aucune modification de contenu : c'est le constat de départ qui a déclenché ce diagnostic. Le seul changement identifié sur la période concernée était l'installation d'une extension de formulaire avancé, remplaçant un simple formulaire de contact par un configurateur de devis à plusieurs étapes. Le contenu de la page n'avait pas bougé d'une ligne. La suite de l'investigation s'est donc concentrée entièrement sur ce que ce nouveau formulaire avait changé côté performance, puisque c'était la seule variable ayant évolué au moment de la baisse. ## Symptôme : un score d'interactivité qui s'effondre Le rapport d'expérience de la page dans la Search Console signalait un net dégradement de l'INP (Interaction to Next Paint), l'indicateur de réactivité qui a remplacé le FID comme Core Web Vital officiel en mars 2024. Sur les pages équipées du nouveau formulaire, l'INP mesuré sur le terrain dépassait régulièrement les 500 millisecondes, loin du seuil de 200 millisecondes considéré comme un bon score. Ce type de dégradation, propre à une catégorie de pages précise, correspond exactement au profil d'un script qui monopolise le thread principal au chargement, empêchant le navigateur de répondre rapidement à la première interaction de l'utilisateur, qu'il s'agisse d'un clic ou d'un défilement. ## Diagnostic à l'aide de l'onglet Performance > L'essentiel à retenir : Un script de formulaire peut bloquer le thread principal plusieurs centaines de millisecondes ; L'onglet Performance du navigateur localise précisément la tâche fautive ; Le chargement différé au premier clic règle le problème sans retirer le formulaire L'onglet Performance des outils de développement du navigateur permet d'enregistrer le chargement complet d'une page et de visualiser, tâche par tâche, ce qui occupe le thread principal. Sur la page de devis, l'enregistrement a fait apparaître une tâche longue de plus de 600 millisecondes, exécutée immédiatement au chargement, avant même que l'utilisateur n'interagisse avec quoi que ce soit. En zoomant sur cette tâche dans la pile d'appels, l'origine est apparue clairement : un script chargé de façon synchrone par l'extension de formulaire, qui initialisait l'ensemble des étapes du configurateur de devis dès le chargement de la page, y compris les étapes que la majorité des visiteurs ne consulteraient jamais. ``` ``` ## Correctif : différer le chargement jusqu'à la première interaction Retirer purement et simplement le formulaire n'était pas une option, il constituait le principal canal de conversion de la page. Le correctif retenu a consisté à retarder le chargement du script d'initialisation jusqu'à la première interaction réelle de l'utilisateur avec la zone du formulaire, par exemple un survol ou un premier clic dans un champ. ``` document.querySelector('.devis-configurateur-wrapper').addEventListener('pointerenter', function initFormulaire() { const script = document.createElement('script'); script.src = '/wp-content/plugins/devis-configurateur/assets/init.js'; document.body.appendChild(script); this.removeEventListener('pointerenter', initFormulaire); }, { once: true }); ``` Le formulaire s'affiche toujours immédiatement dans son état statique, sans exécuter la logique JavaScript coûteuse tant que le visiteur ne montre pas d'intention réelle d'interagir avec lui. Sur les pages de contenu éditorial où le formulaire apparaît en bas de page, un déclenchement basé sur la visibilité à l'écran (`IntersectionObserver`) complète ce correctif pour les visiteurs qui font défiler la page sans jamais s'arrêter sur le formulaire. ## Résultat mesuré après correctif L'INP relevé sur le terrain est redescendu sous les 200 millisecondes en une dizaine de jours, le temps que le rapport d'expérience de la Search Console recalcule ses données agrégées sur vingt-huit jours glissants. Le repositionnement de la page a suivi avec un léger décalage, remontant progressivement vers sa position initiale sur trois semaines. ## Prévention pour les prochaines extensions de formulaire - Tester systématiquement l'onglet Performance avant et après l'installation de toute nouvelle extension touchant à un formulaire ou un configurateur. - Vérifier si l'extension propose une option native de chargement différé avant d'en écrire une soi-même. - Surveiller le rapport d'expérience de la Search Console dans les semaines suivant tout changement d'extension sur une page à fort trafic. - Limiter le chargement du script d'initialisation aux seules pages où le formulaire est réellement présent, plutôt qu'à l'ensemble du site via le thème. > Sur ce genre d'incident, la première question à se poser reste toujours : qu'est-ce qui a changé exactement, et à quelle date ? Une chute isolée à une catégorie de pages précise pointe presque toujours vers un changement technique récent plutôt que vers une évolution générale de l'algorithme. ## En résumé Un formulaire de devis peut dégrader silencieusement la réactivité perçue d'une page bien au-delà de son propre périmètre visuel, en monopolisant le thread principal dès le chargement. L'onglet Performance du navigateur permet de localiser précisément la tâche fautive, et un chargement différé jusqu'à la première interaction résout le problème sans sacrifier la fonctionnalité du formulaire.