Sur ordinateur, au bureau, votre site s’affiche bien. Sur un téléphone, dans la rue, la page reste blanche quelques secondes, puis le titre arrive, puis le reste. Vos visiteurs vivent la seconde version. Avant de corriger, il faut mesurer avec les bons outils et lire les chiffres correctement, parce qu’un score de vitesse varie beaucoup d’une mesure à l’autre. Je vous donne la méthode, les causes qui reviennent, et ce que j’ai changé sur mon propre site.
Mesurer avec PageSpeed Insights, et lire ce qu’il affiche
PageSpeed Insights, l’outil gratuit de Google, affiche deux types de données qu’on confond souvent. En haut, les données terrain : l’expérience de vrais visiteurs sur Chrome, collectée sur les 28 derniers jours, et retenue au 75e centile pour refléter les visites les plus pénibles. En dessous, les données de laboratoire : un chargement simulé par Lighthouse sur un téléphone de milieu de gamme et un réseau mobile. Google prévient que les deux peuvent différer. Quand une page n’a pas assez de visiteurs, l’outil se replie sur l’ensemble du site, et parfois n’affiche aucune donnée terrain. Le score de 0 à 100 vient du laboratoire : 90 et plus est bon, 50 à 89 est à améliorer, moins de 50 est mauvais.
Les trois seuils officiels des Core Web Vitals
- →LCP (Largest Contentful Paint) : temps d’affichage du plus gros élément visible, image ou bloc de texte. Bon à 2,5 secondes ou moins, à améliorer jusqu’à 4 secondes, mauvais au-delà.
- →INP (Interaction to Next Paint) : délai de réaction à un toucher ou un clic. Bon sous 200 millisecondes.
- →CLS (Cumulative Layout Shift) : stabilité de la page pendant le chargement, quand un bouton se décale sous le doigt. Bon sous 0,1.
- →Google évalue chaque seuil au 75e centile des chargements, séparément sur mobile et sur ordinateur. Le rapport Core Web Vitals de Search Console regroupe ces résultats pour tout votre site.
Une seule mesure ne prouve rien. Sur le site d’un artisan du chauffage que je suis, j’ai relevé 20 points d’écart sur la même page à deux minutes d’intervalle. Le soir de sa mise en ligne, les mesures tombaient en deux paquets : 88 à 97 avec un LCP de 2,6 à 3,1 secondes, ou 63 à 73 avec un LCP de 7,3 à 8,8 secondes, sans que le site change entre les deux. Et faute de trafic suffisant, ce site n’a aucune donnée terrain : seul le laboratoire le mesure. Ma règle : trois mesures, je garde la médiane, et je compare toujours avec le même outil.
Les cinq causes qui reviennent
Google découpe le LCP en quatre temps : la réponse du serveur, le délai avant que le navigateur commence à charger l’élément principal, la durée de ce chargement, et le délai avant son affichage. Chaque cause ci-dessous allonge l’un de ces quatre temps.
Dans l’ordre où je les cherche
- 1.L’image principale trop lourde ou découverte tard : une photo de bannière non compressée, ou chargée par un script au lieu d’être présente dans le HTML. Format WebP, poids réduit, chargement prioritaire.
- 2.Les polices de caractères : chaque police téléchargée retarde l’affichage du texte. Une police de moins, c’est un téléchargement de moins.
- 3.Le code qui bloque l’affichage : feuilles de style et scripts placés en tête de page, ou un titre masqué tant qu’un script n’a pas joué son animation d’entrée.
- 4.Les scripts et bibliothèques en trop : effets animés, modules tiers, outils de test. Google cite les longues tâches du processeur parmi les causes de retard, et elles pèsent aussi sur l’INP.
- 5.Le serveur lent : au-delà de 600 millisecondes avant le premier octet, la cause se trouve du côté de l’hébergement, du cache ou du CDN. Sur le site d’artisan cité plus haut, le serveur répondait en 43 à 118 millisecondes : ce suspect-là était écarté d’emblée.
Les deux autres métriques ont leurs propres suspects. Une page qui saute pendant le chargement, le CLS, vient le plus souvent d’images posées sans dimensions, d’un bandeau ou d’un module intégré qui pousse le contenu, d’une police qui change la taille du texte en arrivant, ou d’un bloc qui apparaît tard au-dessus du reste. Une page qui réagit mal au doigt, l’INP, souffre presque toujours de trop de JavaScript : scripts tiers empilés, gestionnaires d’événements lents, processeur occupé au moment du toucher. Sur un site vitrine, le LCP reste le chantier prioritaire ; ces deux-là se vérifient ensuite, avec le même outil.
Ce que la lenteur coûte en clients
Le cas le plus propre que je connaisse vient de Vodafone, publié par Google sur web.dev en 2021. Deux versions d’une même page d’arrivée, trafic partagé à 50/50, aucune différence visuelle : seule la vitesse changeait. La version au LCP amélioré de 31 % a produit 8 % de ventes en plus. Dans mes repères de travail, un site dont le LCP dépasse 4 secondes peut diviser son taux de conversion par deux. La règle vaut aussi pour la publicité payante : chaque clic payé arrive sur la même page lente. Côté classement, Google est clair : il cherche à montrer le contenu le plus pertinent, même quand l’expérience de page est médiocre. Accélérer un site garde vos visiteurs ; la pertinence de la page reste le premier critère de classement.
Vous voulez savoir ce qui ralentit votre site ?
Je mesure vos pages principales sur mobile, je vous montre la cause qui pèse le plus et l’ordre des corrections. Trente minutes, sans engagement.
Audit gratuit 30 minCe que j’ai corrigé sur mon propre site
Fin août 2026, PageSpeed Insights donnait à mon site un score mobile de 65 et un LCP de 6,5 secondes, alors que l’ordinateur affichait 94. J’ai cherché dans l’ordre ci-dessus, et quatre corrections sont parties en production le 6 septembre. La bannière d’accueil est désormais rendue côté serveur, sans fondu d’entrée : le titre principal démarrait à opacité zéro et attendait une animation, ce qui retardait le LCP. Les fondus d’entrée ont été retirés de dix sections. Les bibliothèques d’animation 3D ont été désinstallées. Une police a été supprimée.
Le résultat, mesuré avec Lighthouse le 6 septembre sur les deux versions : 6,8 secondes de LCP pour l’ancienne, entre 3,1 et 3,9 secondes pour la nouvelle selon la passe. Le LCP a été divisé par deux, et le score mobile est passé de 53 à une fourchette de 70 à 80. Je reste au-dessus des 2,5 secondes que Google juge bonnes, et la mesure officielle PageSpeed Insights est encore à refaire. Je l’écris tel quel : un chiffre flatteur tiré d’une seule passe ne vous servirait à rien pour juger votre propre site.
Par où commencer sur votre site
Mesurez l’accueil et vos deux pages qui reçoivent le plus de visites, sur mobile, trois fois chacune. Repérez la métrique la plus faible : presque toujours le LCP sur un site vitrine. Repérez ensuite le plus gros élément affiché à l’écran au chargement, image ou bloc de texte : c’est lui que mesure le LCP. Si c’est une image, travaillez son poids et sa priorité ; si c’est un titre, cherchez ce qui retarde son affichage. Les gains rapides et sans risque viennent en premier : compression, mise en cache, chargement différé des images situées plus bas dans la page, scripts inutiles retirés.
- Mesurez avec PageSpeed Insights, trois fois, et gardez la médiane.
- Le LCP est bon à 2,5 secondes ou moins et mauvais au-delà de 4 secondes.
- Image principale, polices, code bloquant, scripts en trop, serveur : les cinq suspects habituels.
- Chez Vodafone, un LCP amélioré de 31 % a apporté 8 % de ventes en plus.
- La vitesse garde les visiteurs, la pertinence de la page reste le premier critère de Google.
