« Mon site est joli mais il rame. » C'est une phrase que nous entendons souvent, et elle sous-estime le problème : un site lent ne se contente pas d'agacer, il fait perdre des clients avant même qu'ils aient vu ce que vous proposez.
Google a formalisé cette réalité sous le nom de Core Web Vitals : trois mesures qui traduisent ce que ressent réellement un visiteur. Leur définition et leurs seuils sont publics, documentés sur web.dev/articles/vitals : tous les chiffres cités ici en viennent, aucun n'est de notre invention. Voici ce qu'elles signifient et comment agir dessus.
Que mesurent exactement LCP, INP et CLS ?
Les trois mesures observent trois moments différents de la visite : l'affichage, la réaction au clic, et la stabilité de ce qui est affiché. Un site peut être excellent sur l'une et mauvais sur les deux autres, ce qui explique qu'un site « qui a l'air rapide » échoue quand même au contrôle.
| Mesure | Ce qu'elle observe | Bon | Mauvais | Cause la plus fréquente |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Le moment où le plus gros élément visible s'affiche | moins de 2,5 s | plus de 4 s | Une image trop lourde, un serveur lent à répondre |
| INP (Interaction to Next Paint) | Le délai entre le clic et la réaction visible à l'écran | moins de 200 ms | plus de 500 ms | Du JavaScript accumulé, souvent des scripts tiers |
| CLS (Cumulative Layout Shift) | Le déplacement du contenu pendant le chargement | moins de 0,1 | plus de 0,25 | Une image ou une bannière dont la place n'est pas réservée |
Les seuils de ce tableau sont ceux publiés par Google sur web.dev/articles/vitals. Ils ne sont ni une opinion d'agence, ni une cible commerciale.
Comment lire chacune des trois mesures ?
Le LCP est l'indicateur le plus proche de la question « à partir de quand la page paraît-elle chargée ? ». L'INP a remplacé le FID en mars 2024 parce qu'il observe l'ensemble des interactions et pas seulement la première ; le détail du remplacement est documenté sur web.dev/articles/inp. C'est la mesure la plus souvent dégradée sur les sites construits avec des constructeurs visuels : le contenu s'affiche vite, mais la page reste collante pendant plusieurs secondes. Le CLS, enfin, décrit une expérience que tout le monde a vécue : ce texte que vous commencez à lire et qui saute, ce bouton que vous ratez parce qu'une bannière l'a poussé vers le bas.
Les Core Web Vitals influencent-elles le classement Google ?
Oui, mais moins qu'on ne le dit. Les Core Web Vitals font partie des signaux de classement, ce que Google documente explicitement dans sa page sur l'expérience sur la page (developers.google.com/search). Leur poids reste modeste comparé à la pertinence du contenu, et Google l'écrit lui-même : un site lent avec une réponse excellente restera devant un site rapide et creux.
Mais entre deux pages de qualité comparable, ce qui est exactement la situation entre vous et votre concurrent direct, la vitesse départage. C'est là que se joue son intérêt : pas comme levier de classement à elle seule, comme critère de départage.
Un site lent fait-il vraiment fuir les visiteurs ?
C'est l'effet le plus direct, et il n'a rien à voir avec Google. Nous n'avancerons pas ici de pourcentage : les chiffres qui circulent sur le lien entre vitesse et conversion viennent d'études propriétaires, portant sur des sites de très grande taille, et rien ne dit qu'ils se transposent au vôtre. Se les approprier serait exactement le procédé que cet article vous invite à repérer chez les autres.
Ce qui est documenté, en revanche, c'est le seuil. Google fixe les fourchettes bon, à améliorer et mauvais de LCP, INP et CLS à partir des données de navigation réellement collectées auprès des utilisateurs de Chrome, le rapport CrUX (developer.chrome.com/docs/crux).
Et pour votre site précisément, vous n'avez besoin d'aucune statistique de marché : ouvrez votre outil de mesure d'audience et comparez le taux de rebond de vos pages les plus lentes à celui de vos pages les plus rapides. C'est le seul chiffre qui vous concerne, et il est déjà chez vous.
S'y ajoute un effet plus difficile à mesurer et tout aussi réel : un site lent est perçu comme moins fiable, moins professionnel, parfois moins sûr. Ce jugement est instantané, rarement conscient, et il précède la lecture du moindre argument.
Comment mesurer les Core Web Vitals de votre site ?
Deux outils suffisent.
PageSpeed Insights (pagespeed.web.dev) donne une note de laboratoire et, si votre site a assez de trafic, les mesures réelles issues des utilisateurs de Chrome. Ce sont ces dernières qui comptent pour Google.
Le rapport « Signaux web essentiels » de la Search Console (search.google.com/search-console) montre l'évolution sur l'ensemble de vos pages, groupées par type. C'est la vue la plus utile pour prioriser.
Une précision importante : testez toujours la version mobile en priorité. C'est elle que Google évalue, et c'est elle qui est le plus souvent dégradée.
D'où vient la lenteur d'un site, dans la pratique ?
Trois causes reviennent presque toujours, et dans cet ordre.
Les images
C'est le premier poste, et de loin. Une photo de 4 Mo prise au téléphone puis envoyée telle quelle dans une page pèse à elle seule plus que tout le reste.
Les corrections sont simples et très rentables :
- convertir en WebP ou AVIF, qui divisent le poids par trois à cinq à qualité égale ;
- redimensionner aux dimensions réelles d'affichage, inutile de servir 4 000 pixels de large pour une vignette ;
- charger en différé toutes les images situées sous la ligne de flottaison ;
- réserver explicitement la place de chaque image dans la page, ce qui supprime la majeure partie du CLS.
Les scripts tiers
Chaque outil ajouté charge son propre code : mesure d'audience, chat en direct, bandeau de cookies, widget d'avis, pixels publicitaires. Pris isolément, chacun paraît anodin. Cumulés, ils dégradent surtout l'INP.
Faites l'inventaire honnêtement, et posez pour chaque script la question : qu'est-ce que je perds si je le retire ? Beaucoup de sites conservent des outils installés il y a trois ans que plus personne ne consulte.
Pour ceux que vous gardez, chargez-les en différé plutôt qu'en bloquant l'affichage. Et surveillez les nouveaux : un script ajouté pour une campagne de deux semaines reste souvent en place deux ans, parce que personne ne se souvient qu'il est là ni qui l'a installé. Notez la date d'ajout et la raison quelque part, ne serait-ce que dans un tableur : c'est ce qui rendra le prochain inventaire possible.
Faut-il changer d'hébergement ou de technologie ?
Parfois, oui, et c'est la troisième cause. Un hébergement mutualisé à 3 € par mois partage un serveur avec des centaines d'autres sites. Le temps de réponse initial en pâtit, et aucune optimisation d'image ne compensera un serveur qui met une seconde à répondre.
Sur WordPress, une accumulation d'extensions produit le même effet : chacune ajoute des requêtes en base de données et des fichiers à charger. Un site avec quarante extensions actives est structurellement lent.
C'est l'une des raisons pour lesquelles nous développons la plupart de nos sites en Next.js, avec des pages générées à l'avance et servies depuis un réseau de diffusion : il n'y a rien à calculer au moment où le visiteur arrive.
Par où commencer si vous n'avez qu'une journée ?
Procédez dans cet ordre : il va du plus rentable au plus lourd.
- Optimiser les images. Une demi-journée de travail, souvent 40 à 60 % du poids des pages en moins.
- Retirer les scripts inutiles. Une heure d'inventaire, un effet immédiat sur l'INP.
- Activer la mise en cache. Sur WordPress, une extension de cache bien réglée suffit. Sur un site statique, c'est natif.
- Réserver la place des éléments variables. Images, publicités, bandeaux : le CLS disparaît presque entièrement.
- Reconsidérer l'hébergement. Si le temps de réponse serveur dépasse 600 ms, aucun réglage ne vous sauvera.
Ce qu'il faut retenir des Core Web Vitals
La vitesse n'est pas un sujet technique réservé aux développeurs. C'est une question commerciale : elle détermine combien de visiteurs voient réellement votre offre.
Un site qui s'affiche en moins de deux secondes sur un téléphone en 4G, qui répond instantanément au clic et qui ne saute pas pendant le chargement, convertit mieux, indépendamment de tout ce que Google en pense.
C'est pour cette raison que nous mesurons les performances avant et après chaque intervention, et que ces relevés font partie de nos livrables au même titre que le design. Ils sont remis au client ; nous les publierons dans nos fiches de projets à mesure que les clients concernés nous y autorisent, parce qu'un chiffre de performance dit aussi quelque chose de leur activité.
