Un site qui met plusieurs secondes à afficher son contenu ne fait pas qu’agacer les visiteurs. Il pèse sur la conversion, sur le référencement et sur l’image de l’entreprise. Beaucoup de dirigeants s’en rendent compte tard, souvent parce qu’un prestataire ou un client leur en fait la remarque.
Pour objectiver le problème, Google a standardisé la mesure de l’expérience de page autour de trois indicateurs : les Core Web Vitals. Ils ne sont pas réservés aux techniciens : chacun correspond à un désagrément très concret pour un visiteur.
Cet article explique ce que mesurent ces indicateurs, comment les vérifier sur votre site, ce que peut coûter un site lent et par où commencer pour l’améliorer.
Les Core Web Vitals en clair
Il y a trois indicateurs, chacun avec un seuil à atteindre pour être considéré comme « bon » :
| Indicateur | Ce qu’il mesure | Seuil « bon » | Seuil « mauvais » |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Le temps d’affichage du plus gros élément visible | 2,5 secondes ou moins | Plus de 4 secondes |
| INP (Interaction to Next Paint) | La réactivité aux clics, appuis et saisies | 200 millisecondes ou moins | Plus de 500 millisecondes |
| CLS (Cumulative Layout Shift) | La stabilité visuelle de la page | 0,1 ou moins | Plus de 0,25 |
En clair :
- LCP : combien de temps avant que le visiteur voie l’essentiel de la page.
- INP : le site répond-il vite quand on clique, ouvre un menu ou remplit un formulaire ?
- CLS : le contenu bouge-t-il pendant la lecture, au point de faire cliquer au mauvais endroit ?
Ces seuils sont évalués au 75e centile des chargements de page, séparément sur mobile et sur ordinateur. Autrement dit, pour être jugée « bonne », une page doit atteindre le seuil pour au moins trois visites sur quatre. L’INP est devenu un indicateur stable en 2024, en remplaçant le FID, qui ne mesurait que la première interaction. L’INP observe l’ensemble des interactions de la visite.
Pourquoi cela concerne votre chiffre d’affaires
Un effet sur le référencement, parmi d’autres
Google indique que les Core Web Vitals, avec d’autres aspects de l’expérience de page, s’alignent avec ce que ses systèmes de classement cherchent à récompenser. C’est un signal parmi d’autres : un contenu pertinent reste la première condition d’une bonne visibilité. En revanche, à contenu comparable, une expérience fluide est un avantage à ne pas négliger.
Un effet sur les ventes et les demandes de contact
L’étude de cas publiée par Google sur web.dev à propos de Vodafone est parlante. Après une amélioration de 31 % du LCP (de 8,3 à 5,7 secondes), l’entreprise a mesuré 8 % de ventes en plus, 15 % d’amélioration du ratio prospects par visite et 11 % d’amélioration du ratio de visites atteignant le panier.
Ces chiffres concernent une entreprise précise, dans un contexte précis : ils ne sont pas transposables tels quels à votre activité. Ils montrent néanmoins que la vitesse n’est pas un sujet purement technique, mais un levier commercial.
Les symptômes d’un site qui souffre
Sans outil, vous avez peut-être déjà observé l’un de ces signes :
- une page presque vide pendant plusieurs secondes avant que le contenu n’apparaisse ;
- une image ou une bannière qui apparaît tard et fait descendre le texte ;
- un bouton ou un menu qui réagit avec un temps de retard ;
- un site agréable sur ordinateur, mais pénible sur un téléphone avec une connexion moyenne.
Mesurer avant de corriger
Avant toute intervention, il faut mesurer la situation actuelle :
- Google Search Console propose un rapport Core Web Vitals qui, selon Google, montre comment vos pages se comportent.
- PageSpeed Insights est l’un des outils cités par Google pour mesurer ces indicateurs sur une adresse donnée.
- Testez aussi sur de vrais téléphones, pas seulement sur un ordinateur de bureau et une connexion rapide.
Un point d’attention : les indicateurs sont évalués sur des visites réelles, au 75e centile. Un test ponctuel dans de bonnes conditions peut donc donner une image plus flatteuse que la réalité vécue par vos visiteurs.
Où part le temps de chargement
Le guide de Google sur l’optimisation du LCP décompose le délai en quatre parties et indique la répartition idéale :
| Partie du LCP | Part idéale |
|---|---|
| Temps jusqu’au premier octet (TTFB) | environ 40 % |
| Délai avant le début du chargement de la ressource | moins de 10 % |
| Durée de chargement de la ressource | environ 40 % |
| Délai avant l’affichage de l’élément | moins de 10 % |
L’enseignement pratique est important : si le serveur met longtemps à répondre, optimiser les images ne suffira pas. Google précise d’ailleurs que le LCP inclut le temps de connexion, les redirections et les délais du premier octet. Il faut agir sur les quatre parties ensemble, sous peine de déplacer le problème au lieu de le résoudre.
Corriger les trois indicateurs
Améliorer le LCP : l’élément principal doit arriver vite
D’après les recommandations de web.dev :
- l’image principale doit être découvrable dans le code HTML de la page, et non chargée tardivement par un script ;
- l’attribut
fetchpriority="high"signale au navigateur qu’elle est prioritaire ; - ne jamais appliquer le chargement différé (lazy loading) à cette image, car cela retarde inutilement son chargement ;
- utiliser des formats modernes (WebP, AVIF) et compresser les images ;
- servir les images depuis la même origine que la page lorsque c’est possible ;
- définir une politique de cache efficace, pour que les visites suivantes récupèrent les ressources sans les retélécharger.
N’oubliez pas le serveur : un hébergement lent dégrade le LCP avant même que la page ne commence à se construire.
Améliorer l’INP : alléger le JavaScript
Selon web.dev, une mauvaise réactivité vient principalement de tâches JavaScript longues qui bloquent le navigateur, d’un traitement de scripts trop lourd, et de rendus coûteux (mises en page complexes, calculs de styles, page très volumineuse). Les pistes habituelles : supprimer les scripts inutiles, différer ceux qui ne sont pas indispensables au premier affichage, limiter les scripts tiers et simplifier la structure des pages.
Améliorer le CLS : réserver la place du contenu
Les causes citées par web.dev sont connues : images ou vidéos sans dimensions déclarées, polices web qui changent la taille du texte à leur chargement, publicités ou widgets tiers qui se redimensionnent, et contenus insérés au-dessus d’éléments déjà affichés. La correction consiste à réserver l’espace à l’avance et, pour les animations, à privilégier les transformations (transform) plutôt que des changements de taille ou de position qui déplacent la mise en page.
Les causes fréquentes sur WordPress et PrestaShop
Sur les sites bâtis avec des CMS et des boutiques très extensibles, les mêmes causes reviennent fréquemment :
- l’accumulation de plugins ou de modules, dont beaucoup ajoutent leurs propres scripts et feuilles de styles ;
- des thèmes polyvalents qui chargent des fonctionnalités que la page n’utilise pas ;
- des images mises en ligne sans redimensionnement ni compression ;
- un hébergement sous-dimensionné pour le trafic réel ;
- des scripts tiers (chat, suivi, vidéos intégrées, widgets) qui s’additionnent.
Ces constats sont des tendances, pas une règle : seule une mesure sur votre site permet d’identifier ce qui pèse vraiment.
Par où commencer
- Mesurer l’état actuel avec Search Console et PageSpeed Insights, sur mobile en priorité.
- Identifier l’indicateur le plus dégradé : LCP, INP ou CLS, et les pages les plus visitées ou les plus stratégiques (accueil, fiches produits, pages de contact).
- Traiter d’abord les gains rapides : images, polices, scripts inutiles, cache.
- Vérifier l’hébergement et le temps de réponse du serveur si le LCP reste élevé.
- Re-mesurer, en gardant en tête que les indicateurs reflètent les visites réelles de vos utilisateurs.
Optimiser ou refondre ?
Quand les causes sont ponctuelles, une optimisation ciblée suffit. Quand le problème tient à l’architecture elle-même (thème ou extensions trop lourds, technologie inadaptée, dette technique accumulée), les correctifs successifs finissent par coûter plus cher qu’une refonte raisonnée. C’est une décision à prendre sur la base d’un audit, pas d’une intuition.
Conclusion
Les Core Web Vitals traduisent en chiffres trois choses que vos visiteurs ressentent : la rapidité d’affichage, la réactivité et la stabilité de la page. Les mesurer coûte peu, et les corriger repose le plus souvent sur des actions précises : images, scripts, hébergement, réservation d’espace. Un contenu pertinent reste indispensable, mais un site rapide lui donne de meilleures chances d’être lu, et de convertir.
Votre site vous semble lent ou instable ? Notre agence vous accompagne dans l’analyse des performances, l’optimisation de sites existants et, lorsque c’est pertinent, la refonte de solutions digitales adaptées à vos objectifs.
Sources
- web.dev, Core Web Vitals : web.dev/articles/vitals
- web.dev, Largest Contentful Paint (LCP) : web.dev/articles/lcp
- web.dev, Optimiser le LCP : web.dev/articles/optimize-lcp
- web.dev, Interaction to Next Paint (INP) : web.dev/articles/inp
- web.dev, Cumulative Layout Shift (CLS) : web.dev/articles/cls
- web.dev, Étude de cas Vodafone : web.dev/case-studies/vodafone
- Google Search Central, Core Web Vitals et Search : developers.google.com