Outil gratuit : Performance

Test de vitesse de site web

Nous chargeons votre page comme le ferait un téléphone milieu de gamme sur une connexion 4G lente, nous mesurons la vitesse d’affichage du contenu principal et l’ampleur des décalages de la page, et nous montrons ce qui l’alourdit. Lorsque Google dispose de données d’utilisateurs réels pour votre site, vous les voyez aussi.

Gratuit. Généralement terminé en moins d’une minute.

Ce que vérifie cet outil

  • Un téléphone en 4G lente

    La page est chargée dans Chromium comme sur un téléphone de la classe du Moto G Power (412 × 823), avec une latence de 150 ms, environ 1,6 Mbit/s en réception et 750 kbit/s en émission, et un processeur 4× plus lent. C’est le profil qu’utilise Lighthouse pour ses tests mobiles.

  • Largest Contentful Paint

    Le moment où la plus grande image ou le plus grand bloc de texte du premier écran a fini de s’afficher, et de quel élément il s’agissait.

  • Décalage de mise en page

    L’ampleur des déplacements inattendus du contenu visible pendant le chargement de la page.

  • Temps de blocage total

    Le temps pendant lequel les scripts ont rendu le navigateur trop occupé pour répondre à un appui : la part de chaque tâche longue au-delà de 50 ms, additionnée. C’est l’équivalent en laboratoire de l’Interaction to Next Paint.

  • Ce que la page télécharge

    Le nombre total d’octets et de requêtes, réparti entre images, scripts, CSS et polices, et la part provenant de services tiers.

  • Images lourdes et fichiers bloquant le rendu

    Les images de plus de 150 Ko ou bien plus larges que l’espace où elles s’affichent, et les fichiers CSS et scripts qui retardent le premier rendu.

  • Données d’utilisateurs réels de Chrome

    Le Chrome UX Report de Google pour votre origine sur téléphone, au 75e centile : LCP, INP et CLS, lorsque Google dispose de suffisamment de trafic pour le site.

Ce qu’il ne peut pas vérifier

  • Donner les mêmes chiffres à chaque exécution. Les résultats en laboratoire varient selon le réseau, la charge du serveur et les scripts tiers : comparez donc des tendances plutôt que des exécutions isolées.
  • Correspondre exactement à PageSpeed Insights. Les deux utilisent un profil de téléphone similaire, mais s’exécutent sur des machines et des réseaux différents.
  • Mesurer l’INP en laboratoire. L’INP nécessite de vraies interactions : le test en laboratoire affiche donc le TBT, et les données terrain affichent l’INP lorsqu’elles existent.
  • Afficher des données terrain pour tous les sites. Le Chrome UX Report couvre les 28 derniers jours, et uniquement les origines qui ont suffisamment de trafic Chrome.
  • Tester plus que la page que vous saisissez. Le Rapport Performance payant teste 3 pages clés et classe les causes, avec leurs corrections.

Pourquoi c’est important

Une page qui semble instantanée sur le Wi-Fi du bureau avec un ordinateur portable rapide peut mettre plusieurs secondes à s’afficher sur un téléphone milieu de gamme qui capte mal. C’est la situation que recrée ce test, car c’est là que les images et les scripts lourds font le plus de dégâts.

Les Core Web Vitals sont les mesures de Google pour cette expérience : le chargement (LCP), la réactivité (INP) et la stabilité visuelle (CLS). Google les utilise dans son classement, mais précise qu’une bonne expérience sur la page ne l’emporte pas sur un contenu pertinent. Leur effet le plus important concerne les personnes : une page lente ou instable perd des visiteurs avant qu’ils aient lu quoi que ce soit.

Les causes sont généralement concrètes : une image principale non compressée de plusieurs mégaoctets, un widget de chat qui se charge avant le contenu, une police web qui masque le texte, ou une bannière insérée au-dessus de la page après son affichage. Le test indique l’élément LCP et les fichiers les plus lourds, pour que vous voyiez laquelle de ces causes s’applique.

Comment lire les résultats

