Test de vitesse de page et vérificateur Core Web Vitals
Free, no signup. Core Web Vitals reports are usually a wall of numbers before they tell you anything useful. This leads with one sentence: whether the page passes, and the single thing to fix first — real Chrome user data when it exists, a Lighthouse lab audit when it doesn't.
+ enregistre le site ou la page actuels. Utilisez ☆ à côté de tout site, page ou liste enregistré pour l’ajouter aux favoris. L’historique des vérifications récentes apparaît ci-dessous.
Créer une liste nommée
Cible remplie à partir de vos choix locaux.
Passeport du site Contexte local de ce site enregistré
Données locales
Les cibles enregistrées, les listes nommées et les résumés des vérifications récentes restent uniquement dans ce navigateur.
Lab methodology and provenance
Geography: PSI does not provide a test location. A non-regional lab result is diagnostic, not evidence of performance for local users or a target market. Use a regional provider when geography matters.
Lab vs. field comparison
Field data describes real Chrome visits over 28 days; lab data is one simulated run. Use the lab trace to investigate, then use field data to judge the real-user outcome.
What to fix, in order
Elements Lighthouse singled out
Compare a later check
Download this result as a private JSON baseline, then import it after another check to compare the verdict, data source, and metric changes.
Évaluer cet outil
Origin scorecard (mobile field data)
| Origin | Verdict | Worst metric | LCP | INP | CLS |
|---|
Field data is Google's Chrome UX Report — the same 28-day real-user dataset Search uses for the page-experience signal; it updates daily, so repeat checks within 24 hours are served from cache. Lab numbers come from Lighthouse with simulated throttling: expect them to differ from field data and to vary between runs. Lab audits can't measure INP (it needs real users).
À propos de cet outil
Obtenez en une phrase le verdict Core Web Vitals d’une page et la première correction à appliquer. Le contrôle privilégie les données réelles Chrome (CrUX), utilise Lighthouse en repli de laboratoire et affiche mobile et ordinateur côte à côte.
Fonctionnalités
- Données terrain CrUX et source explicitement indiquée pour chaque carte.
- Seuils officiels LCP, INP et CLS avec verdict bon, à améliorer, mauvais ou partiel.
- Diagnostic Lighthouse facultatif pour les pages disposant déjà de données terrain.
- Mode domaines en lot jusqu’à cinq origines avec fiche de score et export CSV.
Fonctionnement
Le contrôle demande d’abord les données terrain de l’URL exacte, puis les données d’origine ou une exécution Lighthouse simulée lorsque CrUX ne fournit aucun échantillon. Il applique les seuils officiels au 75e percentile, affiche la source de chaque carte et priorise la métrique la plus faible.
Limites
- Les données terrain couvrent une fenêtre glissante de 28 jours et peuvent manquer pour les pages nouvelles ou peu visitées.
- Un résultat Lighthouse simulé est diagnostique, non régional, et peut varier entre les exécutions ; il ne représente pas directement les utilisateurs cibles.
- Le passage des seuils ne prouve ni une accessibilité complète ni de bonnes conversions ; lorsque la géographie compte, complétez par un fournisseur régional.
Questions fréquentes
Quels sont les seuils des Core Web Vitals ?
Une page réussit lorsque son score au 75e percentile est « bon » pour les trois métriques : `Largest Contentful Paint` (LCP) à 2,5 secondes ou moins, `Interaction to Next Paint` (INP) à 200 millisecondes ou moins et `Cumulative Layout Shift` (CLS) à 0,1 ou moins. Un LCP supérieur à 4 secondes, un INP supérieur à 500 millisecondes ou un CLS supérieur à 0,25 est « mauvais » ; toute valeur située entre ces deux seuils « doit être améliorée ». L’outil applique exactement ces seuils officiels.
Pourquoi mes scores Core Web Vitals diffèrent-ils de PageSpeed Insights ?
Ils devraient coïncider lorsque les deux outils lisent la même source. L’outil affiche d’abord les données de terrain du Chrome UX Report (CrUX), le même jeu de données issu d’utilisateurs réels qu’utilise la recherche Google, et ne passe à une analyse Lighthouse en laboratoire que lorsqu’une page ne dispose d’aucune donnée de terrain. Les chiffres de laboratoire reposent sur une limitation simulée et varient d’une exécution à l’autre ; un résultat de laboratoire ne correspond donc pas à une mesure de terrain. Si votre valeur PageSpeed Insights provient du laboratoire et la nôtre du terrain, ou inversement, c’est l’origine de l’écart.
Pourquoi le vérificateur indique-t-il « aucune donnée de terrain » pour mon URL ?
CrUX ne publie les données d’une URL que lorsqu’elle reçoit assez de trafic Chrome pour former un échantillon statistiquement fiable sur les 28 derniers jours. Les pages récentes ou peu fréquentées n’atteignent jamais ce seuil. L’outil utilise alors les données de terrain au niveau de l’origine, c’est-à-dire celles de l’ensemble du site, ou une analyse Lighthouse simulée en laboratoire. Chaque carte indique sa source afin d’éviter de confondre les résultats de laboratoire avec ceux d’utilisateurs réels.
Cet outil peut-il mesurer l’INP ?
Il peut publier l’INP issu des données de terrain, car cette métrique est mesurée à partir d’actions d’utilisateurs réels. Il ne peut pas produire de valeur INP à partir d’une analyse en laboratoire : Lighthouse ne dispose d’aucun utilisateur réel pour manipuler la page ; un résultat limité au laboratoire affiche donc « aucun INP de laboratoire » pour cette métrique. Si vous avez besoin d’une valeur INP et que la page ne possède pas de données de terrain, il vous faut du trafic réel ou les outils INP de Chrome DevTools appliqués à vos propres actions.
Quel appareil Google utilise-t-il pour le classement : téléphone ou ordinateur ?
Google évalue l’indicateur d’expérience de page sur téléphone ; l’outil marque donc la carte correspondante comme « utilisée par Google pour le classement ». Lorsqu’une page n’est conforme sur aucun des deux appareils, il désigne la métrique du téléphone comme contrainte déterminante. Les résultats sur ordinateur sont fournis à titre de contexte, mais ils ne déterminent pas l’évaluation du classement sur téléphone.
Problèmes courants et solutions
- Erreur Le LCP est mauvais Solution : Faites passer le LCP sous 2,5 secondes en optimisant l’élément LCP mesuré et son chemin de livraison critique, puis vérifiez avec de nouvelles données de terrain.
- Avertissement Le LCP doit être amélioré Solution : Faites passer le LCP sous 2,5 secondes en donnant la priorité à l’élément LCP mesuré et en supprimant le délai de son chemin de livraison.
- Erreur L’INP est mauvais Solution : Réduisez l’INP sous 200 ms en raccourcissant les tâches d’interaction les plus longues et en réduisant le travail JavaScript sur le fil principal.
- Avertissement L’INP doit être amélioré Solution : Améliorez l’INP sous 200 ms en découpant les gestionnaires d’interaction longs et en cédant le travail du fil principal.
- Erreur Le CLS est mauvais Solution : Réduisez le CLS sous 0.1 en réservant de l’espace pour les éléments qui se déplacent et en empêchant les changements tardifs de police ou de contenu.
- Avertissement Le CLS doit être amélioré Solution : Faites passer le CLS sous 0.1 en ajoutant des tailles stables et des espaces réservés pour les éléments qui bougent après le premier affichage.
- Avertissement Les ressources qui bloquent le rendu peuvent retarder le LCP Solution : Intégrez le CSS critique et différez les feuilles de style ou `scripts` non critiques qui bloquent le rendu de la ressource LCP.
- Avertissement La réponse du serveur peut retarder le LCP Solution : Réduisez le temps de réponse premier du serveur grâce au cache, à un traitement serveur plus rapide et à un CDN proche des utilisateurs avant d’optimiser la ressource LCP.
- Avertissement La diffusion de l’image peut retarder le LCP Solution : Redimensionnez et compressez l’image LCP, servez-la dans une version moderne avec srcset et préchargez-la lorsque sa découverte est tardive.
- Information L’origine critique n’a pas de preconnect Solution : Ajoutez preconnect uniquement pour l’origine tierce critique qui sert la ressource LCP, avec crossorigin lorsque nécessaire.
- Avertissement Le code tiers contribue à l’INP Solution : Différez les gestionnaires de balises, la messagerie, l’analyse et les `scripts` de test non critiques jusqu’à la première action, puis supprimez les fournisseurs inutilisés.
- Avertissement Le travail du fil principal contribue à l’INP Solution : Découpez les longues tâches du fil principal, déplacez les calculs lourds vers un `worker` et réduisez le travail de mise en page synchrone.
- Avertissement Le JavaScript inutilisé contribue à l’INP Solution : Découpez le code par parcours et composant afin que la page ne télécharge, n’analyse et n’exécute que le JavaScript nécessaire à la vue actuelle.
- Avertissement Les éléments qui déplacent la mise en page contribuent au CLS Solution : Donnez aux illustrations, contenus intégrés, annonces et zones injectées signalés des tailles explicites ou des espaces réservés avant leur chargement.
- Avertissement Le chargement des polices contribue au CLS Solution : Préchargez les polices critiques, utilisez des replis compatibles avec les métriques et choisissez un comportement font-display qui évite un changement tardif de mise en page.
- Avertissement Les performances de laboratoire et de terrain diffèrent Solution : Utilisez le profil `Lighthouse` pour diagnostiquer le goulot d’étranglement simulé, puis surveillez la métrique `CrUX` correspondante avant de déclarer ou clôturer une régression d’utilisateurs réels.