Pages de revenus et d’inscription
Surveillez les entrées de paiement, pages de prix, formulaires de contact et parcours d’inscription où une expérience lente peut interrompre une visite importante.
Surveillez PageSpeed sur les URL importantes de votre site
Surveillez les URL publiques importantes avec des contrôles récurrents en laboratoire. Examinez chargement, acheminement de la réponse, blocages et stabilité dans Core Web Vitals de Screpy, avec six mesures séparées pour l'accueil.
Indicateurs de mesure PageSpeed
FCP
Voyez quand le premier contenu apparaît sur une URL choisie.
TTFB
Examinez le délai jusqu'au premier octet de réponse, y compris connexion et acheminement.
TBT et Speed Index
Examinez les blocages du thread principal et la progression visuelle de l'accueil.
Choisir les pages à surveiller
Organisez le suivi PageSpeed autour des pages par lesquelles vos visiteurs arrivent réellement. Screpy inclut la page d'accueil du projet et permet d'ajouter des URL publiques de son domaine ou de ses sous-domaines.
- Consacrez le quota restant de votre forfait aux pages de destination importantes, aux produits et aux exemples représentatifs de chaque modèle.
- Le chemin et les paramètres de requête distinguent les URL surveillées ; les fragments sont supprimés et les doublons refusés.
- Testez les pages d'entrée publiques sans attendre du test de laboratoire qu'il termine une connexion, un achat ou une inscription.
- Retirez une URL devenue inutile au suivi : ses contrôles cessent, mais la page du site n'est pas supprimée.
example.comLaboratoire
/1,4 s/shop/linen2,8 s/guides/seo1,9 sEffectuer des contrôles PageSpeed quotidiens
Gérez ces contrôles dans l'écran Core Web Vitals de votre projet Screpy. Les contrôles récurrents permettent de suivre les pages sélectionnées lorsque les contenus, modèles et scripts évoluent.
- Une URL ajoutée apparaît dans le tableau après sa première tentative de contrôle ; son ajout ne produit pas de résultat immédiat.
- Les URL actives des projets éligibles peuvent être reprogrammées lorsqu'au moins un jour s'est écoulé depuis la tentative enregistrée.
- Le délai de traitement et les mesures disponibles peuvent varier. Le tableau n'affiche ni date de contrôle ni commande de nouveau test immédiat.
Quotidien09:00
123456789101112131415161718192021
Examiner les résultats par URL
Lisez les mesures à côté de l'URL exacte avant de définir vos priorités. Le statut fournit un premier repère ; les valeurs montrent différentes étapes du chargement.
- Chaque ligne affiche FCP et LCP en secondes, TTFB et TBT en millisecondes, et CLS sans unité.
- Triez les pages surveillées par URL ou statut ; les colonnes de mesures ne sont pas triables.
- Le statut de laboratoire retient la moins bonne classification disponible de LCP, CLS ou TBT. Un FCP ou TTFB lent peut mériter une analyse même si le statut est favorable.
- Une valeur manquante est une mesure indisponible ; une réussite partielle n'est pas l'évaluation Google des Core Web Vitals des utilisateurs réels.
example.comLaboratoire
LCP2,1 s
TBT180 ms
CLS0,04
Investiguer les retards de chargement
Utilisez l'ensemble des mesures pour choisir une investigation ciblée. Screpy fournit des signaux de temps et de stabilité ; votre équipe examine l'implémentation pour confirmer une cause.
- Un TTFB élevé peut justifier l'examen des redirections, de la connexion, du cache et de l'acheminement de la réponse ; il ne mesure pas uniquement l'exécution du serveur.
- Un TTFB faible avec un FCP lent peut orienter vers le rendu initial ; un LCP tardif, vers le contenu principal et sa livraison.
- Un TBT élevé invite à examiner les tâches longues du thread principal. Il mesure leurs portions bloquantes, pas toute la durée JavaScript ni INP.
- Un CLS élevé invite à examiner les déplacements inattendus, par exemple un espace non réservé pour du contenu chargé ensuite.
- Utilisez une trace de performance du navigateur pour identifier l'élément ou le script concerné ; le tableau Screpy ne détermine pas ces causes.
Laboratoire2 100 ms
TTFB450 ms
FCP1 100 ms
LCP2 100 ms
TBT95 ms
Vérifier le Speed Index de l'accueil
La vue d'ensemble de l'accueil ajoute Speed Index à FCP, LCP, CLS, TTFB et TBT. Ce résultat enregistré permet de rapprocher la progression visuelle des étapes du premier contenu et du contenu le plus grand.
- Speed Index décrit la rapidité d'apparition du contenu visible, pas la fin du chargement complet ou d'un parcours utilisateur.
- Speed Index figure dans la vue d'ensemble de l'accueil, pas sur chaque ligne d'URL surveillée.
- Cette vue représente l'accueil lui-même, pas une moyenne du site, un percentile de visiteurs ni une tendance historique.
Speed Index2,1 s
0,8 s
1,4 s
2,1 s
Vérifier les changements de performance
Un contrôle ultérieur peut aider à évaluer une mise en ligne ciblée, mais l'écran des résultats actuels n'est pas une archive avant-après. Conservez votre propre référence pour comparer.
- Notez l'URL, les valeurs disponibles et la version de la page avant de modifier un modèle, une stratégie d'images ou un script.
- Effectuez un changement significatif et comparez la même URL à un contrôle ultérieur disponible ; une autre requête peut désigner une page différente.
- Tenez compte des caches, contenus tiers et variations de mesure avant d'attribuer une nouvelle valeur à votre mise en ligne.
- Cette vue n'offre ni historique à plusieurs points, ni alerte de performance, ni rapport automatique de cause à effet.
Avant62→Après87
NotesExpliquer PageSpeed avec SEO MCP
Demandez à un assistant IA d'interpréter les mesures enregistrées disponibles de l'accueil via SEO MCP. Rattachez l'explication à l'URL et à l'heure de contrôle retournées, sans la considérer comme un nouveau test.
- L'outil en lecture seule retourne les valeurs disponibles FCP, LCP, CLS, TTFB, TBT et Speed Index de l'accueil.
- Un résultat d'accueil ou une mesure manquante reste indisponible ; l'outil ne lui substitue pas une autre page surveillée.
- SEO MCP ne lance pas de contrôle de performance, ne récupère pas toutes les URL ajoutées et ne corrige pas automatiquement le site.
- La SEO API authentifiée expose aussi la vue enregistrée de l'accueil, sous réserve de l'accès au projet et de l'éligibilité du forfait pour cet endpoint.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Parlez de Monitoring PageSpeed. Avec SEO MCP.
Interprétez les mesures enregistrées de l'accueil avec SEO MCP. L'outil lit les résultats disponibles ; il ne lance pas de nouveau test et ne récupère pas chaque URL surveillée.
- Screpy: Bonjour ! Regardons Monitoring PageSpeed pour example.com. Que souhaitez-vous savoir ?
- Vous: Explique les valeurs FCP et TTFB enregistrées pour example.com. Que dois-je investiguer ?
- Screpy: Dans cet exemple enregistré de l'accueil, FCP vaut 2,4 s et TTFB 950 ms. Examinez la connexion et l'acheminement de la réponse, puis le rendu initial. Ces valeurs suggèrent une investigation sans identifier la cause. Confirmez l'URL et l'heure enregistrée avant toute comparaison. Exemple enregistré de l'accueil: FCP: 2,4 s. TTFB: 950 ms.
- 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 un résultat lent en contrôle de performance maîtrisé.
Réduisez les suppositions en gardant l’URL, le périmètre et la prochaine modification précis. PageSpeed Monitoring fournit les preuves de laboratoire ; l’analyse reste celle de votre équipe.
-
Choisir une URL publique représentative
Choisissez, dans votre quota disponible, une page publique du domaine du projet ou d'un sous-domaine, liée à une campagne, une entrée organique ou un modèle important.
-
Lire l'URL et les mesures disponibles
Confirmez l'URL exacte, les valeurs disponibles et le statut de laboratoire. Le tableau n'affiche pas de date de contrôle ; des valeurs absentes ne prouvent pas une mesure complète.
-
Formuler une hypothèse ciblée
Utilisez FCP, LCP, TTFB, TBT et CLS du tableau pour choisir l'investigation. Consultez Speed Index uniquement dans la vue de l'accueil pour la progression visuelle.
-
Modifier une cause et mesurer à nouveau
Gardez la même URL et le même périmètre, notez le résultat initial, effectuez une modification significative et utilisez un contrôle ultérieur pour vérifier la direction attendue.
Surveillez les pages qui représentent une vraie décision métier.
Un ensemble d’URL plus petit et intentionnel est plus facile à interpréter qu’une liste sans priorité. Couvrez les parcours et modèles importants avant les pages marginales.
Landing pages de campagne
Gardez les pages publicitaires, e-mail, lancement et saisonnières dans le monitoring pendant qu’elles reçoivent du trafic.
Pages d’entrée organiques
Choisissez des articles, catégories et produits représentatifs qui amènent les visiteurs issus de la recherche sur le site.
Modèles partagés
Surveillez une URL représentative de chaque modèle important afin d’analyser les changements de mise en page ou de script avec un résultat de laboratoire ciblé.
Sachez ce que le résultat de monitoring ne prouve pas.
Utilisez Screpy comme flux de mesure récurrent en laboratoire. Gardez séparés données terrain, diagnostic de cause, rapports historiques, alertes et résultats métier sauf vérification par une autre source.
Les données de laboratoire ne sont pas des données terrain
Screpy fournit des mesures synthétiques issues d’un contrôle maîtrisé. Ne les présentez pas comme l’expérience de vos vrais visiteurs.
Les résultats actuels exigent une référence séparée
Notez les valeurs séparément pour les comparer plus tard. Cette vue n'offre ni graphique historique à plusieurs points, ni colonne de date de contrôle, ni alertes de performance.
Une métrique n’est pas la cause racine
Un résultat faible de FCP, LCP, TTFB, TBT, Speed Index ou CLS indique où chercher mais ne prouve pas la modification nécessaire.
PageSpeed n’est pas une garantie de classement
Des pages rapides peuvent aider les visiteurs et l’expérience, mais un verdict de laboratoire ne garantit ni classement, ni trafic, ni engagement, ni conversions.
Utilisez le flux de performance adapté à la question.
Surveillez des URL sélectionnées pour leurs résultats actuels, apprenez le lien avec Core Web Vitals ou auditez le site lorsqu’une métrique ne suffit pas à expliquer un problème répété.
Effectuez des contrôles récurrents sur vos pages publiques sélectionnées et consultez leurs mesures disponibles dans Core Web Vitals.
Séparez les diagnostics de laboratoire des données terrain et comprenez LCP, CLS, TBT et l’INP réel.
Ajoutez le contexte du site avec les constats de crawl, liens, images et SEO on-page ; un audit ne remplace pas une trace de performance du navigateur.
Documentation Screpy
Apprenez à surveiller les performances des pages
Apprenez à choisir les URL, interpréter les mesures disponibles, distinguer les données terrain et noter une référence pour un contrôle ultérieur.
Réponses à vos questions sur le monitoring PageSpeed.
Comprenez la couverture des URL, l'éligibilité quotidienne, les mesures du tableau et de l'accueil, le statut de laboratoire et les limites des comparaisons.
Que mesure Screpy PageSpeed Monitoring ?
PageSpeed Monitoring utilise Core Web Vitals. Les lignes des URL sélectionnées affichent FCP, LCP, TTFB, TBT et CLS avec un statut de laboratoire. La vue de l'accueil ajoute Speed Index. Le tableau n'affiche ni date de contrôle ni score PageSpeed de 0–100.
Screpy affiche-t-il un score Google PageSpeed ?
Cet écran n'affiche pas de score Lighthouse ou Google PageSpeed de 0–100. Son statut retient la moins bonne classification disponible de LCP, CLS ou TBT. FCP et TTFB sont des diagnostics séparés ; une réussite ne certifie pas les Core Web Vitals des utilisateurs réels.
Le monitoring PageSpeed identifie-t-il la cause exacte d’un résultat lent ?
Non. Une métrique faible oriente l’analyse mais ne prouve pas la cause racine. Examinez l’URL, le modèle, les ressources, les scripts, le chemin de diffusion et l’audit du site avant de choisir une correction.
Les résultats PageSpeed de Screpy sont-ils des données de laboratoire ou de terrain ?
Ce sont des données synthétiques recueillies lors d’un test contrôlé. Les données terrain décrivent l’expérience de vrais visiteurs ; les deux sources doivent être interprétées séparément.
Quelles URL dois-je surveiller en premier ?
Commencez par l'accueil inclus et des pages publiques représentatives de campagne, produit, tarifs ou contenu sur le domaine du projet ou ses sous-domaines. Le quota du forfait détermine le nombre d'URL ajoutables ; un contrôle public ne parcourt pas un parcours utilisateur authentifié.
À quelle fréquence Screpy contrôle-t-il une URL surveillée ?
Les URL actives des projets éligibles peuvent être reprogrammées après au moins un jour depuis la tentative enregistrée. Ajouter une URL ne génère pas de résultat immédiat ; l'heure de fin peut varier. Le tableau n'affiche aucune colonne de date de contrôle.
Le monitoring PageSpeed comprend-il des alertes ou des graphiques historiques ?
Cette vue présente les résultats actuels disponibles par URL et une vue enregistrée de l'accueil. Elle n'offre ni alertes de performance ni graphique historique à plusieurs points. Notez une référence séparément avant de comparer un contrôle ultérieur.
Un meilleur résultat PageSpeed garantit-il de meilleurs classements ou plus de conversions ?
Non. La vitesse peut soutenir l’expérience et la qualité de la page, mais classements et conversions dépendent de nombreux facteurs. Traitez le résultat comme un élément de décision, pas comme une garantie.