0,31 : c’est le score CLS relevé par PageSpeed Insights sur la page d’un formulaire de devis en ligne, largement au-dessus du seuil de 0,1 recommandé pour un bon score Core Web Vitals. Le formulaire fonctionnait pourtant sans erreur visible, et personne dans l’équipe n’avait signalé de bug d’affichage.
Le diagnostic a commencé par un enregistrement vidéo du chargement de la page en simulant une connexion 4G ralentie. La vidéo montrait clairement le problème : un champ de résultat apparaissait brutalement sous les champs de saisie, quelques centaines de millisecondes après le rendu initial, poussant tout le contenu situé en dessous.
Le mécanisme en cause
Le formulaire de devis, construit avec Formidable Forms, comportait un champ calculé configuré pour afficher un total en fonction de plusieurs sélections (surface, matériaux, options). Ce type de champ repose sur un calcul exécuté côté client une fois le DOM du formulaire entièrement chargé et les scripts de Formidable initialisés.
Tant que ce calcul n’a pas tourné, le champ calculé reste vide ou masqué selon la configuration retenue. Une fois le script exécuté, la valeur s’affiche et le champ prend sa hauteur définitive, ce qui pousse visuellement tout ce qui suit dans le flux de la page. C’est exactement la définition d’un Cumulative Layout Shift : un déplacement de contenu déjà visible, après le rendu initial.
Pourquoi ce n’était pas visible en navigation normale
Sur une connexion rapide et un ordinateur de bureau puissant, le calcul s’exécutait si vite que le décalage passait sous le seuil de perception humaine, même s’il restait techniquement mesurable par les outils de Google. C’est un piège fréquent avec le CLS : le défaut existe indépendamment de la vitesse de la machine qui le mesure, mais son impact perçu varie énormément selon le contexte réel de navigation.
Le correctif retenu
Plutôt que de tenter de désactiver le calcul JavaScript, ce qui aurait supprimé une fonctionnalité utile aux visiteurs, le choix s’est porté sur une réservation d’espace. Le conteneur du champ calculé a reçu une hauteur minimale fixe correspondant à sa taille une fois rempli, ainsi qu’un état de chargement visuellement neutre affiché avant l’exécution du calcul.
.frm_calc_field_container {
min-height: 3.25rem;
display: flex;
align-items: center;
}
.frm_calc_field_container:empty::before {
content: "Calcul en cours…";
color: #6b7280;
font-size: 0.875rem;
}
Cette approche garantit que l’espace occupé par le champ ne change jamais de dimension entre l’état initial et l’état final, quelle que soit la vitesse d’exécution du script de calcul. Le contenu situé en dessous ne bouge donc plus, quel que soit le moment où le calcul se termine.
Résultat mesuré après correctif
Après déploiement, le score CLS de la page est retombé à 0,03 sur les mesures de terrain collectées via le rapport d’expérience utilisateur Chrome, soit une baisse largement suffisante pour repasser dans la zone verte des Core Web Vitals sur cette page précise.
- Avant correctif : CLS à 0,31, dans la zone rouge
- Après réservation d’espace : CLS à 0,03, dans la zone verte
- Aucun changement de comportement fonctionnel pour l’utilisateur final
Prévention pour les prochains formulaires
Le vrai enseignement de ce cas ne tient pas au correctif lui-même, assez simple une fois le diagnostic posé, mais à l’absence de test systématique du CLS sur les formulaires publiés. Un contrôle Lighthouse en local, avant chaque mise en ligne de formulaire comportant des champs calculés, aurait détecté le problème avant qu’il n’affecte des visiteurs réels pendant plusieurs semaines.
Tout champ dont le contenu dépend d’un script exécuté après le rendu mérite une hauteur réservée par défaut. C’est une règle simple, systématique, qui coûte quelques lignes de CSS et évite des semaines de score dégradé.
En résumé
Un calcul JavaScript exécuté après le rendu initial d’un formulaire est une source de décalage visuel fréquente et souvent invisible en navigation normale sur un poste rapide. La réservation d’espace via une hauteur minimale reste le correctif le plus fiable, sans toucher à la logique métier du formulaire. Ajouter un test CLS systématique avant mise en ligne, sur un profil de connexion ralentie, aurait permis de détecter ce problème avant qu’il n’atteigne les visiteurs du formulaire de devis.
