Site lent : diagnostiquer et corriger les Core Web Vitals

Un prospect local n’attend pas que votre photo de chantier de huit mégaoctets se charge. Il revient aux résultats et appelle le concurrent. La vitesse n’est pas un concours de score : elle détermine si le visiteur voit le service, touche le bouton et envoie le formulaire sans que la page saute sous son doigt.

À retenir : commencez par les données réelles des utilisateurs, surtout sur mobile. Les trois Core Web Vitals actuels sont le LCP pour l’affichage principal, l’INP pour la réactivité et le CLS pour la stabilité. Corrigez les modèles et composants qui touchent plusieurs pages, puis mesurez à nouveau. Un score de laboratoire à 100 ne garantit ni une bonne expérience réelle ni un appel.

Les trois métriques en français simple

Google évalue les Core Web Vitals au 75e centile : au moins trois visites sur quatre doivent respecter le seuil pour que l’expérience soit considérée comme bonne.

Le FID a été remplacé par l’INP. Un audit qui présente encore le FID comme la métrique centrale actuelle n’est pas à jour.

Données terrain et test de laboratoire : ne les mélangez pas

Les données terrain

Elles viennent de visites réelles éligibles regroupées sur une période glissante. Vous les trouvez notamment dans le rapport Core Web Vitals de Search Console et dans PageSpeed Insights lorsqu’assez de données existent.

Elles répondent à la question : « Que vivent réellement les utilisateurs sur leurs appareils, connexions et pages ? »

Les données de laboratoire

Lighthouse et les diagnostics PageSpeed exécutent un test contrôlé à un instant donné. Ils détaillent les causes probables et permettent de reproduire une amélioration.

Ils répondent à la question : « Que se passe-t-il dans ce scénario de test et que faut-il corriger ? »

Un test ponctuel rapide n’annule pas un mois de mauvaise expérience terrain. Une mauvaise note de laboratoire n’établit pas non plus que chaque visiteur vit exactement le même délai.

La prochaine étape

Vous voulez savoir quoi corriger en priorité ?

AdWaves analyse votre site, votre fiche Google, vos contenus et vos demandes pour identifier les actions qui peuvent créer le plus de valeur.

Diagnostiquer la vitesse de mon site

Voir le détail de l’accompagnement

Étape 1 : mesurer les pages qui rapportent

Testez d’abord :

• accueil ;
• pages de services prioritaires ;
• pages de villes qui reçoivent du trafic ;
• contact et formulaire ;
• pages issues de campagnes ;
• modèles de réalisations ou d’articles.

Mesurez mobile avant ordinateur. Conservez URL, date, LCP, INP, CLS, données terrain disponibles, diagnostic de laboratoire et conversions observées.

Une page peu visitée n’a pas toujours assez de données propres ; les rapports peuvent regrouper des URLs similaires. Corrigez le modèle partagé.

Étape 2 : diagnostiquer un LCP trop lent

Le LCP correspond souvent à l’image principale, au titre ou à un grand bloc de contenu.

Causes fréquentes

• serveur lent à répondre ;
• image principale trop lourde ;
• image chargée tardivement par erreur ;
• CSS ou police qui bloque l’affichage ;
• bannière ou slider complexe ;
• ressource appelée depuis un service tiers ;
• rendu entièrement dépendant de JavaScript.

Corrections prioritaires

1. Réduire le temps de réponse serveur et activer une mise en cache adaptée.
2. Redimensionner l’image à sa taille d’affichage.
3. Utiliser un format moderne compatible et une compression visuelle contrôlée.
4. Donner la priorité à la ressource LCP ; ne pas lui appliquer un chargement paresseux inutile.
5. Réduire les feuilles de style et scripts bloquants.
6. Supprimer le slider si une image et une promesse suffisent.

L’image la plus importante ne doit pas arriver après un carrousel, trois polices et un outil de discussion.

Étape 3 : diagnostiquer un INP trop élevé

Un mauvais INP se manifeste par un menu qui s’ouvre tard, un bouton qui ignore le toucher ou un formulaire qui se fige.

Causes fréquentes

• trop de JavaScript exécuté sur le fil principal ;
• plugins qui chargent partout ;
• gestionnaires d’événements lourds ;
• rendu de longues listes ;
• calcul déclenché à chaque frappe ;
• scripts de suivi, chat, carte ou consentement mal intégrés.

