« Mon site est lent, mais je ne sais pas pourquoi. » C’est une phrase que j’entends presque à chaque nouveau projet client, souvent accompagnée d’un score PageSpeed Insights vaguement inquiétant, capturé une fois puis jamais revérifié. Les Core Web Vitals sont au cœur de cette question, mais ils restent mal compris, y compris par des clients pourtant très à l’aise avec leur propre métier.
Je me lance donc avec ce premier hors-série technique mensuel du blog : plutôt qu’un énième guide théorique, je voulais partager ma méthode réelle, telle que je l’applique sur mes projets, avec mon avis sur ce qui compte vraiment et ce qui relève, à mon sens, du mythe SEO.
Les Core Web Vitals, en une minute
Trois métriques, trois questions simples derrière des noms un peu barbares.
LCP : la vitesse perçue
Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus gros élément visible de la page, en général : une image d’en-tête ou un bloc de titre. Le « bon » seuil est de 2,5 secondes maximum. C’est la métrique la plus intuitive : c’est littéralement le temps que ressent un visiteur avant d’avoir l’impression que « la page est chargée ».
INP : la réactivité
L’INP (Interaction to Next Paint) mesure la réactivité du site à chaque interaction (clic, tap, saisie) sur toute la durée de la session, pas seulement au premier clic. Seuil « bon » : 200 millisecondes maximum. Cette métrique a remplacé l’ancien FID en mars 2024, et elle est nettement plus exigeante, puisqu’elle traque la pire interaction de toute la visite, pas la première.
CLS : la stabilité visuelle
Le CLS (Cumulative Layout Shift) mesure les décalages visuels inattendus pendant le chargement : typiquement une image sans dimension définie qui pousse le texte vers le bas au moment où vous alliez cliquer. Seuil « bon » : score inférieur à 0,1.
Pourquoi je les explique différemment à mes clients qu’aux techniciens
Face à un client, je ne commence jamais par ces définitions. Je commence par une question simple : « est-ce que ça vous est déjà arrivé de quitter un site parce qu’il ne réagissait pas assez vite, ou parce que le bouton a bougé au moment où vous alliez cliquer ? » La réponse est presque toujours oui. Les Core Web Vitals ne sont, au fond, qu’une mesure chiffrée d’une frustration que tout le monde a déjà vécue sans y mettre de nom technique.
Comment je mesure, concrètement, sur chaque projet
Voici ma méthode réelle, pas la version idéalisée qu’on trouve dans certains guides.
Les données terrain (CrUX) plutôt que le score de labo
La première confusion que je corrige systématiquement : le score affiché en haut de PageSpeed Insights est une mesure de laboratoire, dans des conditions standardisées. Ce n’est pas ce que Google utilise pour le classement. Ce qui compte réellement, ce sont les données terrain issues du Chrome User Experience Report (CrUX), qui agrègent la navigation de vrais utilisateurs Chrome sur les 28 derniers jours. Un site peut afficher un excellent score en laboratoire et un mauvais score terrain, notamment si une partie significative des visiteurs navigue sur des connexions ou des appareils plus modestes.
Les outils que j’utilise en pratique
Sur chaque projet, je croise systématiquement trois sources : le rapport Core Web Vitals de la Google Search Console (données terrain, vue d’ensemble par groupe d’URL), PageSpeed Insights (données terrain + labo, page par page, avec le détail des optimisations suggérées), et Lighthouse en local pendant le développement, pour itérer rapidement sans attendre l’accumulation de données terrain.
Les corrections qui donnent le plus de résultat, dans mon expérience
Sur la majorité des projets que j’ai audités, trois interventions reviennent bien plus souvent que les autres.
Sur le LCP : compression et priorisation des images
C’est, de très loin, la cause la plus fréquente d’un mauvais LCP : une image d’en-tête non compressée, souvent plusieurs mégaoctets, exportée directement depuis un appareil photo ou une banque d’images haute définition. La compression au format WebP ou AVIF, combinée au préchargement explicite de cette image prioritaire, suffit très souvent à elle seule à faire basculer un site de la zone rouge à la zone verte.
Sur l’INP : alléger le JavaScript
Les mauvais scores INP viennent presque toujours d’un excès de scripts JavaScript exécutés au chargement ou lors des interactions : trop d’extensions cumulées sur un CMS, des widgets tiers mal optimisés (chat, réseaux sociaux, tracking multiples). Ma règle personnelle : chaque script tiers ajouté doit justifier son coût en performance, pas seulement sa fonctionnalité.
Sur le CLS : réserver l’espace des éléments
Le CLS se corrige presque toujours de la même façon : définir explicitement les dimensions (largeur/hauteur) de chaque image et bloc publicitaire ou bannière, pour que le navigateur réserve l’espace nécessaire avant que le contenu ne charge, plutôt que de laisser la page « sauter » au fur et à mesure.
Un exemple concret tiré de mes projets
Sur un site vitrine que j’ai livré récemment pour un client de la région grenobloise, le diagnostic initial pointait un LCP largement au-dessus du seuil, entièrement causé par une image de fond en pleine largeur, non compressée, chargée avant même le texte de la page d’accueil. La correction (compression, format moderne, préchargement) a suffi à ramener la métrique en zone verte, sans toucher au design visible par l’utilisateur, un exemple typique de ce que je vois sur la majorité des projets : le problème n’est presque jamais le design en tant que tel, mais l’implémentation technique derrière.
Ce que je dis à mes clients qui pensent que « leur site est déjà rapide »
C’est un piège fréquent : un site peut paraître rapide sur l’ordinateur de bureau du client, avec une bonne connexion fibre et un poste récent, tout en étant nettement plus lent pour une partie de ses visiteurs réels, sur mobile ou en 4G. Je recommande systématiquement de tester sur le rapport Search Console (données terrain réelles) plutôt que de se fier à une impression personnelle, forcément biaisée par ses propres conditions de navigation.
Ce décalage de perception est d’autant plus fort que le dirigeant d’une entreprise consulte souvent son propre site depuis le même appareil, au bureau, avec la page déjà partiellement chargée en cache du navigateur suite à ses visites précédentes. Un visiteur qui découvre le site pour la première fois, depuis son téléphone, en extérieur, vit une expérience objectivement différente et c’est précisément cette expérience là que les Core Web Vitals cherchent à capturer.
Mon avis : les Core Web Vitals sont utiles, mais surestimés par beaucoup de clients
Je vais être direct : je pense que les Core Web Vitals sont sur-vendus dans une partie du discours marketing SEO, présentés parfois comme un levier miracle de positionnement. Dans les faits, Google les utilise davantage comme un facteur de départage entre des pages de qualité de contenu équivalente, que comme un critère dominant à lui seul. Un site rapide avec un contenu médiocre ne dépassera pas un site plus lent mais nettement plus pertinent pour la requête. En revanche, entre deux sites globalement comparables sur le fond, celui qui offre la meilleure expérience technique a un vrai avantage. C’est cette nuance que j’essaie toujours de transmettre : optimiser ses Core Web Vitals est nécessaire, mais ce n’est jamais suffisant à lui seul.
Conclusion : une base technique à ne pas négliger, sans en attendre de miracle
Les Core Web Vitals ne sont ni un gadget technique ni une baguette magique SEO : ce sont un indicateur fiable d’une expérience utilisateur réellement vécue par vos visiteurs, avec un vrai poids dans le classement Google, mais un poids qui reste secondaire face à la pertinence du contenu. Mon conseil reste toujours le même : les corriger fait partie des fondations d’un bon site, au même titre que la structure SEO abordée dans notre article sur pourquoi le design peut nuire au référencement, mais ça ne remplacera jamais un contenu réellement utile derrière.
Je referai probablement un point sur ce sujet dans quelques mois, une fois que j’aurai accumulé plus de retours chiffrés sur mes propres projets clients : c’est un des avantages de tenir ce genre de format régulier plutôt qu’un article isolé, figé une fois pour toutes.
Vous voulez savoir où se situe votre propre site sur ces trois métriques ? L’outil de diagnostic gratuit d’Opozite vous donne un premier état des lieux en quelques secondes.