Landing pages principales
Surveillez les pages qui présentent le produit, le service ou la campagne : une première expérience lente peut affecter découverte et conversion.
Surveillez les Core Web Vitals des pages importantes
Suivez LCP, CLS et les indicateurs de chargement de pages publiques choisies sur le domaine du projet. Consultez cinq métriques par URL et un résumé d’accueil distinct avec Speed Index, puis évaluez une correction ciblée avec un résultat ultérieur. Ce sont des tests contrôlés, pas des données de terrain d’utilisateurs réels.
Contrôles Core Web Vitals
LCP
Repérez les URL choisies dont le contenu principal apparaît tardivement.
CLS
Examinez les décalages de mise en page inattendus sur les URL choisies.
Mesures de laboratoire quotidiennes
Notez les valeurs actuelles et consultez un résultat de laboratoire ultérieur après une correction ciblée.
Surveillez Largest Contentful Paint
Largest Contentful Paint mesure quand la plus grande image, le plus grand bloc de texte ou la vidéo admissible apparaît dans la zone visible du test. Le LCP de chaque URL surveillée vous aide à choisir la page dont le chargement mérite un examen approfondi.
- Screpy affiche le LCP en secondes : jusqu’à 2,5 s, il est bon ; au-delà de 2,5 s et jusqu’à 4 s, il doit être amélioré ; au-delà de 4 s, il est mauvais.
- Un FCP rapide suivi d’un LCP lent indique que du contenu était visible avant l’élément principal. Examinez sa livraison et son affichage plutôt que de supposer que toute la page est restée vide.
- Confirmez l’image, la police ou le retard d’affichage concerné avec une analyse de performances menée par un développeur. Le chiffre seul ne désigne ni l’élément ni la correction à apporter.
example.comLaboratoire
LCP2,1 s
Mesurez Cumulative Layout Shift
Une page peut charger rapidement tout en déplaçant un bouton ou un paragraphe de manière inattendue. Cumulative Layout Shift attribue à chaque URL surveillée un score de stabilité en laboratoire pour étudier les mouvements séparément de la vitesse de chargement.
- CLS n’a pas d’unité de temps : jusqu’à 0,1, il est bon dans Screpy ; au-delà de 0,1 et jusqu’à 0,25, il doit être amélioré ; au-delà de 0,25, il est mauvais.
- Examinez l’espace réservé aux images, publicités et contenus intégrés, ainsi que les changements de police. Ce sont des pistes ; le score Screpy ne désigne pas l’élément qui a bougé.
- Un CLS faible pendant le chargement n’exclut pas les déplacements survenant plus tard dans la visite. Vérifiez l’interaction réelle et les données de terrain si le problème apparaît après le chargement.
CLS
0,04Vérifiez Total Blocking Time
Total Blocking Time aide à repérer le travail du thread principal susceptible de retarder la réponse aux entrées pendant le chargement. Lisez TBT avec LCP et FCP : afficher rapidement le contenu ne garantit pas une réponse rapide de la page.
- TBT est affiché en millisecondes : jusqu’à 200 ms, il est bon ; au-delà de 200 ms et jusqu’à 600 ms, il doit être amélioré ; au-delà de 600 ms, il est mauvais.
- Le temps de blocage additionne les portions des tâches longues dépassant 50 ms dans la fenêtre de mesure. Ce n’est pas la durée totale d’exécution de JavaScript.
- Si TBT est élevé, analysez les tâches longues et les scripts inutiles avec les outils de développement avant de modifier le code. La valeur du tableau de bord n’attribue pas le retard à un script précis.
- TBT n’est pas INP. INP mesure des interactions et peut être testé en laboratoire en les exécutant ; cette fonctionnalité Screpy ne fournit pas de mesure INP.
example.comLaboratoire
TBT180 ms
Comparez FCP et TTFB
First Contentful Paint marque le premier contenu visible ; Time to First Byte marque le début de la réponse. Lire ces deux valeurs pour la même URL aide à distinguer un retard initial de réponse du temps nécessaire pour afficher le contenu.
- FCP est affiché en secondes : jusqu’à 1,8 s, il est bon ; au-delà de 1,8 s et jusqu’à 3 s, il doit être amélioré ; au-delà de 3 s, il est mauvais.
- TTFB est affiché en millisecondes : jusqu’à 800 ms, il est bon ; au-delà de 800 ms et jusqu’à 1 800 ms, il doit être amélioré ; au-delà de 1 800 ms, il est mauvais. Connexion, redirections et réponse peuvent l’influencer.
- Si TTFB est faible mais FCP lent, cherchez ce qui retarde le premier affichage. Si la réponse est lente, examinez d’abord la livraison ; aucune valeur isolée ne prouve une cause côté serveur ou affichage.
Laboratoire2 100 ms
TTFB450 ms
FCP1 100 ms
LCP2 100 ms
TBT95 ms
Surveillez les pages importantes
Suivez un ensemble raisonnable de pages publiques du projet au lieu de considérer un seul résultat d’accueil comme celui du site entier. Utilisez le quota du projet prévu par votre abonnement pour les pages où les problèmes de chargement ou de mise en page comptent le plus.
- La page d’accueil est ajoutée à la création du projet. Ajoutez d’autres URL publiques du domaine du projet ou de ses sous-domaines si votre abonnement permet la surveillance.
- Choisissez des pages représentatives de produit, catégorie, article et entrée de conversion. Un problème de modèle répété peut justifier une analyse plus large, mais tester une URL ne mesure pas toutes les pages de ce modèle.
- La saisie normalise le protocole et l’hôte, ajoute HTTPS s’il manque et supprime les fragments. Chemins et paramètres de requête restent significatifs ; une URL normalisée en double est refusée.
- Une page ajoutée attend sa première vérification programmée avant d’apparaître dans le tableau. L’ajout de l’URL ne lance pas de test immédiat.
- Confirmez le retrait pour arrêter la surveillance et libérer une place dans le quota. Cela retire l’enregistrement surveillé, pas la page de votre site ni de Google.
example.comLaboratoire
/1,4 s/shop/linen2,8 s/guides/seo1,9 sConsultez les performances de l’accueil
Le résumé au-dessus du tableau utilise la page d’accueil vérifiée du projet. Il réunit les mesures actuelles de laboratoire, dont Speed Index ; le tableau dessous conserve ses cinq métriques affichées pour chaque URL surveillée.
- Consultez FCP, LCP, CLS, TTFB, TBT et Speed Index dans le résumé de l’accueil. Ce sont ses valeurs, pas une moyenne des pages suivies.
- Speed Index décrit la vitesse d’apparition progressive du contenu pendant le chargement. Screpy affiche des secondes : jusqu’à 3,4 s, il est bon ; au-delà de 3,4 s et jusqu’à 5,8 s, il doit être amélioré ; au-delà de 5,8 s, il est mauvais.
- Chaque barre représente la mesure actuelle. Ce n’est ni un historique enregistré, ni un pourcentage de visiteurs, ni le 75e percentile des données de terrain de Google.
- Sans résultat vérifié pour l’accueil, son résumé est indisponible. Aucun résultat d’une autre URL surveillée ne le remplace.
example.comLaboratoire
LCP2,1 s
TBT180 ms
CLS0,04
Suivez les tests quotidiens de laboratoire
Les pages actives admissibles deviennent éligibles à une nouvelle vérification programmée après un jour. Examinez le résultat actuel après une modification ciblée, en tenant compte de l’abonnement et de la disponibilité du test plutôt que d’une heure exacte garantie.
- Triez les résultats par URL ou statut CWV pour organiser votre examen. FCP, LCP, CLS, TTFB et TBT restent visibles pour chaque URL testée.
- Le badge CWV utilise la moins bonne classification disponible de LCP, CLS et TBT. PASS signifie que cet ensemble disponible est bon ; FAIL couvre les résultats à améliorer et mauvais.
- Examinez les valeurs manquantes même si la ligne indique PASS. Une métrique absente ne compte pas comme mesure saine, et le badge ne certifie pas l’évaluation Google fondée sur LCP, INP et CLS de terrain.
- Aucune donnée signifie que le verdict de laboratoire est indisponible. Une valeur manquante n’est pas zéro, et une vérification échouée ne prouve pas que la page est saine.
- Notez les valeurs actuelles avant de publier une correction, puis comparez un résultat ultérieur de la même URL. Le tableau montre les résultats actuels, pas un historique enregistré avant et après.
Quotidien09:00
123456789101112131415161718192021
Lisez les données avec SEO MCP
Intégrez le résumé de laboratoire enregistré pour l’accueil à une conversation IA ou une intégration REST. Demandez une explication des mesures disponibles et une investigation ciblée, en distinguant les preuves de la correction proposée.
- Authentifiez-vous et choisissez un projet accessible. L’accès REST exige aussi que Core Web Vitals soit disponible dans l’abonnement du projet.
- La réponse contient l’URL d’accueil, l’heure de vérification enregistrée et les valeurs disponibles de FCP, LCP, CLS, TTFB, TBT et Speed Index. Elle concerne l’accueil, pas la liste de toutes les pages surveillées.
- Sans accueil vérifié, aucun résumé n’est fourni ; les mesures individuelles manquantes restent indisponibles. Demandez à l’assistant de signaler les lacunes avant de conclure.
- L’outil MCP Core Web Vitals lit les données enregistrées. Il ne lance pas de test, n’ajoute pas de pages, n’identifie pas l’élément responsable et ne transforme pas TBT en INP.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Parlez de Core Web Vitals. Avec SEO MCP.
Lisez le résumé de laboratoire enregistré pour l’accueil du projet via SEO MCP. Expliquez les métriques disponibles avec leur URL et heure de vérification, puis choisissez une investigation sans supposer un rapport de toutes les pages ou un nouveau test.
- Screpy: Bonjour ! Regardons Core Web Vitals pour example.com. Que souhaitez-vous savoir ?
- Vous: Explique les résultats de laboratoire enregistrés pour l’accueil d’example.com et précise ce qui reste inconnu.
- Screpy: Dans cet exemple d’accueil, LCP vaut 3,2 s et doit être amélioré ; CLS vaut 0,04 et est bon. Vérifiez l’URL et l’heure enregistrées avant d’utiliser les valeurs. Ces deux chiffres ne montrent pas toutes les métriques, ne mesurent pas INP et n’identifient pas l’élément responsable. Je peux proposer une investigation, pas exécuter un nouveau test. Exemple de valeurs d’accueil en laboratoire: LCP: 3,2 s. CLS: 0,04.
- Vous: Transforme cela en un court plan d’action.
- Screpy: Je séparerai les constats des recommandations. Examinez les preuves, choisissez une modification puis vérifiez les résultats. Vos prochaines étapes: Examiner: Vérifier la source et la date de chaque constat.. Décider: Choisir la première modification.. Vérifier: Comparer les résultats après la modification..
- Vous: Peux-tu expliquer les preuves simplement ?
- Screpy: Oui. Interrogez-moi sur un résultat pris en charge pour comprendre ce qu’il montre, sa source et les incertitudes. Les données manquantes restent indisponibles ; les recommandations ne sont pas des corrections automatiques.
Transformer une URL lente en correction de performance testable.
Gardez l’URL et la méthode de mesure stables, utilisez la métrique la plus faible pour cibler l’analyse et validez une modification lors d’un contrôle ultérieur.
-
Choisir une URL publique représentative
Choisissez des URL publiques du domaine du projet ou de ses sous-domaines. Commencez par l’accueil, une entrée de conversion et une URL représentative d’un modèle important, dans la limite du quota du projet.
-
Laisser le contrôle planifié établir une référence
Les URL actives admissibles reçoivent des vérifications programmées récurrentes. Après la première tentative, examinez les valeurs disponibles de FCP, LCP, CLS, TTFB et TBT pour l’URL testée ; le résumé distinct de l’accueil inclut aussi Speed Index.
-
Suivre la métrique faible jusqu’à une hypothèse ciblée
Choisissez une investigation à partir de la métrique faible : LCP pour le contenu principal, CLS pour les mouvements inattendus, TBT pour le travail bloquant, FCP et TTFB pour le début du chargement. Speed Index de l’accueil décrit la progression visuelle sans prouver une cause.
-
Modifier une cause et mesurer à nouveau
Notez les valeurs avant une modification ciblée, gardez l’URL stable et comparez un résultat programmé ultérieur. Le tableau de bord montre les mesures actuelles : conservez séparément votre référence et examinez les changements répétés plutôt qu’une fluctuation isolée.
Surveillez les pages où une régression aurait le plus d’impact.
Un petit ensemble d’URL représentatives est plus facile à analyser qu’un tableau rempli de pages sans valeur. Commencez par les parcours critiques et les modèles réutilisables.
Modèles de pages partagés
Choisissez une URL représentative de produit, catégorie, article ou documentation pour révéler les problèmes qui se répètent dans le même modèle.
Parcours de conversion
Gardez visibles les pages de prix, d’inscription, de lead et d’entrée de paiement lorsque scripts, embeds, expériences ou tags tiers changent leurs performances.
Pages sensibles aux releases
Suivez les URL touchées par une refonte, un changement de framework, de nouveaux médias, une mise à jour du tag manager ou une modification de diffusion avant un déploiement plus large.
Interprétez les résultats de laboratoire sans les exagérer.
Screpy rend les contrôles récurrents exploitables. Ces limites gardent le résultat exact lorsque la question porte sur les données terrain, la cause ou l’impact SEO.
Données de laboratoire, pas de terrain
Screpy exécute des tests contrôlés. Le résultat ne représente pas le jeu de données d’utilisateurs réels de Chrome UX Report ou Google Search Console.
TBT n’est pas INP
TBT décrit le travail bloquant pendant la période de chargement mesurée. INP nécessite des mesures d’interactions et peut être testé en laboratoire en les exécutant ; cette fonction Screpy ne fournit toutefois pas INP et ne remplace pas les preuves de réactivité des utilisateurs réels.
Un verdict n’est pas une cause racine
Une mauvaise métrique indique où chercher. Confirmez l’élément, la requête, le script, le modèle ou le serveur avant de décider quoi modifier.
La performance ne garantit pas le classement
Une bonne expérience aide les utilisateurs et la recherche, mais ne remplace ni contenu pertinent, ni explorabilité, ni indexation, ni liens ni autres signaux.
Choisissez le flux de performance adapté à la question.
Surveillez des URL sélectionnées pour des résultats récurrents, auditez le site pour des motifs techniques répétés ou lisez la méthodologie avant de comparer avec des données terrain.
Surveillez des URL publiques du projet avec des tests récurrents : cinq métriques dans le tableau et six dans le résumé distinct de l’accueil.
Explorez le site pour rechercher les liens, images et problèmes de page autour d’une URL ou d’un modèle concerné. Utilisez ces constats comme contexte technique, pas comme une trace de performance.
Comprenez le périmètre, le calendrier et les limites des données de laboratoire Screpy avant de les comparer à des rapports terrain.
Documentation Screpy
Apprenez à interpréter les contrôles de performance en laboratoire
Utilisez le guide pour choisir les URL, lire les métriques de laboratoire et les distinguer des données de terrain. Notez une référence séparément avant de comparer une amélioration ciblée à un résultat ultérieur.
Réponses à vos questions sur le monitoring Core Web Vitals.
Comprenez données de laboratoire et de terrain, LCP, CLS, TBT, métriques de vitesse, contrôles quotidiens, sélection des URL, verdicts et limites des affirmations sur l’expérience de page.
Quelles pages dois-je surveiller en premier ?
Commencez par l’accueil, les pages publiques importantes, les entrées de conversion et une URL représentative de chaque modèle important. Les URL ajoutées doivent appartenir au domaine du projet ou à ses sous-domaines et respecter le quota. Un échantillon de modèle ne teste pas toutes ses pages.
Que mesure le monitoring Core Web Vitals de Screpy ?
Le tableau d’URL Screpy affiche FCP, LCP, CLS, TTFB et TBT en laboratoire. Le résumé de l’accueil vérifié ajoute Speed Index. Le tableau utilise PASS/FAIL ; les réponses authentifiées API et MCP fournissent aussi l’URL d’accueil et l’heure de vérification enregistrée. Ce ne sont pas des mesures d’utilisateurs réels.
À quelle fréquence les URL surveillées sont-elles contrôlées ?
Les URL actives admissibles peuvent recevoir une autre vérification programmée après un jour. L’abonnement du projet et la disponibilité du test influencent son achèvement ; aucune heure quotidienne identique n’est garantie. Une nouvelle URL apparaît dans le tableau après sa première tentative de vérification.
Un PASS Screpy signifie-t-il que l’URL réussit les Core Web Vitals de Google ?
Non. Le verdict utilise la moins bonne classification disponible de LCP, CLS et TBT en laboratoire et peut conserver des valeurs manquantes. Google évalue des données d’utilisateurs réels, dont INP, avec ses propres règles de couverture et de percentiles. Examinez les métriques disponibles et le rapport de terrain pertinent avant de conclure.
Pourquoi Screpy affiche-t-il TBT au lieu d’INP ?
Cette fonction mesure le chargement et fournit TBT comme diagnostic de blocage ; elle ne mesure pas les interactions nécessaires à INP. INP peut être testé en laboratoire en exécutant des interactions, mais TBT n’est pas INP et ne décrit pas toutes les interactions après chargement.
Quelles métriques sont les Core Web Vitals officielles ?
Google définit actuellement Largest Contentful Paint, Interaction to Next Paint et Cumulative Layout Shift comme Core Web Vitals. Screpy mesure LCP et CLS en laboratoire et fournit TBT comme diagnostic avec FCP, TTFB et Speed Index. Il ne présente pas TBT comme INP.
Améliorer les Core Web Vitals garantit-il un meilleur classement ?
Non. Google recommande de bons Core Web Vitals pour les utilisateurs et la recherche, mais l’expérience de page n’est qu’un ensemble de signaux parmi d’autres. Un contenu pertinent peut se classer malgré une expérience plus faible et une page rapide n’est pas garantie de se classer.
Les données Core Web Vitals de Screpy sont-elles basées sur de vrais utilisateurs ?
Non. Screpy fournit des mesures contrôlées pour l’URL testée. Les données terrain de Chrome UX Report ou Google Search Console reflètent de vraies visites sur une période glissante et peuvent différer selon appareils, réseaux, zones géographiques et comportements.