Pourquoi les Core Web Vitals restent-ils insuffisants après l’optimisation de la vitesse du site ?

Les images ont été compressées, le CDN a été intégré, et le score de test est passé du rouge au vert. Pourtant, dans Search Console, les Core Web Vitals affichent toujours « À améliorer ». Pour les responsables de sites e-commerce internationaux, cet écart peut facilement susciter des doutes : l’optimisation n’aurait-elle pas fonctionné ?

Pas nécessairement. La vitesse de chargement mesurée par les outils et l’expérience réelle des clients internationaux lorsqu’ils consultent, cliquent et voient les pages évoluer ne sont pas la même chose. Pour savoir comment optimiser la vitesse d’un site et atteindre les seuils des Core Web Vitals, il faut d’abord distinguer les méthodes de mesure, puis repérer les pages et les actions qui nuisent réellement à l’expérience.

Tout d’abord, vérifiez : s’agit-il d’un score de test ou de données d’utilisateurs réels ?

Le score de performance Lighthouse de PageSpeed Insights provient d’un test en laboratoire réalisé une fois dans des conditions simulées. Les données d’expérience utilisateur réelle affichées en haut de la page proviennent principalement du Chrome User Experience Report (CrUX). Ces deux sources ont des usages différents : un score élevé ne signifie pas nécessairement que les Core Web Vitals sont conformes.

Les Core Web Vitals reposent principalement sur trois indicateurs, généralement évalués selon le 75e percentile des données de visites réelles, et non selon la moyenne :

Les trois indicateurs doivent tous atteindre le niveau « Bon » pour que l’évaluation soit réussie. Vérifiez séparément les données sur mobile et sur ordinateur. Si les données de l’URL actuelle sont insuffisantes, vérifiez également si l’outil affiche les données de l’ensemble du site, afin de ne pas confondre les résultats du site entier avec ceux d’une seule page.

Par ailleurs, CrUX utilise des données glissantes sur les 28 derniers jours. Si vous déployez une correction aujourd’hui, les anciennes visites restent prises en compte dans les statistiques : le résultat ne passera pas immédiatement au vert. Search Console présente également un délai de mise à jour. Il vaut mieux suivre les tendances que modifier les paramètres à répétition toutes les quelques heures.

Analysez les problèmes indicateur par indicateur au lieu de continuer à compresser les ressources à l’aveugle

Dans PageSpeed Insights, vérifiez les indicateurs en échec, puis enregistrez la page concernée avec le panneau Performance des outils de développement Chrome. Ne testez pas uniquement la page d’accueil : les pages de détails des produits, les pages de catégorie et les pages de destination publicitaires sont souvent les véritables points d’entrée des clients internationaux.

LCP non conforme : l’image est plus légère, mais reste détectée trop tard

La grande image visible au-dessus de la ligne de flottaison est souvent l’élément LCP, mais son poids n’est pas nécessairement la cause du ralentissement. Une réponse lente du serveur, un trop grand nombre de redirections ou l’insertion de l’image seulement après l’exécution de JavaScript peuvent empêcher le navigateur d’en lancer rapidement le téléchargement.

Dans le panneau Network, vérifiez à quel moment la requête de cette ressource est lancée et, à l’aide de l’enregistrement des performances, distinguez le temps d’attente, de téléchargement et de rendu. Ne chargez pas en différé l’image clé visible au-dessus de la ligne de flottaison. Faites en sorte que le navigateur puisse la détecter dès le HTML initial et, si nécessaire, définissez une priorité de récupération élevée. N’envisagez le préchargement que si vous avez confirmé un retard dans la détection de la ressource, afin d’éviter de mobiliser excessivement la bande passante.

Les sites destinés aux marchés internationaux doivent également être testés depuis les marchés cibles. Un chargement rapide depuis le bureau de Pékin ne garantit pas la même rapidité pour un utilisateur mobile en Allemagne ou au Brésil. Vérifiez les taux de succès du cache CDN, le recours au serveur d’origine pour les pages dynamiques et les éventuels délais causés par les redirections multilingues.

INP non conforme : la page s’ouvre, mais le bouton ne « répond » pas

L’INP mesure la réactivité aux interactions pendant la visite d’une page et ne peut pas être évalué uniquement à partir d’un test de chargement ponctuel. Il faut tester concrètement des actions comme le filtrage des produits, le changement de spécifications, l’ouverture d’une fenêtre de demande de renseignements et l’ajout au panier.