Corrections prioritaires

• supprimer les scripts et plugins sans valeur ;
• charger les fonctions seulement sur les pages qui les utilisent ;
• découper les tâches longues ;
• simplifier menus, calculateurs et formulaires ;
• différer ce qui n’est pas nécessaire à la première interaction ;
• tester chaque outil tiers et son coût commercial réel.

Le widget installé « au cas où » consomme parfois plus de temps qu’il ne génère de demandes.

Étape 4 : diagnostiquer un CLS trop élevé

Un mauvais CLS fait bouger la page pendant la lecture. Le bouton d’appel descend au moment du toucher, une publicité pousse le formulaire ou une police change brutalement la largeur du texte.

Causes fréquentes

• images et vidéos sans dimensions réservées ;
• bannière cookies injectée sans espace ;
• police web qui modifie fortement la mise en page ;
• contenu ajouté au-dessus de ce qui est déjà visible ;
• animation de hauteur ou de position ;
• module d’avis qui arrive tard.

Corrections prioritaires

• définir largeur et hauteur des médias ;
• réserver l’espace des composants asynchrones ;
• stabiliser la bannière de consentement ;
• choisir une police de remplacement proche ;
• éviter d’insérer un bandeau au-dessus du contenu chargé ;
• animer avec des propriétés qui ne recalculent pas toute la mise en page.

Le plan de correction par rendement

Classez les actions selon impact × nombre de pages ÷ effort.

Corrigez d’abord le thème, l’en-tête, le pied de page et les composants partagés. Un seul changement peut améliorer cinquante URLs.

Ce qu’il faut vérifier au-delà des Core Web Vitals

• temps de réponse serveur ;
• poids total et nombre de requêtes ;
• cache navigateur et serveur ;
• compression ;
• erreurs réseau ;
• scripts tiers ;
• fonctionnement sur connexion mobile limitée ;
• accessibilité du menu et des formulaires ;
• clic d’appel et confirmation d’envoi ;
• stabilité après acceptation ou refus des cookies.

Les Core Web Vitals sont un cadre essentiel, pas la totalité de l’expérience.

Diagnostiquer par famille de ressources

Images et vidéos

Servez chaque image aux dimensions réellement affichées, avec plusieurs tailles lorsque l’écran varie. Comparez WebP et AVIF selon la compatibilité et la qualité obtenue. Le poids cible dépend du visuel ; contrôlez le rendu au lieu d’appliquer un chiffre universel.

Le chargement différé convient aux médias situés plus bas dans la page. Ne l’appliquez pas aveuglément à l’image LCP. Pour une vidéo, utilisez une miniature légère et chargez le lecteur après interaction lorsque l’usage le permet. Un GIF de démonstration très lourd gagne souvent à être converti en vidéo optimisée.

CSS, JavaScript et polices

Repérez les ressources qui bloquent le premier affichage et les tâches longues qui retardent le toucher. Supprimez le code inutilisé, découpez les fichiers lorsque ce découpage réduit réellement le chargement et limitez les variantes de polices.

La minification réduit la taille ; elle ne corrige pas un script inutile. Le chargement différé déplace l’exécution ; il ne rend pas une fonction lourde plus rapide. Mesurez après chaque changement.

Serveur, cache et réseau de diffusion

Mesurez le temps avant le premier octet sur plusieurs pages et à plusieurs moments. Vérifiez cache de page, cache objet si le CMS l’utilise, compression Brotli ou Gzip, version du langage, requêtes externes et distance réseau.

Un CDN aide surtout lorsque les visiteurs sont éloignés du serveur ou que les ressources statiques sont nombreuses. Il ne compense pas un serveur saturé ni une page générée par cinquante requêtes lentes.

Plugins, thème et base de données

Désactivez un composant uniquement sur un environnement de test, puis comparez. Recherchez les extensions qui chargent leurs fichiers sur toutes les pages, les options chargées automatiquement en excès, les requêtes répétées et les tâches planifiées qui monopolisent le serveur.

Nettoyer une base ne signifie pas supprimer des tables au hasard. Sauvegardez, identifiez leur propriétaire et mesurez le changement. La suppression d’un plugin sans traitement de ses données peut casser le site ou laisser le poids intact.

Services tiers

