Core Web Vitals : comprendre et accélérer votre site web

Votre site peut être magnifique et pourtant perdre des clients dans les trois premières secondes. Google mesure cette expérience avec trois chiffres appelés Core Web Vitals. Dans ce guide, vous allez comprendre ce que signifie chacun d'eux, comment les vérifier gratuitement et quoi corriger en priorité, sans avoir besoin de savoir coder.

La scène est familière : quelqu'un vous trouve sur Google Maps et touche le lien vers votre site depuis son téléphone, avec deux barres de réseau, en attendant à un feu rouge sur l'avenue Tulum. L'écran reste blanc, puis le menu apparaît, puis le texte saute parce qu'une énorme photo vient d'arriver, et quand la personne essaie enfin de toucher le bouton WhatsApp, la page met du temps à réagir. Cette personne est déjà partie. Elle ne s'est pas plainte, elle n'a pas laissé d'avis : elle est simplement revenue aux résultats et a touché le suivant.

Les Core Web Vitals donnent un nom et une mesure à ce moment-là. Ils traduisent en chiffres une question très concrète pour votre activité : votre site accueille-t-il bien les gens pressés ?

01Avant de commencer : ce qu'il vous faut

• L'adresse de votre site et, si possible, celle de vos trois pages les plus visitées (l'accueil, la page services ou menu et la page contact sont généralement les plus importantes).
• Un accès à Google Search Console si vous l'avez déjà configuré. Sinon, pas de souci : vous pouvez commencer sans.
• Un smartphone milieu de gamme. Tester votre site uniquement depuis l'ordinateur portable du bureau, branché à la fibre, est le moyen le plus rapide de vous tromper.

02Ce que mesurent les Core Web Vitals

Google regroupe trois métriques, et chacune correspond à une sensation différente chez le visiteur. D'après le guide officiel des Web Vitals sur web.dev, elles sont évaluées au 75e centile des visites réelles, en distinguant mobile et ordinateur. Autrement dit : votre site doit aussi bien se comporter avec quelqu'un qui a un téléphone modeste et un mauvais réseau.

1. LCP : le temps d'affichage de l'essentiel

LCP signifie Largest Contentful Paint. Il mesure le temps que met à s'afficher le plus grand élément de l'écran initial : presque toujours la photo principale, une vidéo de couverture ou un grand bloc de texte. C'est la réponse à « c'est chargé ? ».

Selon la documentation du LCP sur web.dev, un bon LCP est de 2,5 secondes ou moins ; entre 2,5 et 4 secondes, il doit être amélioré, et au-delà de 4 secondes, il est considéré comme mauvais.

Imaginez, par exemple, une boutique de maillots de bain à Playa del Carmen dont la page d'accueil s'ouvre sur une immense photo prise avec un appareil professionnel, sans compression. Le logo, le menu et les boutons arrivent en un instant, mais tant que la photo n'apparaît pas, le visiteur a l'impression que la page n'a pas chargé.

L'erreur classique consiste à tout mettre sur le dos de l'hébergement, alors que le problème vient souvent d'une seule image ou d'une vidéo d'arrière-plan.

2. INP : la réactivité quand vous touchez la page

INP signifie Interaction to Next Paint et a remplacé une ancienne métrique appelée FID. Il mesure le temps entre le moment où quelqu'un touche, clique ou tape au clavier et le moment où la page affiche une réaction visible. C'est la réponse à « est-ce qu'elle m'a écouté ? ».

Selon la documentation de l'INP sur web.dev, un INP de 200 millisecondes ou moins est bon ; entre 200 et 500 millisecondes, il doit être amélioré, et au-delà de 500 millisecondes, il est mauvais.

Pensez à un restaurant avec un menu digital où chaque catégorie s'ouvre d'un toucher. Si l'écran se fige quand on touche « Fruits de mer » avant d'afficher les plats, le client touche à nouveau et l'expérience paraît maladroite, même si la page s'est chargée vite. Ce retard vient souvent d'un excès de code exécuté en même temps, très souvent issu d'outils tiers : chats qui surgissent, bandeaux de cookies, pixels publicitaires, widgets d'avis.

L'erreur classique, ici, c'est d'installer « juste une extension de plus ». Chacune semble inoffensive ; ensemble, elles empêchent le navigateur de répondre à temps.

3. CLS : à quel point la page bouge pendant le chargement

CLS signifie Cumulative Layout Shift et mesure les sauts inattendus du contenu. C'est la réponse à « pourquoi tout a bougé au moment où j'allais toucher ? ».

La documentation du CLS sur web.dev considère comme bonne une valeur de 0,1 ou moins et comme mauvaise toute valeur supérieure à 0,25 ; entre les deux, il faut l'améliorer. On y trouve aussi les causes les plus fréquentes : images ou vidéos sans dimensions définies, publicités ou widgets qui changent de taille tout seuls, contenu inséré au-dessus de celui qui était déjà là, et typographies qui, une fois chargées, paraissent plus grandes ou plus petites que la police provisoire.

