Temps de chargement d'un site web : le mesurer, le tester et l'améliorer

Une page qui tarde à s'afficher fait perdre des visiteurs, des ventes et parfois des positions dans Google. Pourtant, le « temps de chargement » d'un site n'est pas un chiffre unique : c'est une série de moments (la réponse du serveur, le premier texte affiché, l'affichage du contenu principal, la réaction aux clics) que Google mesure avec des métriques précises, les Core Web Vitals. Ce guide explique ce que recouvre le temps de chargement d'un site web, quels sont les seuils officiels, comment faire un test de temps de chargement avec des outils gratuits et quelles actions mener pour améliorer et optimiser votre site web, avec ou sans développeur.

Toutes les valeurs et recommandations de cet article viennent de la documentation de Google : web.dev (le site de l'équipe Chrome consacré à la performance web) et Google Search Central (la documentation officielle sur la recherche Google). Elles ont été relues le 8 octobre 2026.

Qu'est-ce que le temps de chargement d'un site web ?

Le temps de chargement d'une page désigne le délai entre le moment où l'internaute demande la page (en cliquant sur un lien, par exemple) et le moment où il peut la lire et l'utiliser. On parle aussi de vitesse de chargement ou de vitesse d'un site web : c'est la même question vue dans l'autre sens. Plus le temps de chargement est court, plus la vitesse de chargement du site est élevée.

Dans la pratique, ce délai se découpe en plusieurs étapes, chacune mesurée par une métrique :

• TTFB (Time to First Byte, temps de latence du premier octet) : le délai entre la demande de la page et la réception des premiers octets du document HTML. Il dépend notamment de l'hébergement, du serveur et des redirections.
• FCP (First Contentful Paint) : le temps écoulé jusqu'à l'affichage à l'écran d'une première partie du contenu (texte, image).
• LCP (Largest Contentful Paint) : le délai d'affichage de la plus grande image, vidéo ou section de texte visible à l'écran. C'est la Core Web Vital qui mesure les performances de chargement.
• INP (Interaction to Next Paint) : la réactivité de la page aux clics, appuis et touches du clavier pendant toute la visite.
• CLS (Cumulative Layout Shift) : la stabilité visuelle, c'est-à-dire les décalages inattendus de la mise en page pendant le chargement (un bouton qui se déplace au moment où vous cliquez, par exemple).

Autre point important : le temps de chargement d'un site n'est pas le même pour tous les visiteurs. Selon web.dev, les données réelles d'un site forment une distribution : la page peut se charger très vite pour certains visiteurs et très lentement pour d'autres (téléphone ancien, réseau lent, visiteur éloigné du serveur). C'est pourquoi Google ne regarde pas une moyenne, mais le 75e centile des chargements de page, séparément sur mobile et sur ordinateur.

Pourquoi la vitesse de chargement est importante

Pour l'expérience utilisateur et le taux de conversion

La documentation web.dev rassemble plusieurs études de cas qui relient la vitesse et les résultats commerciaux. Deux exemples publiés par web.dev :

• la BBC a constaté qu'elle perdait 10 % d'utilisateurs supplémentaires pour chaque seconde supplémentaire nécessaire au chargement de son site ;
• chez Vodafone, un test A/B a montré qu'une amélioration de 31 % du LCP entraînait une augmentation de 8 % des ventes (étude de cas publiée le 17 mars 2021).

Ces chiffres valent pour ces sites et ne se transposent pas tels quels au vôtre, mais la tendance est constante dans les études citées par web.dev : un site lent pèse sur le rebond, sur la fidélisation et sur la conversion.

Pour le SEO : ce que Google dit vraiment de la vitesse de chargement

La vitesse de chargement est un critère de classement, mais pas un critère dominant. Les faits, d'après Google Search Central :

• la vitesse était déjà utilisée pour classer les recherches sur ordinateur ; avec la « Speed Update », annoncée le 17 janvier 2018 et déployée à partir du 9 juillet 2018, elle est aussi devenue un facteur de classement pour les recherches sur mobile. Google précisait qu'elle ne concernait que les pages les plus lentes et un petit pourcentage de requêtes ;
• aujourd'hui, « les Core Web Vitals sont utilisées par nos systèmes de classement », et Google recommande « vivement » d'obtenir un bon score Core Web Vitals ;
• mais de bons résultats dans le rapport Core Web Vitals ou dans des outils tiers « ne garantit pas » que vos pages s'afficheront en haut des résultats, et chercher un score parfait uniquement pour le SEO « n'est pas forcément pertinent » ;
• enfin, Google s'efforce de toujours afficher le contenu le plus pertinent, même si l'expérience sur la page est décevante ; c'est quand de nombreux contenus utiles répondent à une même requête qu'une bonne expérience sur la page peut faire la différence.

En clair, une page rapide mais sans réponse utile ne remontera pas grâce à sa vitesse ; une page utile mais lente peut perdre face à une concurrente aussi utile et plus rapide. Pour les autres leviers du référencement, voyez notre guide des bonnes pratiques SEO.

Sur mobile : l'indexation mobile-first est terminée

Google utilise la version mobile du contenu d'un site, explorée avec son agent pour smartphone, pour l'indexation et le classement. Google Search Central a annoncé le 31 octobre 2023 que le passage à l'indexation orientée mobile était terminé. Les notifications « indexation mobile-first activée » que la Search Console envoyait il y a quelques années n'ont donc plus d'objet : tous les sites sont concernés. Comme c'est la version mobile qui est indexée, et que Google évalue les Core Web Vitals séparément sur mobile et sur ordinateur, surveillez en priorité les résultats mobiles. Le sujet est développé dans notre guide du SEO mobile.

Quel est un bon temps de chargement ? Les seuils officiels

Google ne fixe pas de « temps de chargement total » idéal. Il fixe des seuils pour chaque métrique. Les trois Core Web Vitals sont celles qui comptent pour la recherche Google ; le FCP et le TTFB servent à diagnostiquer.

Trois précisions pour lire ce tableau :

• Le 75e centile. Une page est jugée conforme si elle atteint les objectifs au 75e centile pour les trois Core Web Vitals, c'est-à-dire pour au moins 75 % des visites, avec des résultats séparés pour le mobile et l'ordinateur.
• L'INP a remplacé le FID. L'INP est devenu une Core Web Vital le 12 mars 2024, à la place du FID (First Input Delay). Un audit ou un outil qui parle encore du FID est donc daté.
• Le TTFB est un « guide approximatif ». Selon web.dev, un site n'a pas absolument besoin d'atteindre le seuil « bon » du TTFB si cela ne l'empêche pas d'obtenir de bons scores sur les métriques importantes (FCP et LCP).

La règle souvent répétée selon laquelle « Google recommande une page chargée en moins de 3 secondes » ne figure pas sous cette forme dans la documentation actuelle de Google : le seul seuil de 3 secondes qui y apparaît est la limite au-delà de laquelle le FCP est jugé médiocre. Pour savoir si votre site est assez rapide, référez-vous aux seuils du tableau.

Comment tester le temps de chargement de votre site

Données de terrain et données de laboratoire : deux mesures différentes

Les outils de test se répartissent en deux familles, que web.dev distingue clairement :

• les données de terrain (ou données utilisateur réelles) sont collectées auprès des vraies personnes qui visitent votre site. Les outils de Google les tirent du rapport sur l'expérience utilisateur de Chrome (CrUX), qui présente la distribution des métriques sur une période de 28 jours. Ce sont elles qui reflètent ce que vivent vos visiteurs ;
• les données de laboratoire sont collectées dans un environnement contrôlé, avec un appareil et un réseau prédéfinis. Elles servent à reproduire et à diagnostiquer un problème.

Les deux peuvent diverger fortement : un test en laboratoire peut annoncer un site très rapide alors que les données de terrain montrent qu'il doit être amélioré, et inversement. Pour juger, partez des données de terrain ; pour corriger, servez-vous du laboratoire.

PageSpeed Insights : le premier test à faire

PageSpeed Insights (pagespeed.web.dev) analyse une page à partir de son adresse : il affiche les données de terrain CrUX de la page ou du site et un audit Lighthouse en laboratoire, avec des recommandations. web.dev note que la section Lighthouse de PageSpeed Insights fournit des conseils pour améliorer le LCP, mais qu'il faut d'abord comparer les données de terrain et de laboratoire. Testez séparément la version mobile et la version ordinateur, et testez plusieurs types de pages (accueil, article, fiche produit) : le résultat d'une page ne vaut pas pour tout le site.

Le rapport Core Web Vitals de la Search Console

Si vous avez accès à la Google Search Console de votre site, le rapport Core Web Vitals est l'outil le plus utile pour un suivi dans le temps. Il classe vos URL par état (« Médiocre », « Amélioration nécessaire », « Bon »), par métrique (LCP, INP, CLS) et par groupe de pages similaires, à partir de données d'utilisation réelles. Pour chaque groupe, la valeur affichée est celle atteinte par 75 % des requêtes de page sur les 28 derniers jours. Seules les URL indexées y figurent, et un groupe sans volume suffisant de données est omis : un petit site peut donc n'y voir que peu de pages.

Lighthouse et les outils pour les développeurs Chrome

Lighthouse est un outil automatisé et open source qui audite les performances d'une page. Il est intégré au navigateur Chrome (panneau « Lighthouse » des outils pour les développeurs) et fonctionne aussi sur des pages qui demandent une connexion. Le panneau « Performances » de Chrome permet d'aller plus loin : il identifie l'élément LCP et affiche la cascade des requêtes réseau. Attention, un outil de laboratoire ne peut pas mesurer l'INP, faute d'interaction réelle ; web.dev indique qu'il s'appuie alors sur le Total Blocking Time (TBT), qui sert d'indicateur de substitution.

WebPageTest et la mesure sur votre propre site

web.dev cite WebPageTest parmi les outils de laboratoire qui permettent de mesurer le LCP et le TTFB et d'identifier l'élément LCP d'une page. Pour un suivi plus fin que CrUX, web.dev recommande aussi aux sites de mesurer eux-mêmes leurs visiteurs réels (on parle de RUM, Real User Monitoring), par exemple avec la bibliothèque JavaScript web-vitals. Si vous cherchez une solution qui surveille la disponibilité et les temps de réponse de votre site en continu, consultez notre comparatif des outils de monitoring de site web.

Les outils de test qui n'existent plus

Deux outils de Google souvent cités dans les anciens articles ont disparu. L'adresse de « Test My Site » redirige désormais vers une page de Think with Google, et celle du « Test d'optimisation mobile » redirige vers la présentation de Lighthouse (constat du 8 octobre 2026). Utilisez PageSpeed Insights, Lighthouse et la Search Console à leur place.

Interpréter les résultats et prioriser les corrections

Un rapport de performance liste souvent des dizaines de recommandations. Pour ne pas vous disperser, partez de la métrique qui est dans le rouge sur les données de terrain, puis remontez à sa cause :

• LCP trop élevé : web.dev découpe le LCP en quatre sous-parties (le TTFB, le délai avant le début du chargement de la ressource LCP, la durée de ce chargement et le délai d'affichage de l'élément). À titre indicatif, sur une page bien optimisée, le TTFB et la durée de chargement de la ressource pèsent chacun environ 40 % du LCP, et les deux délais moins de 10 % chacun. Si l'un des délais pèse beaucoup plus, c'est là qu'il faut agir.
• INP trop élevé : une interaction se découpe en délai d'entrée, durée de traitement et délai de présentation. Le délai d'entrée peut venir de tâches longues qui occupent le navigateur au moment où l'internaute clique.
• CLS trop élevé : cherchez les images, annonces, éléments intégrés et iframes sans dimensions, le contenu injecté après coup et les polices web.
• TTFB élevé : regardez l'hébergement, la mise en cache côté serveur et les redirections. web.dev rappelle que les données de terrain incluent les redirections, alors que les tests de laboratoire mesurent souvent l'URL finale et passent à côté.

Pourquoi un site web est lent : les causes fréquentes

D'après les guides d'optimisation de web.dev, les ralentissements viennent le plus souvent des mêmes causes :

• un serveur lent ou un hébergement sous-dimensionné pour le trafic reçu ;
• des images trop lourdes, dans un format ancien ou plus grandes que leur taille d'affichage ;
• des GIF animés utilisés à la place de vidéos ;
• l'absence de mise en cache et de compression des fichiers texte (HTML, CSS, JavaScript) ;
• trop de scripts tiers (mesure d'audience, publicité, tests A/B, boutons de partage, lecteurs vidéo intégrés) ou d'extensions de CMS ;
• des polices web volumineuses ou découvertes tard par le navigateur ;
• une image principale chargée trop tard, par exemple parce qu'elle est en chargement différé ou insérée par JavaScript ;
• des redirections en chaîne avant d'arriver à la page.

Comment améliorer le temps de chargement d'un site web : 11 actions

Les actions suivantes suivent les recommandations de web.dev. Certaines se règlent dans votre CMS ou chez votre hébergeur ; d'autres demandent un développeur.

1. Choisir un hébergement adapté et réduire le TTFB

Pour web.dev, l'hébergement « doit être votre première préoccupation » avant toute autre optimisation du TTFB : l'hébergeur doit pouvoir absorber le trafic que vous lui envoyez. L'hébergement partagé est généralement plus lent ; ce n'est pas un problème pour un petit site qui sert surtout des fichiers statiques, mais une application avec beaucoup d'utilisateurs, de la personnalisation et des requêtes en base de données demande une offre plus solide. Évitez aussi les redirections inutiles, qui s'ajoutent au TTFB. Pour comparer les offres, voyez notre comparatif des meilleurs hébergements web.

2. Utiliser un CDN

Un réseau de diffusion de contenu (CDN) est un réseau de serveurs répartis qui livre vos ressources depuis un point proche de l'internaute. Selon web.dev, les CDN améliorent les performances, réduisent la charge et les coûts du serveur et absorbent mieux les pics de trafic. Ils sont surtout connus pour diffuser du contenu mis en cache, mais peuvent aussi améliorer la diffusion du contenu qui ne peut pas l'être.

3. Mettre en cache les ressources

Le cache HTTP évite au navigateur de retélécharger une ressource qu'il a déjà. Il se règle par les en-têtes que votre serveur ajoute aux réponses, en particulier Cache-Control, qui indique comment et pendant combien de temps le navigateur et les caches intermédiaires peuvent conserver chaque fichier. Les fichiers qui changent rarement (images, CSS, JavaScript versionnés) peuvent être mis en cache longtemps.

4. Compresser et minifier HTML, CSS et JavaScript

gzip et Brotli sont des algorithmes de compression qui fonctionnent le mieux sur les fichiers texte (CSS, JavaScript, HTML). Tous les navigateurs modernes les acceptent ; c'est votre serveur qui doit être configuré pour les activer. La minification complète la compression : supprimer les commentaires et les espaces inutiles du HTML, du CSS et du JavaScript réduit la taille de la page et de ses ressources.

5. Optimiser les images

Les images sont souvent la ressource la plus lourde d'une page. web.dev recommande de :

• utiliser des formats modernes : WebP et AVIF offrent une meilleure compression que PNG ou JPEG, donc des fichiers plus légers ; WebP fonctionne sur tous les navigateurs modernes ;
• ne pas servir une image plus grande que sa taille d'affichage, et utiliser l'attribut srcset pour que le navigateur choisisse la taille adaptée à chaque écran ;
• indiquer les attributs width et height sur les images et les vidéos, pour que le navigateur réserve la place et que la page ne bouge pas (voir l'action 11).

Si vous publiez beaucoup de visuels, un outil d'optimisation d'image peut redimensionner et convertir automatiquement vos fichiers : voyez notre comparatif des outils d'optimisation d'image.

6. Charger en différé ce qui est hors écran, jamais l'image principale

L'attribut loading="lazy" diffère le chargement des images situées sous l'écran jusqu'à ce que l'internaute s'en approche. web.dev met en garde : n'utilisez pas le chargement différé pour les images susceptibles d'être visibles dès l'ouverture de la page, en particulier l'image LCP. Au contraire, l'image principale doit être découverte le plus tôt possible : présente dans le HTML initial (et non ajoutée par JavaScript), voire préchargée avec fetchpriority="high" lorsqu'il s'agit d'une image d'arrière-plan CSS.

7. Remplacer les GIF animés par des vidéos

Contrairement à une idée encore répandue, convertir une vidéo en GIF n'allège pas la page : c'est l'inverse. web.dev recommande de remplacer les GIF animés par des vidéos. Dans l'exemple de web.dev, un GIF de 3,7 Mo pèse 551 Ko une fois converti en MP4 et 341 Ko en WebM. Une balise <video autoplay loop muted playsinline> reproduit le comportement d'un GIF (lecture automatique, en boucle, sans son).

8. Limiter les scripts tiers, plugins et extensions

Scripts de mesure d'audience, iframes publicitaires, scénarios de test A/B, boutons de partage sur les réseaux sociaux, lecteurs vidéo intégrés : web.dev rappelle que si votre site reste lent alors que votre code est optimisé, c'est probablement la faute de scripts tiers. Il conseille de charger ces scripts avec l'attribut async ou defer pour ne pas bloquer l'analyse de la page, d'héberger le script vous-même si le serveur tiers est lent, et de supprimer purement et simplement un script qui n'apporte aucune valeur ajoutée. Sur WordPress ou un autre CMS, faites régulièrement le tri dans les extensions installées.

9. Optimiser les polices web

Les fichiers de polices volumineux retardent l'affichage du premier contenu, et une valeur font-display mal choisie peut provoquer des décalages visuels. web.dev recommande le format WOFF2, qui compresse jusqu'à 30 % mieux que WOFF, le préchargement des polices utiles (preload) et l'auto-hébergement, qui évite d'ouvrir une connexion vers le domaine d'un fournisseur tiers.

10. Réduire le travail JavaScript pour améliorer l'INP

Un INP élevé peut venir de longues tâches JavaScript qui occupent le navigateur au moment de l'interaction. web.dev recommande de découper ces tâches et de « céder la main » régulièrement au navigateur, de limiter ce qui s'exécute juste après un clic à ce qui met à jour l'écran, et de reporter le reste. C'est un chantier pour développeur, mais vous pouvez déjà réduire la charge en supprimant les scripts tiers inutiles (action 8).

11. Réserver la place des éléments pour éviter le CLS

Les causes les plus courantes d'un CLS élevé, selon web.dev, sont les images sans dimensions, les annonces, éléments intégrés et iframes sans dimensions, le contenu injecté dynamiquement et les polices web. Indiquez toujours width et height sur les images et vidéos (ou réservez l'espace avec la propriété CSS aspect-ratio), et dimensionnez à l'avance les emplacements des annonces et des éléments intégrés.

Ce que vous pouvez faire sans développeur

Une bonne partie du poids d'une page vient de choix éditoriaux. Sans toucher au code, une équipe marketing ou un éditeur de contenu peut déjà :

• se demander si chaque média est utile : une image ou une vidéo qui n'explique rien de plus qu'une phrase ralentit la page sans rien apporter ;
• redimensionner et convertir les images avant de les publier (WebP plutôt que PNG ou JPEG, à la taille réelle d'affichage) ;
• bannir les GIF animés lourds au profit de courtes vidéos ou d'images fixes ;
• faire le tri dans les outils marketing installés sur le site (balises de suivi, pixels, chat, pop-ups) et retirer ceux qui ne servent plus ;
• vérifier la page sur un téléphone avant publication, en regardant ce qui s'affiche en premier ;
• tester les pages clés dans PageSpeed Insights et transmettre au développeur la métrique en défaut, plutôt qu'une liste brute de recommandations.

Le choix de l'outil compte aussi. Les CMS et constructeurs de sites (WordPress, Shopify, Wix, Framer…) n'offrent pas tous la même maîtrise de l'hébergement, du cache et des scripts. Si votre site tourne sous WordPress, notre article 15 techniques pour améliorer la vitesse de votre site WordPress détaille les réglages propres à ce CMS, et notre comparatif des hébergements WordPress aide à choisir une offre adaptée.

Après les corrections : vérifier, puis faire réexplorer vos pages

Une fois les modifications en ligne, refaites un test de temps de chargement dans PageSpeed Insights ou Lighthouse pour vérifier le gain en laboratoire. Les données de terrain, elles, évoluent plus lentement, puisqu'elles portent sur 28 jours de visites réelles.

Dans le rapport Core Web Vitals de la Search Console, cliquez sur « Démarrer le suivi » une fois un problème corrigé sur toutes les URL concernées : Google lance une session de surveillance de 28 jours, et le problème est considéré comme résolu s'il n'est détecté sur aucune URL pendant cette période. Ce suivi ne déclenche pas de réindexation.

Si vous avez aussi modifié le contenu des pages, vous pouvez demander à Google de les explorer de nouveau : avec l'outil d'inspection d'URL pour quelques URL (dans la limite d'un quota, et des demandes répétées pour une même URL n'accélèrent rien), ou en envoyant un sitemap pour un grand nombre d'URL. L'exploration peut prendre plusieurs jours, voire plusieurs semaines.

Par où commencer ?

Chez La Fabrique du Net, nous recommandons de traiter la vitesse de chargement dans cet ordre, pour concentrer l'effort là où il compte :

1. Mesurer sur le terrain : ouvrez le rapport Core Web Vitals de la Search Console (ou PageSpeed Insights) et repérez, sur mobile d'abord, les groupes de pages « Médiocre » ou « Amélioration nécessaire ».
2. Identifier la métrique en défaut (LCP, INP ou CLS) et sa cause, avec Lighthouse et les outils pour les développeurs Chrome.
3. Régler les fondations : hébergement, cache, compression, CDN. Ces réglages profitent à toutes les pages d'un coup.
4. Alléger les modèles de pages les plus visités : images, image principale, scripts tiers, polices.
5. Vérifier en laboratoire, puis sur les 28 jours de données de terrain.

Si la refonte technique dépasse vos ressources internes, une agence de développement web peut auditer et corriger les performances de votre site ; pour choisir l'outil qui servira de base à votre site, voyez aussi nos comparatifs des meilleurs CMS et des plateformes e-commerce, ou notre guide des headless CMS.

FAQ : temps de chargement d'un site

Quel est le temps de chargement moyen d'une page web ?

Google ne publie pas de « temps de chargement moyen » de référence, et une moyenne masque les visiteurs pour qui la page est très lente. Google raisonne en seuils, mesurés au 75e centile des visites : un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins. Pour connaître la situation de votre site, consultez ses données de terrain dans PageSpeed Insights ou dans la Search Console.

Quelle est la vitesse de chargement idéale d'un site web ?

Un site est considéré comme rapide s'il atteint les trois seuils « bons » des Core Web Vitals pour au moins 75 % des visites, sur mobile comme sur ordinateur. En diagnostic, web.dev vise aussi un FCP de 1,8 seconde ou moins et un TTFB de 0,8 seconde ou moins.

Comment tester le temps de chargement d'un site gratuitement ?

Vous pouvez utiliser PageSpeed Insights (données de terrain et audit Lighthouse), le rapport Core Web Vitals de la Google Search Console, Lighthouse, outil open source intégré au navigateur Chrome, et WebPageTest. Testez plusieurs pages, sur mobile et sur ordinateur, et partez des données de terrain pour juger.

Pourquoi mon site web est-il lent ?

Les causes les plus fréquentes sont un serveur ou un hébergement trop lent, des images trop lourdes, l'absence de cache et de compression, trop de scripts tiers ou d'extensions, des polices web mal chargées et une image principale découverte trop tard. Le rapport Lighthouse de PageSpeed Insights indique quelles causes s'appliquent à une page donnée.

La vitesse de chargement est-elle un critère SEO ?

Oui : la vitesse est un facteur de classement sur ordinateur et, depuis la Speed Update de juillet 2018, sur mobile ; les Core Web Vitals sont utilisées par les systèmes de classement de Google. Mais la pertinence du contenu reste prioritaire : une page lente peut bien se classer si son contenu est le plus pertinent, et de bons scores ne garantissent pas la première place.

Comment accélérer le chargement des pages web ?

Commencez par l'hébergement, la mise en cache, la compression et un CDN, puis allégez les pages : images au format WebP ou AVIF et à la bonne taille, image principale chargée en priorité, GIF remplacés par des vidéos, scripts tiers limités, polices en WOFF2. Pour l'INP, réduisez le travail JavaScript ; pour le CLS, donnez des dimensions aux images, aux annonces et aux éléments intégrés.

Faut-il viser un score de 100 sur PageSpeed Insights ?

Non. Google indique qu'essayer d'obtenir un score parfait uniquement pour des raisons de SEO n'est pas forcément pertinent. Le score de laboratoire aide à trouver des pistes ; ce qui compte est que vos visiteurs réels atteignent les seuils des Core Web Vitals.

Combien de temps faut-il pour voir l'effet d'une optimisation ?

Le gain apparaît tout de suite dans un test de laboratoire. Les données de terrain de PageSpeed Insights et de la Search Console portent sur 28 jours : il faut donc environ quatre semaines pour qu'elles reflètent entièrement une correction, et la validation dans la Search Console suit elle aussi une période de surveillance de 28 jours.