Cartes, vidéos, chat, gestion des avis, polices, publicité, consentement et suivi viennent d’autres serveurs. Listez leur poids et le moment où ils s’exécutent. Chargez-les seulement sur les pages qui en ont besoin et après consentement lorsque le cadre l’exige.

Chaque outil tiers doit répondre à une question commerciale. S’il ne produit aucune décision ni demande, son coût de performance devient difficile à défendre.

Optimiser ou refaire le site : décider avec des preuves

Une refonte n’est pas la première réponse à un mauvais score. Corrigez l’existant lorsque le thème, le CMS et l’hébergement permettent d’agir sur les composants responsables.

Envisagez une reconstruction lorsque :

• le thème empêche toute suppression de code inutile ;
• chaque correction est écrasée par l’outil propriétaire ;
• les extensions critiques ne sont plus maintenues ;
• le rendu dépend d’une architecture disproportionnée pour un site vitrine ;
• les formulaires, contenus et accès ne sont plus maîtrisés ;
• le coût cumulé des contournements dépasse celui d’une base propre.

Comparez deux scénarios chiffrés : corrections, risques, durée de vie et capacité de maintenance. Ne vendez pas une refonte pour compresser trois images. Ne conservez pas non plus un système bloqué uniquement parce qu’il est déjà payé.

Tester le site mobile en huit points

Le processus avant/après

1. Archiver les mesures initiales.
2. Identifier le composant ou modèle commun.
3. Modifier un groupe cohérent de causes.
4. Tester sur préproduction et appareils réels.
5. Déployer avec possibilité de retour.
6. Contrôler erreurs, appels et formulaires.
7. Attendre le renouvellement des données terrain.
8. Valider la correction dans Search Console lorsque le rapport le propose.

La validation Search Console ne rend pas le code rapide. Elle demande à Google de réévaluer les URLs après correction.

Les fausses bonnes idées

Installer un plugin de cache sans diagnostic

Il peut aider, ne rien changer ou casser les formulaires. Le cache ne réduit pas une image démesurée ni un script exécuté au toucher.

Supprimer toutes les images

Les réalisations rassurent. Servez-les au bon format et à la bonne taille.

Poursuivre un score 100

Un site à 96 avec un téléphone visible et un formulaire fiable vaut davantage qu’un site à 100 qui ne qualifie aucune demande.

Tester uniquement la fibre du bureau

Vos prospects utilisent des téléphones moyens, parfois dans une zone mal couverte. Testez ce contexte.

Charger chaque outil de mesure sans gouvernance

Les scripts de suivi ont un coût. Gardez ceux qui produisent une décision et configurez-les proprement.

La méthode AdWaves

AdWaves mesure les modèles stratégiques, sépare terrain et laboratoire, identifie le goulot puis priorise selon l’impact sur les pages et les contacts. AdWaves contrôle ensuite l’appel, le formulaire et le suivi après chaque modification.

La vitesse rejoint l’offre, la structure et la fiche Google. Gagner une seconde ne sert à rien si la page ne dit pas ce que l’entreprise fait. Une page convaincante ne sert à rien si personne n’attend son affichage.

FAQ

Quel score PageSpeed faut-il atteindre ?

Il n’existe pas de score unique garantissant la réussite. Respectez les seuils terrain, corrigez les problèmes majeurs et vérifiez la conversion réelle.

Pourquoi PageSpeed change-t-il à chaque test ?

Le contexte de test, le serveur, le réseau et les services tiers varient. Comparez plusieurs exécutions et appuyez-vous sur les données terrain lorsqu’elles existent.

Un meilleur hébergement suffit-il ?

Il réduit le temps de réponse lorsqu’il constitue le goulot. Il ne corrige pas les images, scripts, polices ou composants instables du site.

Faut-il supprimer Google Maps de la page ?

Chargez la carte seulement lorsqu’elle aide le visiteur, après interaction si ce choix réduit le coût initial. Une carte lourde sur chaque page n’est pas une preuve locale.

Combien de temps pour voir l’amélioration dans Search Console ?

Les données terrain couvrent une période glissante et nécessitent assez de visites. Les tests de laboratoire montrent immédiatement le changement ; le rapport terrain se renouvelle progressivement.

Chaque seconde doit servir l’appel

AdWaves identifie les composants qui ralentissent vos pages, corrige les priorités et vérifie que le site reste rapide, clair et capable de générer des demandes.

Diagnostiquer la vitesse de mon site