Réponse courte. Un site « lent » se mesure avec trois indicateurs publiés par Google, les Core Web Vitals : l'affichage de l'élément principal (LCP, bon jusqu'à 2,5 secondes), la réactivité aux gestes (INP, bon jusqu'à 200 millisecondes) et la stabilité de la mise en page (CLS, bonne jusqu'à 0,1). On les lit dans PageSpeed Insights, en mobile. Sur un site vitrine, l'ordre de correction qui rapporte le plus est presque toujours le même : les images d'abord, les scripts tiers ensuite, puis les polices, puis l'hébergement.
Ce guide explique comment mesurer sans se tromper de chiffre, puis quoi corriger, dans quel ordre.
Les trois mesures, et leurs seuils officiels
| Mesure | Ce qu'elle mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Le temps d'affichage du plus grand élément visible : souvent la photo d'en-tête ou le titre | ≤ 2,5 s | de 2,5 à 4 s | > 4 s |
| INP (Interaction to Next Paint) | Le délai entre un geste (toucher un bouton, ouvrir un menu) et la réponse à l'écran | ≤ 200 ms | de 200 à 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Les déplacements inattendus de contenu pendant le chargement | ≤ 0,1 | de 0,1 à 0,25 | > 0,25 |
Ces seuils sont publiés par Google sur web.dev, et s'appliquent au 75e centile des visites : pour qu'un site soit « bon », trois visites sur quatre au moins doivent passer sous le seuil.
Une précision de proportion : Google utilise ces mesures dans ses systèmes de classement, mais précise lui-même qu'une bonne expérience de page ne compense pas un contenu peu pertinent. Un site rapide qui ne répond pas à la recherche ne sera pas mieux classé. Un site pertinent mais très lent, lui, perd les visiteurs qui n'attendent pas.
Mesurer sans se tromper de chiffre
Ouvrez pagespeed.web.dev, collez l'adresse de votre page, choisissez Mobile.
En haut, les données réelles. Le bloc « Découvrez l'expérience de vos utilisateurs réels » vient du rapport d'expérience utilisateur de Chrome, sur les 28 derniers jours. C'est ce que vivent vos visiteurs. S'il affiche « pas assez de données », votre site n'a pas assez de visites pour être mesuré ainsi ; il reste la mesure de laboratoire.
En dessous, le laboratoire. Le score sur 100 et le « Diagnostic des problèmes de performances » viennent de Lighthouse, qui simule un téléphone de milieu de gamme avec une connexion lente. Ce score varie d'un test à l'autre. Lancez la mesure trois fois et gardez la valeur du milieu.
Les deux pièges les plus fréquents :
- Tester la page d'accueil seulement. Testez aussi la page de service qui reçoit le plus de visites, souvent plus lourde.
- Tester sur l'ordinateur et conclure que « ça va ». Votre ordinateur sur la fibre n'est pas le téléphone d'un client dans une cave en 4G.
Quoi corriger, et dans quel ordre
1. Les images (le LCP, le plus souvent)
Sur un site vitrine, l'élément principal est presque toujours une photo d'en-tête. C'est donc elle qui fixe le LCP.
- Dimensionnez : une photo de 4 000 pixels de large affichée sur un écran de 400 pixels transporte dix fois trop d'information. Exportez à la taille d'affichage, avec une variante pour mobile.
- Compressez et modernisez le format : WebP ou AVIF, plutôt que JPEG ou PNG non optimisés. Les navigateurs actuels les lisent tous.
- Ne différez pas l'image principale : le chargement différé (
loading="lazy") est utile pour les images plus bas dans la page, mais nuisible sur la photo d'en-tête. Celle-ci doit se charger en premier. - Indiquez les dimensions (
widthetheight) de chaque image : le navigateur réserve la place, et le contenu ne saute plus (CLS).
2. Les scripts tiers (l'INP et le LCP)
Chaque outil ajouté au site charge son propre code : fenêtre de discussion, carte interactive, outil de statistiques, bandeau d'avis, pixel publicitaire, widget de réseau social. Ils s'additionnent.
- Faites l'inventaire : dans PageSpeed Insights, la section « Réduire l'impact du code tiers » liste les domaines extérieurs et leur coût.
- Retirez ce qui ne sert pas : un pixel publicitaire d'une campagne terminée, un deuxième outil de statistiques.
- Différez le reste : une carte peut se charger quand on clique dessus, plutôt qu'à l'ouverture de la page.
3. Les extensions et les constructeurs de pages
Sur WordPress, chaque extension peut ajouter ses fichiers sur toutes les pages, même là où elle ne sert pas. Les constructeurs de pages visuels produisent souvent un code plus lourd que nécessaire. Désactivez les extensions inutiles, une par une, en mesurant après chaque retrait.
4. Les polices de caractères
Trois familles en cinq graisses, c'est quinze fichiers. Limitez-vous à une ou deux familles et aux graisses réellement utilisées, et utilisez font-display: swap pour que le texte s'affiche avant que la police soit chargée.
5. Les fenêtres surgissantes
Une fenêtre qui couvre l'écran à l'ouverture sur mobile gêne la lecture et peut décaler la mise en page. Google déconseille les interstitiels intrusifs. Un bandeau discret fait le même travail.
6. L'hébergement (le temps de réponse du serveur)
Si toutes les corrections ci-dessus sont faites et que la page reste lente, regardez le temps de réponse du serveur (TTFB). web.dev considère comme bon un TTFB de 0,8 seconde ou moins. Au-delà, l'hébergement, l'absence de cache ou une base de données surchargée sont en cause. C'est le dernier poste à changer, pas le premier : un hébergement plus cher ne compense pas des images de 5 Mo.
Après les corrections
- Remesurez dans PageSpeed Insights, trois fois, en mobile.
- Les données réelles mettent jusqu'à 28 jours à refléter un changement, puisqu'elles portent sur cette période. Ne concluez pas le lendemain.
- Dans la Search Console, le rapport Signaux Web essentiels regroupe les pages par état (bon, à améliorer, médiocre) à partir des données réelles.
Si vous voulez déléguer
La mesure de vitesse fait partie du diagnostic digital express à 490 €. Les corrections de performance d'un site existant correspondent à la prestation « SEO technique, données structurées et performance », à partir de 1 490 € ; si le site doit être refait, la refonte commence à 4 990 €. Le détail est sur la page Création de site internet. Pour situer la vitesse parmi les autres causes d'appels perdus, voir les 10 erreurs d'un site d'artisan.
Sources
- web.dev : Les Core Web Vitals
- web.dev : Largest Contentful Paint (LCP)
- web.dev : Interaction to Next Paint (INP)
- web.dev : Cumulative Layout Shift (CLS)
- web.dev : Time to First Byte (TTFB)
- web.dev : Chargement différé des images au niveau du navigateur
- Google Search Central : Comprendre les Core Web Vitals et les résultats de recherche Google
- Google Search Central : Expérience sur la page dans les résultats de recherche Google
- Aide Search Console : Rapport Signaux Web essentiels
Questions fréquentes
Quel est le bon temps de chargement pour un site sur mobile ?
Google ne fixe pas un temps de chargement global, mais trois seuils : l'élément principal affiché en 2,5 secondes au plus (LCP), une réponse aux gestes en 200 millisecondes au plus (INP), et une stabilité de mise en page de 0,1 au plus (CLS), pour au moins 75 % des visites.
Pourquoi mon score PageSpeed change-t-il à chaque test ?
Le score sur 100 vient d'une mesure de laboratoire, qui dépend de l'état du réseau et du serveur au moment du test. Des écarts de quelques points sont normaux. Lancez trois mesures et retenez la valeur du milieu, ou fiez-vous aux données réelles quand elles existent.
Un site lent est-il pénalisé par Google ?
Google utilise les Core Web Vitals comme un signal parmi d'autres, et précise qu'une bonne expérience de page ne remplace pas un contenu pertinent. L'effet le plus direct d'un site lent n'est pas le classement : ce sont les visiteurs qui partent avant que la page s'affiche.
Faut-il changer d'hébergeur pour accélérer son site ?
Rarement en premier. Sur un site vitrine, les images trop lourdes, les scripts tiers et les extensions inutiles pèsent généralement plus que l'hébergement. Si le temps de réponse du serveur dépasse 0,8 seconde après ces corrections, l'hébergement devient la piste à examiner.