Un site rapide commence à envoyer sa page en moins de 0,8 seconde, affiche son contenu principal en moins de 2,5 secondes et réagit à un clic en moins de 200 millisecondes. Le temps de chargement d’un site web est le délai entre la demande d’une page par le visiteur et le moment où elle s’affiche et devient utilisable. Google l’évalue avec les Core Web Vitals : le LCP pour l’affichage du contenu principal, l’INP pour la réactivité et le CLS pour la stabilité visuelle. Si votre site dépasse ces seuils, commencez par trois correctifs qui ne demandent pas de développeur, dans cet ordre : un cache de page, des images allégées, le tri des scripts tiers. Le serveur ne devient la limite qu’une fois ces chantiers faits.
Quel temps de chargement viser pour un site web ?
Un bon temps de chargement se fixe indicateur par indicateur : moins de 0,8 s pour la réponse du serveur (TTFB), moins de 2,5 s pour le LCP, moins de 200 ms pour l’INP et un score CLS inférieur à 0,1. Google publie ces seuils.
| Indicateur | Ce qu’il mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| TTFB | Délai avant le premier octet envoyé par le serveur | moins de 0,8 s | 0,8 à 1,8 s | plus de 1,8 s |
| LCP | Affichage du plus grand élément visible | moins de 2,5 s | 2,5 à 4 s | plus de 4 s |
| INP | Réaction à un clic ou un toucher | moins de 200 ms | 200 à 500 ms | plus de 500 ms |
| CLS | Décalages de la mise en page | moins de 0,1 | 0,1 à 0,25 | plus de 0,25 |
Le TTFB ne fait pas partie des Core Web Vitals, mais il conditionne les trois autres : tant que le serveur n’a rien envoyé, rien ne s’affiche.
Une page est conforme quand 75 % de ses visites respectent chaque seuil, et non en moyenne. Une moyenne flatteuse peut cacher un quart de visiteurs mobiles, mal connectés, qui attendent bien plus longtemps.
Le repère de 2 secondes pour une page complète, souvent cité, est un ordre de grandeur, pas une norme. Une page qui met 5 s à charger entièrement peut convenir si son contenu principal s’affiche tout de suite et que le chat ou les statistiques arrivent ensuite.
Core Web Vitals et LCP : que mesure Google exactement ?
Les Core Web Vitals sont les trois indicateurs par lesquels Google juge l’expérience d’une page : le LCP mesure l’affichage du contenu principal, l’INP la réactivité et le CLS la stabilité visuelle. Chacun dérape pour des raisons différentes, donc lisez-les séparément.
LCP : l’affichage du contenu principal
Le Largest Contentful Paint (LCP) mesure le temps d’affichage du plus grand élément visible à l’ouverture de la page : la bannière d’une page d’accueil, la photo principale d’une fiche produit, le titre ou le premier paragraphe d’un article sans visuel en tête.
PageSpeed Insights désigne l’élément LCP de chaque page analysée, avec un aperçu. Quand il est lent, trois causes reviennent : un serveur qui répond tard, une image trop lourde ou une image chargée en différé alors qu’elle est visible dès l’ouverture.
INP et CLS : la réactivité et la stabilité
L’INP (Interaction to Next Paint) mesure le délai entre un clic, un toucher ou une frappe et la réaction visible de la page ; il a remplacé le FID dans les Core Web Vitals en mars 2024. Les scripts tiers le dégradent en occupant le processeur : le bouton « Ajouter au panier » est affiché, mais le navigateur exécute encore le code d’un widget.
Le CLS (Cumulative Layout Shift) chiffre les déplacements inattendus du contenu pendant l’affichage. Ses causes habituelles sont connues : images sans dimensions déclarées, bandeaux qui s’insèrent au-dessus du texte, polices web chargées en retard qui changent la taille des lignes. Le visiteur qui clique au moment où un bloc descend touche le mauvais lien.
Pourquoi la vitesse pèse sur le référencement et les ventes
Un site lent perd des positions face à une page de contenu comparable mais plus rapide, et des visiteurs mobiles avant même l’affichage. La vitesse départage sans remplacer le contenu : un site lent reste plafonné, un site rapide sans contenu utile ne monte pas.
Le mobile pèse le plus. Google a fait de la vitesse un facteur de classement dans la recherche mobile en 2018, et l’indexation mobile-first conduit Googlebot à explorer en priorité la version mobile de vos pages. Regardez donc vos mesures mobiles en premier. Le chiffre souvent cité de 53 % de visiteurs mobiles qui partent au-delà de 3 secondes vient d’une étude DoubleClick de 2016 : il indique une tendance, pas une mesure actuelle.
Sur un gros catalogue e-commerce, la vitesse influence aussi la cadence d’exploration de Googlebot. Une panne coûte plus cher qu’une lenteur : selon la documentation de Google sur les codes HTTP, « les URL qui renvoient durablement une erreur serveur finissent par être supprimées de l’index ».
Un site lent a aussi trois effets sur les citations dans les Aperçus IA, ChatGPT ou Perplexity : une indexation ralentie, des erreurs quand l’assistant consulte la page à la demande et des visiteurs perdus en route.
Comment mesurer le temps de chargement de son site ?
Un test de vitesse fiable croise deux sources : les données de terrain de la Search Console et de PageSpeed Insights, issues de vos vrais visiteurs, et les données de laboratoire de Lighthouse ou GTmetrix, issues d’une simulation. Les premières disent si le site respecte les seuils, les secondes expliquent pourquoi.
Données de terrain et données de laboratoire
Les données de terrain viennent du CrUX (Chrome User Experience Report), qui agrège les visites réelles d’utilisateurs de Chrome sur 28 jours glissants. Google évalue vos pages sur ces données, qui reflètent les téléphones et les connexions de votre audience.
Les données de laboratoire, produites par Lighthouse, la partie diagnostic de PageSpeed Insights ou GTmetrix, simulent un chargement sur un appareil et une connexion fixés. Instantanées et reproductibles, elles servent à tester un correctif. La règle tient en une phrase : pilotez sur le terrain, validez les correctifs en laboratoire.
Lire PageSpeed Insights et la Search Console
Dans PageSpeed Insights, lisez d’abord le bloc du haut, onglet Mobile : il affiche les données de terrain de la page et du site entier. Si la page manque de trafic dans le CrUX, il ne montre que celles du site, voire la seule simulation.
Le score de 0 à 100 affiché plus bas vient du laboratoire et se lit en trois zones : 0 à 49 à corriger vite, 50 à 89 à améliorer, 90 à 100 bon. Ce score n’est pas un objectif SEO : une page à 65 peut passer les trois seuils sur le terrain, une page à 95 peut les rater sur les téléphones de vos clients.
Dans la Search Console, le rapport Core Web Vitals (intitulé « Signaux Web essentiels », rubrique Expérience) regroupe les URL similaires et les classe en bon, à améliorer ou mauvais, séparément pour mobile et ordinateur. Commencez par le groupe le plus mal classé : sur une boutique, les fiches produits partagent souvent le même gabarit, donc le même défaut.
Pourquoi mon site est-il lent ? Le diagnostic par symptôme
La lenteur d’un site se rattache à une cause précise dès que l’on regarde quel indicateur dérape. Le tableau relie chaque symptôme à sa cause probable et à la personne la mieux placée pour la corriger.
| Symptôme mesuré | Cause probable | Qui s’en occupe |
|---|---|---|
| TTFB au-dessus de 0,8 s | Pas de cache de page, serveur sous-dimensionné | Vous pour le cache, puis l’hébergeur |
| TTFB bon, LCP élevé | Image principale trop lourde ou chargée en différé | Vous |
| INP mauvais | Scripts tiers : consentement, statistiques, chat, widgets, cartes, polices externes | Vous pour le tri, un prestataire pour différer le code |
| CLS mauvais | Images sans dimensions, bandeau de consentement, polices web | Vous ou le prestataire qui gère le thème |
| Le site ne s’affiche plus | Erreur 5xx, serveur saturé, ressources épuisées, DNS, certificat | L’hébergeur, immédiatement |
Le TTFB est le premier suspect : aucun réglage d’image ne compense un serveur qui met 2 secondes à répondre. Si le TTFB est bon et le LCP mauvais, regardez les images, qui font la plus grosse part du poids d’une page.
Un site qui ne s’affiche plus du tout relève d’un autre diagnostic : erreur 500 ou 503, pic de trafic qui sature le serveur, mémoire ou disque épuisés, domaine qui ne pointe plus, certificat SSL expiré. Contactez votre hébergeur sans attendre, car une panne qui dure expose vos URL à une sortie de l’index.
Accélérer son site sans développeur : les 3 chantiers prioritaires
Pour réduire vous-même le temps de chargement de vos pages, traitez trois chantiers dans cet ordre : activer un cache de page, alléger les images, puis trier les scripts tiers et les extensions. Le premier rapporte le plus pour le moins d’effort.
1. Activer un cache de page
Le cache de page enregistre une version HTML prête de chaque page, que le serveur renvoie au lieu de la recalculer avec PHP et la base de données à chaque visite. Mesure faite sur revoweb.fr le 5 octobre 2026 : TTFB d’environ 0,5 s sans cache de page, de 0,07 s avec l’extension Cache Enabler, soit un temps de réponse divisé par 7 sur le même serveur.
Sous WordPress, une seule solution de cache suffit, WP Rocket, Cache Enabler ou le cache serveur de votre hébergeur : en cumuler deux provoque des conflits. Sous PrestaShop, le cache est intégré :
- Ouvrez Paramètres avancés > Performances dans le back-office.
- Activez le cache Smarty.
- Désactivez le mode debug, prévu pour le développement : il ralentit l’affichage.
- Dans le bloc CCC (combinaison, compression, cache), activez le cache intelligent des CSS et du JavaScript.
- Videz le cache, puis contrôlez l’affichage de l’accueil, d’une catégorie, d’une fiche produit et du panier.
2. Alléger les images
Alléger les images d’un site consiste à réduire leur poids et à les servir à la bonne taille. Convertissez-les en WebP ou en AVIF, plus légers que le JPEG à qualité visuelle égale, et compressez-les avec TinyPNG ou ImageOptim avant la mise en ligne. Redimensionnez chaque image à la largeur réellement affichée : une colonne d’article de 732 pixels rend inutile une photo de 4 000 pixels.
Déclarez la largeur et la hauteur de chaque image pour stabiliser le CLS. Réservez le lazy loading (chargement différé au défilement) aux images situées sous la ligne de flottaison. Ne l’appliquez jamais à l’image LCP, que le navigateur afficherait en retard : vérifiez dans le code source que l’attribut loading de votre bannière n’a pas la valeur lazy.
3. Faire le tri dans les scripts et les extensions
Chaque script tiers ajoute du travail au processeur du visiteur : bandeau de consentement, statistiques, chat, widget d’avis, carte, police externe. Supprimez ceux qui ne servent plus, comme le pixel d’une campagne terminée. Différez les autres après l’affichage du contenu avec les attributs defer ou async, ou avec l’option de report du JavaScript de votre extension de cache.
Les extensions WordPress et les modules PrestaShop méritent le même inventaire. Supprimez plutôt que de désactiver : un module inactif ne ralentit plus la page, mais ses fichiers restent sur le serveur et doivent être tenus à jour.
Quand l’hébergement devient le frein
L’hébergement devient le facteur limitant quand le TTFB reste au-dessus de 0,8 s avec un cache de page actif, ou quand le site ralentit aux heures de pointe et retrouve sa vitesse la nuit. Il faut alors un serveur dimensionné au trafic réel ; le tableau résume les options.
| Type d’hébergement | Ressources | Profil adapté |
|---|---|---|
| Mutualisé | Partagées entre plusieurs sites, économique mais limité | Site vitrine à trafic modéré |
| VPS | Allouées à votre machine virtuelle | Boutique en croissance, agence avec plusieurs sites |
| Dédié | Serveur entier réservé, meilleures performances | Gros catalogue, trafic soutenu |
| Cloud | Évolutives, haute disponibilité | Trafic irrégulier, pics saisonniers |
Avant de changer d’offre, demandez à votre hébergeur ces réglages côté serveur :
- une version de PHP encore maintenue ;
- une base de données purgée ;
- la compression Gzip ou Brotli des fichiers texte ;
- le protocole HTTP/2 ;
- un CDN, surtout utile pour une audience internationale ou des pics de trafic.
L’emplacement du serveur n’influe pas, à lui seul, sur le classement d’un site national en .fr. Un hébergement infogéré confie ces réglages, la surveillance et les mises à jour à un prestataire d’infogérance chargé de l’optimisation serveur. Et un site lent ne justifie pas d’emblée une refonte : mesurez et corrigez d’abord les causes.
Quelles optimisations ne servent plus, et comment rester rapide ?
Plusieurs conseils de vitesse encore répandus sont dépassés : fusionner les fichiers CSS et JavaScript, utiliser des sprites CSS, adopter AMP ou la police au format EOT. Pour éviter que le site ralentisse de nouveau, un budget de performance et un contrôle mensuel des données de terrain suffisent.
La fusion des fichiers limitait le nombre de requêtes sous HTTP/1.1. Avec HTTP/2, qui charge les fichiers en parallèle, elle n’apporte plus rien, même si des guides encore bien classés la recommandent toujours. Les sprites CSS sont périmés pour la même raison, et Google n’exige plus AMP depuis juin 2021. Pour les polices, préférez le WOFF2 avec la propriété font-display, et remplacez les GIF animés par des vidéos.
La vitesse d’un site est une agrégation de petites améliorations, et les ralentissements s’accumulent de la même façon. Fixez un budget de performance (poids maximal par page, LCP à ne pas dépasser) et vérifiez-le avant chaque ajout de module, de bannière ou de script marketing. Une agence peut automatiser ce contrôle avec Lighthouse CI.
Après un correctif, validez-le en laboratoire et notez sa date. Les données de terrain portant sur 28 jours glissants, comptez environ un mois avant de voir le temps de chargement de votre site web s’améliorer dans la Search Console. Ouvrez ensuite le rapport Core Web Vitals chaque mois pour repérer une dérive avant qu’elle touche vos positions.
Questions fréquentes
Faut-il viser un score de 100 sur PageSpeed Insights ?
Non, un score de 100 sur PageSpeed Insights n'est pas nécessaire. L'outil classe la vitesse comme bonne entre 90 et 100, et ce score sort d'un test de laboratoire, simulé sur un seul chargement. Google juge en réalité vos pages sur les données de terrain des Core Web Vitals : LCP sous 2,5 secondes, INP sous 200 millisecondes et CLS sous 0,1, pour au moins 75 % des visites. Mieux vaut atteindre ces seuils que gagner quelques points de score.
Pourquoi PageSpeed Insights n'affiche-t-il aucune donnée réelle pour ma page ?
PageSpeed Insights n'affiche aucune donnée réelle quand la page ne reçoit pas assez de visites de navigateurs Chrome pour figurer dans le rapport CrUX (Chrome User Experience Report). C'est fréquent sur un site récent ou peu fréquenté. L'outil propose alors seulement le test de laboratoire Lighthouse. Consultez dans ce cas les données de l'origine entière, si elles existent, ou le rapport Signaux Web essentiels de la Search Console, qui regroupe les pages similaires.
Combien de temps faut-il pour voir l'effet d'une optimisation de vitesse ?
Comptez environ quatre semaines pour voir l'effet d'une optimisation de vitesse dans les données de Google. Les données de terrain affichées par la Search Console et PageSpeed Insights portent sur les 28 derniers jours de visites réelles : une correction apparaît donc progressivement. Le test de laboratoire Lighthouse montre en revanche le gain tout de suite, ce qui sert à valider le correctif avant d'attendre la confirmation sur le terrain.
Un CDN est-il utile pour un site qui vise uniquement la France ?
Un CDN apporte peu à un site dont les visiteurs et le serveur sont tous en France. L'emplacement géographique du serveur ne change pas, à lui seul, le classement d'un site national. Le gain de distance reste faible quand le serveur est déjà en France. Un cache de page et un hébergement dimensionné au trafic réduisent davantage le temps de réponse. Le CDN devient intéressant pour servir des images lourdes ou absorber des pics de trafic.
