Un matin, la boîte du gérant reçoit un message de Google Search Console : plusieurs URL sont classées « médiocre » sur mobile au titre des signaux web essentiels. Le site fonctionne pourtant très bien. Les pages s'affichent, le formulaire de contact envoie ses mails, la boutique encaisse. Personne dans l'entreprise ne sait ce que recouvrent les trois sigles listés dans le rapport, et le prestataire qui a livré le site ne répond plus depuis la mise en ligne.
Les Core Web Vitals, que Google traduit par signaux web essentiels, sont trois mesures qui décrivent ce que vit réellement un visiteur pendant le chargement d'une page. Elles ne jugent ni votre design, ni la qualité de vos textes, ni la pertinence de vos mots-clés. Elles décrivent trois moments précis : l'apparition du contenu principal, la réaction de la page au premier geste, et la stabilité de la mise en page pendant que tout se charge. Sur un WordPress dont le thème a été chargé de démos et dont la médiathèque n'a jamais été préparée, ces trois mesures échouent presque systématiquement sur téléphone.
Ce que ces mesures décrivent, et ce qu'elles ne couvrent pas
Une confusion revient dans presque tous nos audits : les Core Web Vitals ne sont pas un score de performance global. Elles ne remplacent pas l'analyse de votre indexation, elles ne détectent pas une page orpheline, et elles ignorent complètement le fait qu'un visiteur trouve ou non le bouton d'appel. Un site rapide dont la structure est mauvaise restera invisible dans les résultats de recherche, et ce chantier se traite à part.
Ce que ces mesures apportent, en revanche, est précieux : elles proviennent de vos visiteurs réels, sur leurs appareils réels, avec leur connexion réelle. Google agrège ces mesures collectées dans le navigateur Chrome et vous les restitue par groupe de pages. Vous ne discutez donc plus d'une impression de lenteur, vous lisez une distribution mesurée sur vos propres URL. C'est exactement ce dont nous avons besoin pour trancher entre un vrai problème technique et un souvenir de navigation malheureuse.
LCP : le temps que met votre contenu principal à s'afficher
Le LCP, pour Largest Contentful Paint, mesure le délai au bout duquel le plus grand élément visible de la page a fini de s'afficher. Sur une page d'accueil, cet élément est presque toujours la grande image de bandeau ou le premier bloc de titre. Google considère qu'un LCP inférieur à 2,5 secondes constitue une bonne expérience, et qu'au-delà de 4 secondes l'expérience devient mauvaise.
Les causes que nous rencontrons sont peu nombreuses et se traitent bien. Une photo de bandeau exportée en pleine résolution depuis un appareil photo pèse plusieurs mégaoctets et bloque tout le reste : nous la redimensionnons et la convertissons, ce que nous détaillons dans notre article sur le poids des images et le format WebP. Un carrousel qui charge cinq visuels avant d'en afficher un seul produit le même effet, et nous le remplaçons le plus souvent par une image fixe. Enfin, un serveur qui met une seconde et demie à renvoyer la première réponse consomme d'avance le budget disponible : un cache de pages correctement configuré règle ce point, comme nous l'expliquons à propos de WP Rocket et du cache WordPress.
INP : le délai entre le geste du visiteur et la réaction de la page
L'INP, pour Interaction to Next Paint, mesure le temps qui s'écoule entre le moment où le visiteur clique, tape ou appuie, et le moment où la page affiche visiblement une réponse. Google situe la bonne expérience sous 200 millisecondes. Cette mesure a remplacé l'ancien FID, qui ne regardait que la toute première interaction et laissait passer les blocages survenant plus tard dans la navigation.
Un mauvais INP traduit presque toujours un excès de JavaScript exécuté en même temps sur le fil principal du navigateur. Le coupable est rarement WordPress lui-même. Nous trouvons plutôt une bulle de chat tierce, deux outils de mesure d'audience installés en parallèle, un widget d'avis clients, et un constructeur de pages dont chaque section embarque ses propres scripts. Notre travail consiste à retarder le chargement de ce qui n'est pas nécessaire à l'affichage, à supprimer les doublons, et parfois à dire au dirigeant qu'un widget qui n'a jamais généré un contact ne mérite pas de ralentir toutes ses pages. Un thème construit avec Elementor tient très correctement ces mesures quand il reste raisonnable : le problème vient rarement du constructeur lui-même, il vient des quinze démos importées et jamais nettoyées.
CLS : les blocs qui se déplacent pendant que la page se charge
Le CLS, pour Cumulative Layout Shift, cumule les déplacements imprévus d'éléments déjà visibles. Il ne s'exprime pas en secondes mais en score, et Google attend une valeur inférieure à 0,1. Le scénario est familier : le visiteur pose son pouce sur le bouton « Envoyer », une police d'écriture finit de se charger, le texte se recompose, un encart apparaît au-dessus du formulaire, et le doigt tombe à côté. Personne ne se plaint de ce défaut, les gens abandonnent simplement.
Les corrections sont mécaniques. Chaque image doit déclarer sa largeur et sa hauteur pour que le navigateur réserve la place avant même de la télécharger. Les polices doivent être chargées localement et limitées à deux familles, avec une règle d'affichage qui évite le remplacement brutal du texte. Les bandeaux de consentement, les messages d'alerte et les encarts promotionnels doivent occuper un espace réservé au lieu de pousser le contenu vers le bas. Ce sont des ajustements de code et de gabarit, pas un plugin à installer.
Où lire vos chiffres sans vous tromper d'outil
Deux sources coexistent et servent à des choses différentes. Search Console vous donne le terrain, c'est-à-dire ce que vos visiteurs ont réellement vécu sur les vingt-huit derniers jours, regroupé par type de page. C'est la source qui compte pour savoir si vous avez un problème, et nous insistons sur la nécessité de posséder cet accès en votre nom dans notre article sur Search Console pour une PME. Lighthouse et PageSpeed Insights vous donnent le laboratoire, c'est-à-dire une simulation exécutée à l'instant sur une seule URL. C'est la source qui compte pour diagnostiquer et pour vérifier une correction, mais la note qu'elle affiche n'est pas une note d'expérience réelle, un point que nous développons à propos du score PageSpeed.
Concrètement, une page peut afficher un score de laboratoire moyen tout en présentant d'excellents chiffres de terrain, parce que vos visiteurs sont majoritairement en fibre sur un téléphone récent. L'inverse arrive aussi, et c'est plus grave.
Notre séquence de correction sur un WordPress existant
Nous commençons par lire votre rapport Search Console avec vous, en mobile d'abord, pour identifier quel groupe de pages échoue et sur quelle mesure. Nous passons ensuite les URL représentatives dans Lighthouse afin de nommer les causes : quelle image pèse sur le LCP, quel script bloque l'INP, quel bloc provoque le CLS. Nous corrigeons dans cet ordre, du gain le plus large au réglage le plus fin, puis nous remesurons. Les chiffres de terrain, eux, mettent quelques semaines à bouger, puisqu'ils reposent sur une fenêtre glissante de visites réelles.
Ce suivi entre dans la maintenance WordPress à 500 HT / an, avec un relevé Lighthouse desktop et mobile dans le rapport mensuel : une mise à jour de thème qui dégrade la stabilité visuelle se voit le mois suivant, et non l'année suivante. Sur un site que nous créons dès 900 HT, ces réglages sont posés d'emblée. Nous intervenons à distance dans toute la France et en Suisse, avec le même montant hors taxes en euros et en francs.
Retenez l'essentiel : trois mesures, trois causes dominantes, et aucune obligation de comprendre les sigles pour exiger un résultat. Vous devez pouvoir ouvrir votre site sur votre téléphone, voir la page apparaître sans attendre, cliquer sans que rien ne bouge. Si ce n'est pas le cas aujourd'hui, envoyez-nous l'adresse de votre site : nous vous rendons la liste des causes réelles et le gain attendu pour chacune.