Fin juin 2026, l'Arcep recensait 28,1 millions d'abonnements en fibre optique, soit 85 % des accès internet fixes en France. Les tests de débit affichent des centaines de mégabits, et pourtant bien des pages rament encore. D'après le Web Almanac 2025 de HTTP Archive, seules 48 % des origines mobiles passent les trois seuils de Google. Le problème ne vient donc pas de votre box : il se joue côté site, et Google le chronomètre.
Sommaire de ce guide sur les Core Web Vitals
- 📡 Débit ou latence
- ⏱️ Trois seuils
- 📊 Collecte CrUX
- 🌍 État du web
- 🤔 Idées reçues
- 🔍 Diagnostic
- 🛠️ Correctifs
- ✅ Récapitulatif
- ❓ Questions
Débit, latence et temps d'affichage d'une page
Un test de débit mesure la quantité de données que votre ligne transporte par seconde. Une page web, elle, n'est pas un gros fichier : selon le chapitre « Page Weight » du Web Almanac 2025, la page d'accueil mobile médiane pèse 2,6 Mo répartis en 72 requêtes. Chaque requête impose un aller-retour vers un serveur, et c'est ce délai, la latence, qui domine le temps d'attente.
Ilya Grigorik l'a documenté dans « High Performance Browser Networking » (O'Reilly, 2013) à partir des mesures de Mike Belshe, ingénieur chez Google : passer de 5 à 10 Mbit/s n'accélère le chargement que d'environ 5 %, alors que chaque gain de 20 ms de latence réduit le temps de chargement de façon linéaire. Voici ce qui distingue les deux approches de la mesure :
| Critère | Test de débit | Mesure de Google |
|---|---|---|
| Objet mesuré | Votre ligne internet | Le site visité |
| Unité | Mbit/s, ping en ms | Secondes, millisecondes, score de décalage |
| Conditions | Un appareil, un instant | Des milliers de visites sur 28 jours |
| Facteurs parasites | Wi-Fi, terminal, navigateur | Réseau et appareil de chaque visiteur |
| Usage | Vérifier votre abonnement | Évaluer l'expérience de page |
L'Arcep le rappelle d'ailleurs dans son code de conduite des outils de mesure (version 2020) : Wi-Fi, système d'exploitation et navigateur influencent le résultat, et la médiane de latence reflète mieux l'expérience que la moyenne. Le même raisonnement vaut pour la vitesse d'un site.
Les trois signaux web essentiels et leurs seuils
Google résume l'expérience de chargement en trois indicateurs, les signaux web essentiels. La documentation de PageSpeed Insights fixe pour chacun trois zones : bon, à améliorer, mauvais. Ces bornes sont identiques sur mobile et sur ordinateur :
| Indicateur | Ce qu'il mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Affichage du plus grand élément visible | ≤ 2,5 s | 2,5 à 4 s | > 4 s |
| INP | Délai entre un clic et la mise à jour de l'écran | ≤ 200 ms | 200 à 500 ms | > 500 ms |
| CLS | Décalages inattendus de la mise en page | ≤ 0,1 | 0,1 à 0,25 | > 0,25 |
L'INP est le plus récent. Annoncé sur le blog web.dev le 31 janvier 2024, il a remplacé le FID le 12 mars 2024. Le FID ne regardait que la première interaction, quand l'INP observe toutes les interactions de la visite : un menu qui se fige au cinquième clic compte désormais.
TTFB
Le temps de réponse du serveur ne fait pas partie du trio, mais il le conditionne. La fiche TTFB de web.dev recommande 0,8 seconde au plus, en additionnant redirections, résolution DNS, connexion, négociation TLS et attente du premier octet.
FCP
Le First Contentful Paint marque l'apparition du premier texte ou de la première image. Il sert de signal d'alerte avant le LCP : si rien ne s'affiche vite, le plus grand élément arrivera forcément tard.
Comment Google collecte ces mesures chez les internautes
Les valeurs qui comptent pour Google ne sortent pas d'un laboratoire. Elles proviennent du Chrome User Experience Report, ou CrUX, alimenté par de vrais utilisateurs de Chrome. La documentation de méthodologie CrUX précise qui est comptabilisé et quelles pages y entrent :
- Navigateurs : Chrome sur ordinateur et sur Android, jamais Chrome sur iOS ni les WebView d'applications.
- Consentement : statistiques d'usage activées et historique synchronisé, sans phrase secrète de synchronisation.
- Éligibilité : page publique, indexable, en code 200, avec un nombre minimal de visites non divulgué.
- Période : fenêtre glissante de 28 jours affichée par PageSpeed Insights.
- Agrégation : valeur retenue au 75e centile, séparément sur mobile et ordinateur.
Le 75e centile change tout : un site doit être rapide pour trois visites sur quatre au minimum, y compris celles d'un smartphone d'entrée de gamme dans une zone mal couverte. Votre fibre et votre ordinateur récent ne représentent qu'une fraction de ces visites.
La Search Console reprend ces données dans son rapport « Core Web Vitals ». D'après l'aide Google, les URL y sont regroupées par pages similaires, un groupe prend l'état de son indicateur le plus lent, et la validation d'un correctif lance un suivi de 28 jours.
Les scores des Core Web Vitals sur le web en 2025
Le chapitre Performance du Web Almanac 2025, bâti sur les données CrUX de juillet 2025, dresse un état des lieux sans complaisance. L'écart entre mobile et ordinateur reste net, surtout sur le chargement et la réactivité :
| Part des origines « bonnes » | Mobile | Ordinateur |
|---|---|---|
| Les trois seuils à la fois | 48 % | 56 % |
| LCP | 62 % | 74 % |
| INP | 77 % | 97 % |
| CLS | 81 % | 72 % |
| TTFB | 44 % | 55 % |
Le LCP reste le point faible sur smartphone. Le même rapport indique que l'élément LCP est une image sur 76 % des pages mobiles, et qu'environ 16 % des pages chargent cette image en différé, ce qui retarde précisément l'élément que Google chronomètre.
Idées reçues sur la vitesse de chargement et le SEO
La performance attire beaucoup de raccourcis, souvent entretenus par les notes colorées des outils. La page « Understanding page experience » de Google Search Central, mise à jour en septembre 2026, permet de trancher la plupart des débats :
| Idée reçue | Réalité |
|---|---|
| Avec la fibre, tous les sites sont rapides | Au-delà de 5 Mbit/s, la latence et le poids de la page pèsent davantage |
| Le score Lighthouse sur 100 est ce que Google utilise | Le classement s'appuie sur les données réelles CrUX, pas sur une simulation |
| Un site lent ne peut pas se classer | Google montre le contenu le plus pertinent, même si l'expérience est moyenne |
| La vitesse n'a aucun effet sur le référencement | Google écrit que ses systèmes de classement utilisent les Core Web Vitals |
| Il suffit de tester depuis son bureau | Le 75e centile inclut les mobiles lents et les réseaux saturés |
Ce signal existe depuis la mise à jour « page experience », dont le déploiement a débuté mi-juin 2021 pour s'achever fin août 2021, selon le blog Google Search Central d'avril 2021. Il départage surtout des pages de pertinence comparable.
Méthode pas à pas pour mesurer un site lent
Un diagnostic fiable croise données de terrain et données de laboratoire, puis isole l'élément fautif. Les outils gratuits de Google suffisent sans logiciel payant si l'on suit cet ordre :
- Terrain : lancer PageSpeed Insights et lire d'abord le bloc des utilisateurs réels, sur 28 jours.
- Laboratoire : comparer avec Lighthouse, qui simule un Moto G4 sur réseau mobile.
- Gabarits : ouvrir le rapport Search Console pour repérer les groupes d'URL en échec.
- Élément LCP : identifier dans Chrome DevTools l'image ou le bloc de texte concerné.
- Interactions : enregistrer une trace de performance en cliquant menus, filtres et formulaires.
- Validation : corriger, déployer, puis relancer le suivi de 28 jours dans la Search Console.
Ne vous étonnez pas si le laboratoire et le terrain divergent. La documentation PageSpeed Insights explique que les données de terrain sont un historique de visites variées, alors que le laboratoire rejoue un seul scénario : c'est le terrain qui fait foi.
Les correctifs qui améliorent le LCP, l'INP et le CLS
Chaque indicateur a ses coupables habituels. Plutôt que de viser un score parfait, traitez d'abord l'indicateur en rouge sur mobile, celui qui fait basculer le groupe d'URL dans la Search Console.
Chargement
Pour le LCP, l'image principale doit arriver en priorité : ne jamais la charger en différé, la servir en WebP ou AVIF aux bonnes dimensions, et la déclarer tôt dans le HTML. Un cache serveur et un CDN proche des visiteurs raccourcissent le TTFB qui précède tout le reste.
Un serveur installé sur un autre continent ajoute sa latence à chaque aller-retour, quelle que soit la fibre du visiteur. Pour un public francophone, un hébergement ou un CDN avec des points de présence en Europe reste le réglage le plus simple à obtenir.
Réactivité
L'INP souffre des scripts qui monopolisent le fil principal du navigateur. Les chantiers les plus rentables sont connus :
- Scripts tiers : retirer les traceurs et widgets inutiles, différer les autres.
- Tâches longues : découper le JavaScript lourd en morceaux plus courts.
- Thème : éviter les constructeurs de pages qui chargent tout sur chaque URL.
- Polices : les héberger sur le même domaine que le site.
Stabilité
Le CLS se corrige souvent en une journée. Il suffit de réserver la place des images, publicités et intégrations avec des attributs width et height, et de ne jamais insérer une bannière au-dessus d'un contenu déjà affiché.
Les polices web provoquent aussi des sauts de texte quand la police de secours laisse place à la police définitive. Choisir une police de secours aux métriques proches et une règle font-display adaptée limite ce décalage visible.
Récapitulatif des indicateurs de vitesse à surveiller
Voici l'essentiel à garder sous la main pour juger un site sans confondre votre connexion et sa conception. Les seuils viennent de web.dev et de PageSpeed Insights, tous mesurés au 75e centile :
| Indicateur | Seuil « bon » | Cause fréquente | Premier correctif |
|---|---|---|---|
| LCP | 2,5 s | Image lourde ou chargée en différé | Image prioritaire, format moderne |
| INP | 200 ms | JavaScript et scripts tiers | Alléger et découper les scripts |
| CLS | 0,1 | Médias sans dimensions | Attributs width et height |
| TTFB | 0,8 s | Serveur lent ou lointain | Cache et CDN |
| Débit de la ligne | Peu décisif au-delà de 5 Mbit/s | Wi-Fi faible | Tester en câble ou près de la box |
Vos questions sur les Core Web Vitals
Les Core Web Vitals font-ils gagner des places sur Google ?
Oui, mais la pertinence du contenu passe avant. Google Search Central confirme que ses systèmes de classement utilisent ces indicateurs, tout en précisant qu'il affiche le contenu le plus pertinent même quand l'expérience de page est moyenne.
Bon débit, site lent : que disent les signaux web essentiels ?
Parce que la lenteur vient surtout du site et de la latence, pas du débit. Une page mobile médiane enchaîne 72 requêtes : chacune attend un aller-retour serveur, quel que soit le nombre de mégabits de votre abonnement fibre.
Comment mesurer les Core Web Vitals d'un site gratuitement ?
Avec PageSpeed Insights et la Search Console, tous deux gratuits. Le premier affiche les données réelles de 28 jours et une simulation Lighthouse, le second regroupe les URL de votre site par gabarit et par appareil.
Quelle différence entre INP et FID pour les Core Web Vitals ?
Le FID ne mesurait que la première interaction, l'INP les observe toutes pendant la visite. Il a remplacé le FID le 12 mars 2024, avec un seuil de 200 millisecondes pour être jugé bon au 75e centile des visites.
Pourquoi PageSpeed n'affiche aucune donnée Core Web Vitals ?
Parce que la page n'a pas assez de visites Chrome éligibles pour figurer dans CrUX. Le seuil exact n'est pas publié ; en attendant, fiez-vous à Lighthouse et aux données de l'origine entière si elles existent.
Combien de temps pour voir l'effet sur les Core Web Vitals ?
Comptez environ 28 jours, la durée de la fenêtre glissante de CrUX. La Search Console applique la même période à sa validation : les anciennes visites lentes sortent progressivement de la fenêtre observée.
Faut-il viser 100 dans Lighthouse pour les Core Web Vitals ?
Non, l'objectif est de passer les trois seuils sur le terrain, pas d'atteindre un score de laboratoire parfait. Un score Lighthouse moyen peut très bien cohabiter avec des Core Web Vitals réels tous au vert.