Largest Contentful Paint (LCP)
Bon en dessous de 2,5 s, mauvais au-delà de 4 s. Si l’élément LCP est une image, sa taille et sa priorité de chargement comptent le plus ; s’il s’agit de texte, examinez les polices web et le CSS qui bloque le rendu.
Décalage cumulé de mise en page (CLS)
Bon en dessous de 0,1, mauvais au-delà de 0,25. Un score sans unité qui combine la part de l’écran qui a bougé et la distance du déplacement.
Temps de blocage total (TBT)
Bon en dessous de 200 ms, mauvais au-delà de 600 ms. Un TBT élevé laisse prévoir des réponses lentes aux appuis pour les utilisateurs réels.
Octets et requêtes
Il n’existe pas de limite officielle ; regardez quel type domine. Les images représentent généralement la plus grande part, et une part élevée de services tiers désigne les applications, les balises et les widgets.
Images lourdes
Chaque image de plus de 150 Ko, ou téléchargée bien plus large qu’elle n’est affichée, avec son poids et ses dimensions.
Fichiers bloquant le rendu
Le CSS et les scripts synchrones que le navigateur doit télécharger avant de pouvoir afficher quoi que ce soit.
Données terrain (75e centile)
Les utilisateurs réels de Chrome sur téléphone au cours des 28 derniers jours. Le 75e centile signifie que trois chargements de page sur quatre ont été au moins aussi rapides. L’INP est bon en dessous de 200 ms et mauvais au-delà de 500 ms.
Pas de données terrain
Google ne dispose pas d’assez de trafic Chrome pour votre origine. Cela ne dit rien de votre vitesse ; fiez-vous aux résultats en laboratoire.

Comment corriger les problèmes les plus courants

  • Une image LCP lente

    Servez l’image principale à sa taille d’affichage, avec srcset, en WebP ou AVIF. Ne la chargez pas en différé (lazy loading), ajoutez fetchpriority="high" et placez-la dans le HTML sous forme d’élément img plutôt que de la charger depuis un script ou un arrière-plan CSS.

  • Du contenu qui saute pendant le chargement

    Donnez aux images, aux vidéos et aux contenus intégrés des attributs width et height ou un aspect-ratio CSS. Réservez de l’espace pour les bannières, les bandeaux cookies et les publicités, ou affichez-les en superposition sans pousser le contenu vers le bas. Pour les polices web, utilisez font-display: optional ou une police de secours dimensionnée pour correspondre.

  • Un temps de blocage total élevé

    Commencez par supprimer les applications, les balises et les extensions que vous n’utilisez plus ; leurs scripts restent souvent en place après que vous avez cessé de les utiliser. Chargez le chat, les avis et les outils d’analyse avec defer ou une fois la page interactive. Sur Shopify, vérifiez Boutique en ligne › Thèmes › Personnaliser › Intégrations d’applications.

  • CSS et scripts bloquant le rendu

    Ajoutez defer aux scripts qui n’ont pas besoin de s’exécuter avant le premier affichage, intégrez directement dans la page (inline) la petite quantité de CSS nécessaire au premier écran, et retirez les feuilles de style des fonctionnalités que la page n’utilise pas.

  • Des images trop lourdes

    Redimensionnez les images avant de les importer (environ 2000 px de large suffisent largement pour une bannière pleine largeur) et compressez-les. Shopify et WordPress peuvent servir automatiquement des versions plus petites lorsque le thème les demande : vérifiez donc que votre thème utilise des tailles d’image adaptatives (responsive).

Questions sur cet outil

Pourquoi mes résultats diffèrent-ils de ceux de PageSpeed Insights ?

Les tests en laboratoire dépendent de la machine, du réseau et du moment. PageSpeed Insights exécute Lighthouse sur les serveurs de Google et simule la connexion lente, alors que nous appliquons le bridage dans un vrai navigateur. Attendez-vous à des ordres de grandeur similaires, pas à des chiffres identiques.

Qu’est-ce qu’un bon LCP ?

Selon web.dev, un LCP de 2,5 secondes ou moins pour au moins 75 % des chargements de page. Au-delà de 4 secondes, il est considéré comme mauvais.

Pourquoi n’y a-t-il pas de données d’utilisateurs réels pour mon site ?

Le Chrome UX Report n’inclut que les origines publiquement détectables qui reçoivent suffisamment de visites d’utilisateurs de Chrome partageant leurs statistiques d’utilisation. De nombreux petits sites n’atteignent pas ce niveau ; le test en laboratoire montre tout de même ce qu’il faut corriger.

Pourquoi tester sur un téléphone lent plutôt que sur un ordinateur ?

Parce que c’est là que les problèmes apparaissent en premier. Un ordinateur portable rapide masque des images et des scripts lourds qui coûtent des secondes sur un téléphone milieu de gamme, et Lighthouse utilise le même profil de téléphone pour ses tests mobiles.

Qu’est devenu le First Input Delay ?

L’Interaction to Next Paint (INP) a remplacé le First Input Delay en tant que Core Web Vital en mars 2024. L’INP prend en compte le délai des interactions tout au long d’une visite, et pas seulement celui de la première.

Sources

Outils associés

Le Rapport Performance ($55, paiement unique) part de l’analyse gratuite complète et y ajoute davantage de pages, la modification à apporter pour chaque constat, un PDF et de nouveaux tests pour vérifier vos corrections.

À propos du Rapport Performance