Enregistrez les clics et vérifiez si des tâches longues occupent le thread principal. Parmi les causes courantes figurent le rendu simultané d’un grand nombre de produits, la validation complexe des formulaires, ainsi que l’exécution simultanée de scripts de chat, de suivi publicitaire et de cartes de chaleur. Pour y remédier, divisez les tâches longues, réduisez le JavaScript inutile ou chargez les fonctionnalités non essentielles au moment opportun.

Le temps de blocage total mesuré en laboratoire peut aider à localiser le problème, mais ne remplace pas l’INP réel. Supprimer les scripts marketing n’est pas la seule solution : il faut d’abord clarifier leur fonction et leurs conditions de déclenchement, afin d’éviter d’améliorer les performances tout en perdant l’attribution des demandes de renseignements.

CLS non conforme : le haut de page est stable, mais la mise en page se décale lors du défilement

En se concentrant uniquement sur les premières secondes après l’ouverture de la page, on risque de passer à côté des décalages de mise en page. Les bannières promotionnelles qui apparaissent tardivement, les modules de recommandation, le remplacement des polices et les vidéos dont les dimensions n’ont pas été réservées peuvent tous déplacer le contenu pendant la navigation.

Définissez les dimensions ou le rapport largeur/hauteur des images, des vidéos et des modules intégrés, et réservez de l’espace pour les contenus asynchrones. Sur les sites multilingues, vérifiez tout particulièrement les textes longs, le chargement des polices et les retours à la ligne des boutons : un modèle stable en chinois ne le sera pas forcément en allemand.

Pourquoi le rapport affiche-t-il encore un groupe de pages en échec après la correction d’une page ?

Search Console regroupe les URL dont l’expérience est similaire. Corriger une page produit ne signifie pas que toutes les pages du même groupe se sont améliorées : certaines peuvent encore utiliser un ancien modèle, une image principale plus volumineuse ou des composants tiers supplémentaires.

Il est conseillé d’établir une liste de contrôle selon la combinaison « modèle × langue × appareil », de sélectionner des pages représentatives pour chaque catégorie et d’inclure les principales pages d’entrée à fort trafic ainsi que celles qui rencontrent le plus de problèmes. Pour les sites marketing tournés vers l’international, vérifiez aussi séparément les pages de destination comportant des paramètres publicitaires : assurez-vous que ces paramètres n’affectent pas le cache et que les entrées issues des publicités ne déclenchent pas de scripts supplémentaires.

Les plateformes comme Yiyingbao, qui proposent des services de création de sites intelligents et de marketing international, permettent d’examiner ensemble les modèles, les scripts et les points d’entrée des campagnes, plutôt que de demander aux responsables marketing de compresser les images une à une. Dans le cadre de la collaboration, il convient de distinguer clairement les problèmes liés au modèle utilisé sur l’ensemble du site de ceux qui ne surviennent que sur certaines pages marketing.

Évaluez les résultats par des tests de vérification, au lieu d’attendre simplement que tout passe au vert

Consignez pour chaque modification la date de mise en production, les pages concernées et les indicateurs visés. Après le déploiement, commencez par vérifier, au moyen d’un test en laboratoire réalisé dans des conditions identiques, si le problème a disparu. Observez ensuite les changements par région, appareil et type de page grâce à la surveillance des utilisateurs réels. Si le trafic est faible, ne tirez pas de conclusions à partir d’un petit nombre de visites.

Après avoir confirmé que la correction couvre les pages concernées, vous pouvez lancer une validation dans Search Console et continuer à suivre les données glissantes. Effectuez également des tests de régression sur l’envoi des demandes de renseignements, le paiement, les conversions publicitaires et la gestion du consentement, afin d’éviter que le chargement différé des scripts ne perturbe les processus métier.

Lorsque les Core Web Vitals ne sont pas conformes, le problème ne vient généralement pas de l’absence d’un plugin supplémentaire d’accélération, mais d’un décalage entre les méthodes de mesure, les modèles de page et les conditions d’utilisation réelles. En identifiant d’abord l’indicateur en échec, puis en corrigeant le goulet d’étranglement correspondant, vous transformerez l’accélération : d’une belle capture d’écran de test, elle deviendra une expérience réellement fluide pour vos clients internationaux.