Par exemple, imaginez une clinique dentaire dont la page d'accueil affiche d'abord le texte « Prenez rendez-vous », puis, une demi-seconde plus tard, une bannière promotionnelle apparaît au-dessus et pousse tout vers le bas. La personne qui allait toucher « Réserver » finit par toucher le numéro d'un autre cabinet.

L'erreur classique est de tester uniquement sur un ordinateur puissant, où les sauts passent inaperçus. Sur un téléphone avec un réseau lent, le même site danse.

Un site rapide passe inaperçu. Un site lent, jamais.

03Comment vérifier votre site, étape par étape

1. Mesurez avec PageSpeed Insights

Rendez-vous sur PageSpeed Insights, collez l'adresse de votre page d'accueil et attendez l'analyse. Vous verrez deux blocs à ne pas confondre :

• Données d'utilisateurs réels. En haut s'affiche, si votre site a suffisamment de visites, l'évaluation des Core Web Vitals à partir des données de personnes qui ont réellement consulté votre page récemment. C'est le résultat qui compte.
• Diagnostic de laboratoire. En dessous, une simulation avec une note de 0 à 100 et une liste d'opportunités. Elle sert à trouver les causes, mais c'est un test ponctuel qui peut varier d'une analyse à l'autre.

Si votre site est récent ou reçoit peu de visites, vous ne verrez peut-être pas de données réelles. Dans ce cas, appuyez-vous sur le diagnostic de laboratoire et répétez la mesure plusieurs fois pour ne pas réagir à un résultat isolé.

Regardez toujours l'onglet mobile en premier. C'est par là qu'arrivent la plupart des gens qui vous trouvent sur Maps ou via une publicité Instagram, et c'est là que les problèmes se voient le plus.

2. Consultez le rapport de Search Console

Si vous avez Search Console, ouvrez le rapport Core Web Vitals. Google y regroupe les pages de votre site qui partagent des problèmes similaires et les classe en bonnes, à améliorer ou mauvaises. C'est utile, car vous savez ainsi si le problème touche une seule page ou un modèle qui se répète, par exemple toutes les fiches produit ou tous les articles du blog.

3. Notez le coupable de chaque métrique

