Landing pages principales
Monitoriza páginas que presentan el producto, servicio o campaña porque una primera experiencia lenta puede afectar al descubrimiento y la conversión.
Supervisa Core Web Vitals de las páginas importantes
Sigue LCP, CLS y los indicadores de carga de páginas públicas seleccionadas del dominio del proyecto. Consulta cinco métricas por URL y un resumen separado del inicio con Speed Index; comprueba una corrección concreta con un resultado posterior. Son pruebas controladas, no datos de campo de usuarios reales.
Comprobaciones de Core Web Vitals
LCP
Encuentra URL seleccionadas cuyo contenido principal aparece tarde.
CLS
Revisa los desplazamientos inesperados del diseño en las URL seleccionadas.
Mediciones diarias de laboratorio
Anota los valores actuales y revisa un resultado posterior de laboratorio después de una corrección concreta.
Monitoriza Largest Contentful Paint
Largest Contentful Paint mide cuándo aparece la imagen, el bloque de texto o el vídeo apto de mayor tamaño en el área visible de la prueba. Usa el LCP de cada URL monitorizada para elegir qué página necesita una investigación de carga más detallada.
- Screpy muestra LCP en segundos: hasta 2,5 s es bueno; más de 2,5 s y hasta 4 s necesita mejorar; más de 4 s es deficiente.
- Un FCP rápido seguido de un LCP lento indica que apareció contenido antes del elemento principal. Investiga cómo se entrega y se renderiza ese elemento, en lugar de asumir que toda la página estuvo en blanco.
- Confirma la imagen, la fuente o el retraso de renderizado mediante un análisis de rendimiento del desarrollador. El número por sí solo no identifica el elemento ni determina la solución.
example.comLaboratorio
LCP2,1 s
Mide Cumulative Layout Shift
Una página puede cargar rápido y aun así desplazar un botón o un párrafo inesperadamente. Cumulative Layout Shift da a cada URL monitorizada una puntuación de estabilidad en laboratorio para analizar el movimiento por separado de la velocidad de carga.
- CLS no tiene unidad de tiempo: hasta 0,1 es bueno en Screpy; más de 0,1 y hasta 0,25 necesita mejorar; más de 0,25 es deficiente.
- Revisa el espacio reservado para imágenes, anuncios y elementos incrustados, así como los cambios de fuentes. Son posibles causas; la puntuación de Screpy no identifica qué elemento se movió.
- Un CLS bajo durante la carga no descarta desplazamientos posteriores durante la visita. Revisa la interacción real y los datos de campo si el problema aparece después de cargar.
CLS
0,04Comprueba Total Blocking Time
Total Blocking Time ayuda a detectar trabajo del hilo principal que puede retrasar la respuesta a las entradas durante la carga. Lee TBT junto con LCP y FCP: mostrar contenido rápidamente no implica que la página responda con rapidez.
- TBT se muestra en milisegundos: hasta 200 ms es bueno; más de 200 ms y hasta 600 ms necesita mejorar; más de 600 ms es deficiente.
- El tiempo de bloqueo suma las partes de las tareas largas que superan 50 ms dentro del intervalo medido. No es el tiempo total de ejecución de JavaScript.
- Si TBT es alto, analiza las tareas largas y los scripts innecesarios con herramientas de desarrollo antes de cambiar código. El valor del panel no atribuye el retraso a un script concreto.
- TBT no es INP. INP mide interacciones y puede probarse en laboratorio ejecutándolas; esta función de Screpy no proporciona una medición de INP.
example.comLaboratorio
TBT180 ms
Compara FCP y TTFB
First Contentful Paint marca el primer contenido visible; Time to First Byte marca el inicio de la respuesta. Leer ambos para la misma URL ayuda a distinguir un retraso inicial de respuesta del tiempo necesario para mostrar contenido.
- FCP se muestra en segundos: hasta 1,8 s es bueno; más de 1,8 s y hasta 3 s necesita mejorar; más de 3 s es deficiente.
- TTFB se muestra en milisegundos: hasta 800 ms es bueno; más de 800 ms y hasta 1.800 ms necesita mejorar; más de 1.800 ms es deficiente. La conexión, las redirecciones y la respuesta pueden influir.
- Si TTFB es bajo pero FCP es lento, investiga qué retrasa el primer contenido. Si la respuesta es lenta, revisa primero la entrega; ningún valor aislado prueba una causa del servidor o del renderizado.
Laboratorio2100 ms
TTFB450 ms
FCP1100 ms
LCP2100 ms
TBT95 ms
Monitoriza páginas web importantes
Sigue un conjunto manejable de páginas públicas del proyecto en vez de interpretar un resultado de inicio como si describiera todo el sitio. Usa la cuota del proyecto de tu plan en las páginas donde más importan los problemas de carga o diseño.
- La página de inicio se añade al crear el proyecto. Puedes añadir otras URL públicas del dominio del proyecto o sus subdominios cuando el plan permita la monitorización.
- Elige páginas representativas de productos, categorías, artículos y entradas de conversión. Un problema de plantilla repetido puede justificar más investigación, pero una URL probada no mide todas las páginas que usan esa plantilla.
- La entrada normaliza el protocolo y el dominio, añade HTTPS si se omite y elimina fragmentos. Las rutas y los parámetros de consulta siguen siendo relevantes; se rechaza una URL normalizada duplicada.
- Una página añadida espera su primera comprobación programada antes de aparecer en la tabla. Añadir la URL no inicia una prueba inmediata.
- Confirma la eliminación para dejar de seguir una página y liberar su espacio en la cuota. Se elimina el registro monitorizado, no la página de tu sitio ni de Google.
example.comLaboratorio
/1,4 s/shop/linen2,8 s/guides/seo1,9 sRevisa el rendimiento del inicio
El resumen sobre la tabla de URL utiliza la página de inicio comprobada del proyecto. Reúne las mediciones actuales de laboratorio, incluido Speed Index; debajo, la tabla mantiene sus cinco métricas mostradas asociadas a cada URL monitorizada.
- Consulta FCP, LCP, CLS, TTFB, TBT y Speed Index en el resumen del inicio. Son valores de esa página, no una media de las páginas seguidas.
- Speed Index describe cómo se forma el contenido visible durante la carga. Screpy muestra segundos: hasta 3,4 s es bueno; más de 3,4 s y hasta 5,8 s necesita mejorar; más de 5,8 s es deficiente.
- Cada barra representa la medición actual. No es un historial guardado, un porcentaje de visitantes ni el percentil 75 de los datos de campo de Google.
- Si no hay resultado comprobado del inicio, su resumen no está disponible. No se sustituye por el resultado de otra URL monitorizada.
example.comLaboratorio
LCP2,1 s
TBT180 ms
CLS0,04
Sigue las pruebas diarias de laboratorio
Las páginas activas que cumplen los requisitos pueden recibir otra comprobación programada tras un día. Revisa el resultado actual después de un cambio concreto, teniendo en cuenta el plan y la disponibilidad de la comprobación, sin esperar una hora exacta garantizada.
- Ordena los resultados por URL o estado CWV para organizar la revisión. FCP, LCP, CLS, TTFB y TBT se muestran para cada URL probada.
- La etiqueta CWV usa la peor clasificación disponible de LCP, CLS y TBT. PASS indica que esos valores disponibles son buenos; FAIL incluye resultados que necesitan mejorar y deficientes.
- Revisa los valores ausentes aunque la fila muestre PASS. Una métrica ausente no cuenta como medición saludable; la etiqueta no certifica la evaluación de Google con LCP, INP y CLS de campo.
- Sin datos indica que el veredicto de laboratorio no está disponible. Un valor ausente no es cero y una comprobación fallida no demuestra que la página esté bien.
- Anota los valores actuales antes de publicar una corrección y compáralos con un resultado posterior de la misma URL. La tabla muestra resultados actuales, no un historial guardado de antes y después.
Diario09:00
123456789101112131415161718192021
Consulta datos de rendimiento con SEO MCP
Lleva el resumen guardado de laboratorio del inicio a una conversación con IA o una integración REST. Pide una explicación de las mediciones disponibles y una investigación concreta, distinguiendo las pruebas de una solución propuesta.
- Autentícate y selecciona un proyecto al que tengas acceso. El endpoint REST también requiere que Core Web Vitals esté disponible en el plan del proyecto.
- La respuesta contiene la URL del inicio, la hora guardada de la comprobación y los valores disponibles de FCP, LCP, CLS, TTFB, TBT y Speed Index. Son datos del inicio, no una lista de todas las páginas monitorizadas.
- Sin una página de inicio comprobada no hay resumen; las mediciones individuales ausentes siguen sin estar disponibles. Pide al asistente que señale los datos que faltan antes de concluir.
- La herramienta MCP de Core Web Vitals lee datos guardados. No inicia pruebas, añade páginas, identifica el elemento responsable ni convierte TBT en INP.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Habla de Core Web Vitals. Con SEO MCP.
Consulta el resumen guardado de laboratorio del inicio del proyecto mediante SEO MCP. Explica las métricas disponibles con su URL y hora de comprobación y elige qué investigar, sin asumir un informe de todas las páginas ni una prueba nueva.
- Screpy: ¡Hola! Veamos Core Web Vitals para example.com. ¿Qué quieres saber?
- Tú: Explica los resultados guardados de laboratorio del inicio de example.com e indica lo que sigue sin conocerse.
- Screpy: En este ejemplo del inicio, LCP es 3,2 s y necesita mejorar; CLS es 0,04 y bueno. Comprueba la URL y la hora guardadas antes de usar los valores. Estas dos cifras no muestran todas las métricas, no miden INP ni identifican el elemento responsable. Puedo sugerir una investigación, pero no ejecutar una prueba nueva. Valores de ejemplo del inicio en laboratorio: LCP: 3,2 s. CLS: 0,04.
- Tú: Conviértelo en un breve plan de acción.
- Screpy: Separaré los hallazgos de las recomendaciones. Revisa las pruebas, elige un cambio y comprueba después los resultados. Tus próximos pasos: Revisa: Comprueba la fuente y fecha de cada hallazgo.. Decide: Elige el primer cambio.. Verifica: Compara los resultados después del cambio..
- Tú: ¿Puedes explicar las pruebas con palabras sencillas?
- Screpy: Sí. Pregunta por un resultado compatible y explicaré qué muestra, de dónde viene y qué sigue siendo incierto. Los datos ausentes siguen sin estar disponibles; las recomendaciones no son correcciones automáticas.
Convierte una URL lenta en una corrección de rendimiento comprobable.
Mantén estables la URL y el método de medición, usa la métrica más débil para enfocar la investigación y valida un cambio con una comprobación posterior.
-
Elige una URL pública representativa
Elige URL públicas del dominio del proyecto o sus subdominios. Empieza con el inicio, una entrada de conversión y una URL representativa de una plantilla importante, dentro de la cuota del proyecto.
-
Deja que la comprobación programada establezca una referencia
Las URL activas elegibles reciben comprobaciones programadas recurrentes. Tras el primer intento, revisa los valores disponibles de FCP, LCP, CLS, TTFB y TBT de la URL probada; el resumen separado del inicio también incluye Speed Index.
-
Sigue la métrica débil hasta una hipótesis concreta
Usa la métrica débil para elegir una investigación concreta: LCP para la carga principal, CLS para movimientos inesperados, TBT para tareas bloqueantes y FCP con TTFB para la carga inicial. Speed Index del inicio aporta contexto del progreso visual, no una causa demostrada.
-
Cambia una causa y vuelve a medir
Anota los valores actuales antes de un cambio concreto, mantén la URL y compara un resultado programado posterior. El panel muestra mediciones actuales: guarda por separado tu referencia previa e investiga cambios repetidos, sin considerar una fluctuación aislada como prueba.
Monitoriza las páginas donde una regresión tendría mayor impacto.
Un conjunto pequeño de URL representativas es más fácil de investigar que un panel lleno de páginas de poco valor. Empieza por recorridos críticos y plantillas reutilizables.
Plantillas compartidas
Elige una URL representativa de producto, categoría, artículo o documentación para descubrir problemas que puedan repetirse en la misma plantilla.
Rutas de conversión
Mantén visibles las páginas de precios, registro, captación y entrada al checkout cuando scripts, embeds, experimentos o etiquetas de terceros cambien su rendimiento.
Páginas sensibles a lanzamientos
Sigue las URL afectadas por rediseños, cambios de framework, nuevos medios, actualizaciones del tag manager o cambios de entrega antes de ampliar el patrón.
Interpreta los resultados de laboratorio sin exagerarlos.
Screpy está diseñado para que las comprobaciones recurrentes sean accionables. Estos límites mantienen la precisión cuando la pregunta real son los datos de campo, la causa o el impacto en posiciones.
Datos de laboratorio, no de campo
Screpy ejecuta pruebas controladas de páginas. El resultado no representa el conjunto de usuarios reales de Chrome UX Report o Google Search Console.
TBT no es INP
TBT describe trabajo bloqueante durante el período de carga medido. INP necesita mediciones de interacciones y puede probarse en laboratorio ejecutándolas, pero esta función de Screpy no informa INP ni sustituye las pruebas de respuesta de usuarios reales.
Un veredicto no es una causa raíz
Una métrica deficiente indica dónde investigar. Confirma el elemento, solicitud, script, plantilla o comportamiento del servidor antes de decidir el cambio.
El rendimiento no garantiza posiciones
Una buena experiencia de página ayuda a usuarios y buscadores, pero no sustituye contenido relevante, rastreabilidad, indexación, enlaces u otras señales.
Usa el flujo de rendimiento que responda a tu pregunta.
Monitoriza URL seleccionadas para resultados de laboratorio recurrentes, audita el sitio completo para encontrar patrones técnicos o lee la metodología antes de comparar con datos de campo.
Monitoriza URL públicas seleccionadas del proyecto con comprobaciones recurrentes; consulta cinco métricas en la tabla y seis en el resumen separado del inicio.
Rastrea el sitio para revisar enlaces, imágenes y problemas de página alrededor de una URL o plantilla afectada. Usa los hallazgos como contexto técnico, no como una traza de rendimiento.
Comprende alcance, tiempos y límites de los datos de laboratorio de Screpy antes de compararlos con informes de usuarios reales.
Documentación de Screpy
Aprende a interpretar las comprobaciones de rendimiento
Usa la guía para seleccionar URL, leer las métricas de laboratorio y distinguirlas de los datos de campo. Guarda una referencia previa por separado antes de comparar una mejora concreta con un resultado posterior.
Respuestas a tus preguntas sobre Core Web Vitals.
Comprende datos de laboratorio y de campo, LCP, CLS, TBT, métricas de velocidad, comprobaciones diarias, selección de URL, veredictos y límites de las afirmaciones sobre experiencia de página.
¿Qué páginas debería monitorizar primero?
Empieza por el inicio, páginas públicas importantes de entrada, entradas de conversión y una URL representativa por plantilla relevante. Las URL añadidas deben pertenecer al dominio del proyecto o sus subdominios y caber en la cuota del plan. Una muestra de plantilla no prueba todas sus páginas.
¿Qué métricas son las Core Web Vitals oficiales?
Google define actualmente Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift como Core Web Vitals. Screpy mide LCP y CLS en laboratorio e informa de TBT como diagnóstico junto con FCP, TTFB y Speed Index. No presenta TBT como INP.
¿Con qué frecuencia se comprueban las URL monitorizadas?
Las URL activas elegibles pueden recibir otra comprobación programada después de un día. El plan del proyecto y la disponibilidad de la comprobación influyen en su finalización; no se garantiza un resultado a la misma hora diaria. Una URL nueva aparece en la tabla después del primer intento.
¿Los datos de Core Web Vitals de Screpy se basan en usuarios reales?
No. Screpy informa de mediciones controladas para la URL comprobada. Los datos de campo de Chrome UX Report o Google Search Console reflejan visitas reales durante un periodo móvil y pueden variar según dispositivos, redes, ubicación y comportamiento.
¿Por qué Screpy muestra TBT en lugar de INP?
Esta función mide la carga y ofrece TBT como diagnóstico de bloqueo; no mide las interacciones necesarias para INP. INP puede probarse en laboratorio ejecutando interacciones, pero TBT no es INP y no describe todas las interacciones posteriores a la carga.
¿Mejorar Core Web Vitals garantiza mejores posiciones?
No. Google recomienda buenos Core Web Vitals para usuarios y búsqueda, pero la experiencia de página es solo una parte de muchas señales. El contenido relevante puede posicionar con una experiencia más débil y una página rápida no garantiza posiciones.
¿Qué mide la monitorización de Core Web Vitals de Screpy?
La tabla de URL de Screpy muestra FCP, LCP, CLS, TTFB y TBT de laboratorio. El resumen del inicio comprobado añade Speed Index. La tabla usa PASS/FAIL; las respuestas autenticadas de API y MCP también incluyen la URL del inicio y la hora guardada de comprobación. No son mediciones de usuarios reales.
¿Un PASS de Screpy significa que la URL supera los Core Web Vitals de Google?
No. El veredicto de la tabla usa la peor clasificación disponible de LCP, CLS y TBT en laboratorio, y puede haber valores ausentes. Google evalúa datos de usuarios reales, incluido INP, con reglas propias de cobertura y percentiles. Revisa las métricas disponibles y el informe de campo correspondiente antes de concluirlo.