En bref : Un site lent se diagnostique en quelques minutes avec un outil gratuit de Google, PageSpeed Insights. Trois indicateurs comptent, les Core Web Vitals : le LCP mesure le temps d'affichage du contenu principal (2,5 secondes ou moins), l'INP la réactivité quand on touche un bouton (200 millisecondes ou moins), le CLS les sauts de mise en page (0,1 ou moins). Sur un site de TPE, la lenteur vient souvent de trois sources : des images trop lourdes, trop de scripts et d'extensions, ou un serveur qui répond tard. Regardez d'abord les données réelles du rapport plutôt que la note sur 100, qui n'est qu'une simulation. Un bon résultat améliore l'expérience de vos visiteurs, mais d'après Google il ne garantit aucune position. Ce tutoriel s'appuie sur la documentation de Google et sur nos propres mesures, relevées le 1er novembre 2026.
Ce satellite prolonge notre guide Créer son site internet avec l'IA : les 3 voies comparées. Il s'adresse au dirigeant qui a entendu dire que son site était lent et qui veut comprendre, sans devenir technicien.
Seuils et définitions tirés de web.dev et de la documentation de PageSpeed Insights, consultés le 1er novembre 2026. Les exemples sont illustratifs, sauf nos mesures sur fjdigital.fr, datées et signalées comme telles.
Que mesurent les Core Web Vitals, en langage courant ?
En bref : Les Core Web Vitals répondent à trois questions que se pose un visiteur. Est-ce que ça s'affiche ? C'est le LCP, le temps avant que le plus gros élément visible, souvent une image ou un titre, apparaisse. Est-ce que ça réagit ? C'est l'INP, le délai entre un geste, comme toucher un menu, et la réponse visible à l'écran. Est-ce que ça bouge tout seul ? C'est le CLS, une note des décalages qui vous font cliquer à côté quand une bannière pousse le texte. Google mesure ces trois valeurs sur le 75e centile des visites : trois visiteurs sur quatre doivent atteindre l'objectif, pas seulement ceux qui ont un bon réseau. Attention aux guides anciens : l'INP a remplacé le FID le 12 mars 2024, et le FID ne fait donc plus partie de ces indicateurs.
| Indicateur | Question du visiteur | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP (chargement) | Est-ce que ça s'affiche ? | 2,5 s ou moins | jusqu'à 4 s | plus de 4 s |
| INP (réactivité) | Est-ce que ça réagit ? | 200 ms ou moins | jusqu'à 500 ms | plus de 500 ms |
| CLS (stabilité) | Est-ce que ça bouge ? | 0,1 ou moins | jusqu'à 0,25 | plus de 0,25 |
Comment lire un rapport PageSpeed Insights sans se tromper ?
En bref : Le rapport contient deux parties qu'il ne faut pas confondre. La première, en haut, indique ce qu'ont vécu de vrais visiteurs utilisant Chrome, sur les 28 derniers jours : ce sont les données réelles, celles qui disent si la page réussit ou non l'évaluation Core Web Vitals. La seconde, le diagnostic avec sa note sur 100, vient d'un chargement simulé, sur un seul appareil et un réseau fixe : elle sert à trouver les problèmes, pas à juger le résultat. Sur un site à faible trafic, le cas de nombreuses TPE, la première partie est souvent vide, faute de visites suffisantes. Ce n'est pas une anomalie. Fiez-vous alors au diagnostic, et lancez plusieurs tests, car Google précise que la note peut varier sans que la page ait changé. Testez toujours sur mobile, et sur vos pages qui comptent, pas seulement sur l'accueil.
Lire votre rapport en quatre étapes
Allez sur pagespeed.web.dev, collez l'adresse d'une page qui vous amène des clients, et lancez l'analyse en restant sur l'onglet Mobile.
Nous l'avons vérifié le 1er novembre 2026 : deux passages de Lighthouse à quelques minutes d'intervalle sur notre page d'accueil, sans rien modifier, ont donné la même note et un LCP simulé différent de 0,2 seconde. Pour suivre l'ensemble du site dans la durée, le rapport Core Web Vitals de la Google Search Console complète ce test page par page.
Quelles causes de lenteur retrouve-t-on souvent sur un site de TPE ?
En bref : Trois causes reviennent souvent sur les sites de petites entreprises. Première cause, les images : une photo de téléphone envoyée telle quelle pèse plusieurs mégaoctets, alors qu'une version bien dimensionnée, en AVIF ou WebP, tient souvent en moins de 150 Ko. Elle pèse directement sur le LCP. Deuxième cause, les scripts : extensions accumulées, widgets de réservation, outils de suivi, carte, chat. Chacun ajoute du code que le téléphone doit exécuter, ce qui dégrade la réactivité. Troisième cause, le serveur : si la première réponse arrive tard, tout le reste attend. web.dev donne comme repère un temps de réponse de 0,8 seconde ou moins. Un hébergement mutualisé très chargé ou l'absence de cache suffisent à le dépasser. Le diagnostic indique laquelle de ces causes domine sur votre page : commencez par celle-là, plutôt que par celle que vous soupçonnez.
Images. Redimensionnez à la taille d'affichage réelle et compressez. Une erreur classique consiste à charger en différé l'image principale : le guide web.dev sur le LCP rappelle qu'elle doit au contraire arriver le plus tôt possible. Réservez le chargement différé aux images plus bas dans la page.
Scripts et extensions. Faites l'inventaire et posez une question pour chacun : sert-il encore ? Sur un site WordPress, chaque extension supprimée est aussi une maintenance en moins, comme le détaille notre analyse du coût réel d'un site WordPress.
Serveur. Exemple illustratif : une boutique de Libourne dont les pages mettent plus d'une seconde à commencer à répondre gagnera peu à compresser ses images. Le premier levier est d'activer le cache ou de questionner l'hébergeur.
La mesure peut aussi surprendre. Le 1er novembre 2026, sur une page d'article de fjdigital.fr, un seul fichier JavaScript représentait 527 Ko transmis en Brotli, soit 3,07 Mo une fois décompressés, alors que l'image principale pesait 78 Ko. Sans mesure, nous aurions cherché du côté des images. Ce fichier est désormais sur notre liste de corrections. Autre leçon : notre premier test local affichait ce fichier sans compression, et donc un résultat bien plus sombre que la réalité. Avant de vous alarmer d'un chiffre, vérifiez dans quelles conditions il a été mesuré.
Quant aux sauts de page mesurés par le CLS, le guide web.dev cite d'abord les images sans dimensions et les contenus injectés tardivement, comme les publicités et les intégrations. Indiquer la largeur et la hauteur des images règle souvent une bonne partie du problème.
Quel score viser sans en faire une obsession ?
En bref : Pour la note sur 100, Google considère 90 ou plus comme bon, 50 à 89 comme à améliorer, moins de 50 comme mauvais. Mais cette note reste une simulation, et la documentation précise qu'un bon résultat en laboratoire ne signifie pas forcément une bonne expérience réelle. L'objectif utile est donc plus simple : les trois Core Web Vitals au vert sur les données réelles quand elles existent, et sinon aucune alerte majeure sur vos pages importantes. Côté référencement, restez lucide. Google indique que de bons résultats vont dans le sens de ce que ses systèmes de classement récompensent, sans garantir de figurer en tête, et qu'il cherche toujours à montrer le contenu le plus pertinent, même si l'expérience sur la page est imparfaite. Passer de 92 à 100 ne vaut donc pas une journée de travail : mieux rédiger une page de service sera souvent un meilleur usage de ce temps.
Une règle simple pour arbitrer : corrigez ce que vos visiteurs ressentent. Une page qui met six secondes à s'afficher sur un téléphone mérite une intervention, quelle que soit sa note. Une page fluide notée 85 peut attendre. Le reste du temps se place mieux dans vos fondamentaux de référencement local et dans des contenus clairs, qui comptent aussi pour être cité par les moteurs IA.
Dans quel ordre corriger un site lent ?
En bref : L'ordre le plus rentable part de ce qui coûte peu et rapporte vite. Mesurez d'abord une page qui compte, sur mobile, et notez le résultat avec la date, pour pouvoir comparer plus tard. Traitez ensuite les images, car c'est souvent le gain le plus simple, et il ne demande en général pas de développeur. Faites après cela le tri des scripts et des extensions, en testant le site après chaque suppression, pour repérer ce qui casse. Interrogez enfin votre hébergeur ou votre prestataire si le temps de réponse du serveur reste élevé. Ne corrigez qu'une chose à la fois, puis refaites le test, afin de savoir ce qui a vraiment produit un effet. Les données réelles mettant 28 jours à se renouveler complètement, patientez avant de juger un changement sur le bloc du haut du rapport. Le diagnostic simulé, lui, réagit tout de suite.
Ma routine vitesse pour une page importante
Core Web Vitals : trois questions pour vérifier
Quelle partie du rapport PageSpeed Insights dit si une page réussit les Core Web Vitals ?
Ce qu'il faut retenir
En bref : Un site lent se comprend avec trois questions : est-ce que ça s'affiche (LCP, 2,5 secondes ou moins), est-ce que ça réagit (INP, 200 millisecondes ou moins), est-ce que ça bouge tout seul (CLS, 0,1 ou moins) ? Dans PageSpeed Insights, regardez d'abord les données réelles, puis utilisez le diagnostic simulé pour trouver la cause. Sur une TPE, celle-ci se situe souvent dans les images, les scripts et extensions, ou le temps de réponse du serveur, mais seule la mesure le confirme : sur notre propre page, le plus gros poste de poids était un fichier JavaScript, pas une image. Visez le vert sur vos pages importantes, sans courir après un score de 100, car Google ne promet aucune position en échange. Corrigez une chose à la fois, notez vos mesures, et consacrez le temps restant à vos contenus et à vos pages de service, sans négliger la vitesse pour autant.
La formation Créer son site internet sur mesure avec l'IA se déroule sur 2 jours à Bordeaux ou à distance : vous construisez votre site avec Claude Code, puis vous apprenez à le mesurer et à le corriger avec ces mêmes outils. Pour faire le point sur votre situation, réservez un appel de 15 minutes. Pour replacer la vitesse dans l'ensemble du projet, consultez notre guide des trois voies pour créer son site.
Sources consultées le 1er novembre 2026 :
- web.dev : les Core Web Vitals, optimiser le LCP, optimiser le CLS, le TTFB et l'INP devient une Core Web Vital le 12 mars 2024
- Google : à propos de PageSpeed Insights
- Google Search Central : Core Web Vitals et résultats de recherche et comprendre l'expérience sur la page
Questions fréquentes