Dans votre carnet, trois lignes : pour le LCP, quel est le plus grand élément (le diagnostic l'indique) ; pour l'INP, quel code tiers la page charge ; pour le CLS, quels éléments bougent. Cela semble administratif, mais vous évitez ainsi l'erreur la plus coûteuse : corriger des choses qui n'étaient pas le problème.

4. Testez de vos propres yeux sur mobile

Ouvrez votre site sur votre téléphone avec les données mobiles, pas avec le wifi du bureau. Soyez attentif à trois moments : quand vous avez l'impression que tout est chargé, si quelque chose a changé de place et si les boutons réagissent dès que vous les touchez. Demandez à quelqu'un qui n'a jamais vu votre site d'essayer de vous contacter depuis celui-ci, et observez-le sans l'aider.

04Quoi corriger en premier, par ordre d'impact

Tout n'a pas le même poids. Cet ordre donne généralement le plus grand changement pour le moindre effort.

1. Allégez les images

C'est l'amélioration la plus rentable, et vous pouvez la faire vous-même. Exportez les photos à la taille à laquelle elles s'affichent réellement (une photo affichée sur la largeur d'un téléphone n'a pas besoin des dimensions d'un panneau d'affichage) et enregistrez-les dans des formats modernes comme WebP ou AVIF. Des outils gratuits comme Squoosh vous permettent de comparer qualité et poids côte à côte avant de télécharger.

Deux autres règles que votre développeur doit appliquer : l'image principale de chaque page doit se charger en priorité, pas en différé, et toutes les autres images (celles placées plus bas) peuvent attendre que le visiteur fasse défiler la page.

2. Réservez l'espace de chaque élément

Pour stopper les sauts, chaque image, vidéo, carte ou bannière doit avoir son espace réservé avant de se charger. En pratique, cela veut dire indiquer la largeur et la hauteur dans le code, ou un ratio fixe, pour que le navigateur sache combien de place laisser. Si vous utilisez des bandeaux promotionnels ou de cookies, faites-les apparaître par-dessus le contenu, sur un calque, sans le pousser.

3. Faites le tri dans les outils tiers

Dressez la liste de tout ce qui a été installé sur votre site au fil des années : chat, pixel Meta, balises Google, cartes de chaleur, widgets d'avis, boutons de réseaux sociaux, sondages. Pour chacun, posez-vous la question : quelqu'un consulte-t-il les données qu'il génère ? M'apporte-t-il des clients ? Puis-je le charger une fois la page prête ? Ce que personne n'utilise, on le retire. Ce qui sert vraiment, on le charge quand il ne gêne plus.

4. Soignez la vidéo de couverture

Une vidéo plein écran en page d'accueil peut être superbe et devenir en même temps l'élément le plus lourd de votre page. Si vous la gardez, qu'elle soit courte, sans son, compressée, et accompagnée d'une image fixe légère qui s'affiche immédiatement. Sur mobile, la meilleure décision est souvent de n'afficher que cette image.

5. Vérifiez typographies, serveur et plateforme

Ici, mieux vaut faire appel à la personne qui a créé votre site : limiter les variantes de police téléchargées, servir les polices depuis votre propre domaine, utiliser un hébergement avec cache et un réseau de diffusion de contenu (CDN), et vérifier si la plateforme ou le thème que vous utilisez charge du code dont vous n'avez pas besoin. Si le modèle traîne des fonctions que personne n'a demandées, il est parfois plus sensé de reconstruire sur une base légère que de continuer à rafistoler.

05Les erreurs fréquentes quand on travaille la vitesse

• S'obstiner à atteindre 100 à la note de laboratoire. Le vrai objectif, c'est que les données d'utilisateurs réels soient au vert.
• Ne mesurer que la page d'accueil. Les pages services, produits ou menu sont souvent les plus lourdes, et celles qui vendent le plus.
• Tester sur ordinateur et oublier le mobile.
• Installer une extension « d'optimisation » par-dessus dix autres. Ajouter du code pour corriger un excès de code fonctionne rarement.
• Changer beaucoup de choses à la fois et ne pas savoir laquelle a fonctionné. Un changement, une mesure, une note.
• Oublier que les données réelles mettent du temps à se mettre à jour. Après une amélioration, laissez passer quelques semaines avant de juger le rapport de Search Console.

06Un site pensé pour être léger dès le départ

La vitesse est bien plus facile à préserver quand elle se décide dès la conception, et non à la fin. Si vous êtes sur le point de créer ou de refaire votre site, prenez d'abord le temps de lire comment planifier un site web avec une structure et un contenu clairs, car chaque section superflue, c'est du poids en moins. Et si votre activité dépend de votre visibilité sur la carte, la vitesse s'ajoute à tout ce que nous avons vu dans le guide SEO local et Profil d'établissement.

Chez BDB, à Cancún, nous construisons des sites web codés sur mesure, sans modèles surchargés de fonctions inutiles, précisément pour qu'ils se chargent vite sur le téléphone de ceux qui vous cherchent. Si vous souhaitez que nous examinions le vôtre, écrivez-nous.

07Questions fréquentes

Que sont les Core Web Vitals, en termes simples ?

Ce sont trois mesures que Google utilise pour décrire l'expérience réelle des personnes qui visitent votre site : la vitesse à laquelle le contenu principal apparaît (LCP), la rapidité avec laquelle la page répond à un toucher ou à un clic (INP) et sa stabilité pendant le chargement (CLS). Elles sont calculées à partir des données de vrais visiteurs, pas d'un seul test sur votre ordinateur.

Quelles sont les bonnes valeurs de LCP, INP et CLS ?

D'après la documentation officielle de Google sur web.dev, un bon LCP est de 2,5 secondes ou moins, un bon INP de 200 millisecondes ou moins et un bon CLS de 0,1 ou moins. Elles sont évaluées au 75e centile des visites, en distinguant mobile et ordinateur.

Les Core Web Vitals influencent-ils mon référencement sur Google ?

Google recommande d'obtenir de bons Core Web Vitals et indique que, avec d'autres aspects de l'expérience sur la page, ils correspondent à ce que ses systèmes de classement cherchent à récompenser. Google précise aussi qu'il essaie toujours d'afficher le contenu le plus pertinent, même si l'expérience peut être améliorée. Un site rapide ne compense pas un contenu faible, mais il vous évite de perdre des visiteurs et vous aide à vous démarquer face à des offres similaires.

Puis-je améliorer les Core Web Vitals sans être développeur ?

Oui, en grande partie. Compresser les images, supprimer les extensions inutilisées, alléger les vidéos d'arrière-plan et faire le tri dans les chats ou publicités chargés par des services tiers, c'est à la portée de n'importe quel chef d'entreprise. Pour les ajustements de code, de serveur et de typographies, mieux vaut s'adresser à la personne qui a développé le site.

08Sources

• Web Vitals, web.dev
• Largest Contentful Paint (LCP), web.dev
• Interaction to Next Paint (INP), web.dev
• Cumulative Layout Shift (CLS), web.dev
• Core Web Vitals et résultats de recherche, Google Search Central
• Expérience sur la page dans la recherche Google, Google Search Central
• Rapport Core Web Vitals dans Search Console, Aide Google
• PageSpeed Insights