Largest Contentful Paint (LCP)
Estima cuándo termina de renderizarse en el laboratorio la imagen o el bloque de texto visible más grande. Usa un resultado lento para investigar el contenido principal, los recursos y la entrega.
Supervisa Core Web Vitals de las páginas importantes
Ejecuta comprobaciones de laboratorio diarias para URL públicas seleccionadas y mantén LCP, CLS, FCP, TTFB, TBT, Speed Index, el veredicto actual y la hora de comprobación junto a tu flujo de SEO técnico. Detecta regresiones y vuelve a probar correcciones concretas sin confundir mediciones sintéticas con datos reales de usuarios.
TL;DR
Demasiado largo; no leído
Mostrar resumen Ocultar resumen
TL;DR
Demasiado largo; no leído
¿Qué hace la monitorización de Core Web Vitals de Screpy?
Screpy ejecuta comprobaciones de laboratorio recurrentes para URL públicas seleccionadas. Informa de LCP y CLS junto con FCP, TTFB, TBT, Speed Index, un veredicto de laboratorio y la frescura de la comprobación para que los equipos encuentren regresiones, investiguen una causa concreta y vuelvan a medir sin confundir resultados sintéticos con datos reales.
Elige el alcance de monitorización
- La página de inicio se incluye al configurar un proyecto para monitorización.
- Puedes añadir URL públicas adicionales dentro del límite del plan actual.
- Cada URL activa puede volver a comprobarse después de un día.
- La URL exacta y la hora de la última comprobación permanecen visibles junto al resultado.
Lee las señales principales del laboratorio
- Largest Contentful Paint estima cuándo termina de renderizarse el contenido visible principal.
- Cumulative Layout Shift mide los movimientos inesperados durante la prueba.
- Un veredicto de laboratorio ayuda a identificar primero las URL que requieren atención.
- El veredicto es un diagnóstico sintético, no la evaluación de datos de campo de Google.
Usa diagnósticos complementarios
- First Contentful Paint aporta contexto del renderizado inicial.
- Time to First Byte ayuda a enfocar la investigación en el retraso de la respuesta inicial.
- Total Blocking Time muestra tareas que bloquean el hilo principal en el laboratorio.
- Speed Index resume la rapidez con que aparece el contenido visible durante la prueba.
Interpreta el resultado con seguridad
- Compara los datos de laboratorio con la misma URL y el mismo método de medición.
- Total Blocking Time no es Interaction to Next Paint.
- Una métrica débil orienta la investigación, pero no demuestra la causa raíz.
- Una mejor experiencia de página ayuda a los usuarios, pero no garantiza posiciones ni tráfico.
Lee las métricas de laboratorio detrás de cada página comprobada.
El informe separa carga, estabilidad visual, respuesta del servidor y diagnósticos del hilo principal para que un único veredicto no oculte la señal que necesita investigación.
Cumulative Layout Shift (CLS)
Mide el movimiento visual inesperado durante la prueba. Imágenes sin dimensiones, embeds, fuentes y contenido tardío son lugares habituales para investigar.
First Contentful Paint (FCP)
Comprueba cuándo se pinta el primer texto, imagen u otro contenido. FCP ayuda a localizar retrasos iniciales antes de que aparezca el contenido principal.
Time to First Byte (TTFB)
Revisa el retraso de la respuesta inicial del servidor observado por la prueba. Un valor lento puede apuntar a hosting, caché, redirecciones o trabajo del backend.
Total Blocking Time (TBT)
Mide cuánto tiempo las tareas del hilo principal bloquean la respuesta en el laboratorio. TBT es un diagnóstico útil, pero no es la métrica real de usuario Interaction to Next Paint.
Speed Index
Resume la rapidez con que aparece el contenido visible durante la prueba, en lugar de depender de un único hito de renderizado.
Veredicto de rendimiento de laboratorio
Usa los veredictos Bueno, Necesita mejorar o Deficiente para encontrar las URL seleccionadas que requieren atención primero. Resume resultados de laboratorio, no la evaluación de usuarios de Google.
Frescura de la URL y la comprobación
Mantén cada resultado asociado a su URL pública exacta y a la hora de la última comprobación para no usar una medición antigua o ajena en una decisión actual.
Mantén las páginas importantes en un ciclo de pruebas recurrente.
Añade URL públicas representativas y revisa el resultado más reciente después de cada comprobación diaria. Cada veredicto permanece vinculado a la URL probada y a la hora de recopilación.
- Monitorizar la página de inicio y URL seleccionadas de alto valor
- Ordenar las páginas comprobadas por veredicto o URL
- Usar la hora de la última comprobación antes de actuar
Separa Core Web Vitals de los diagnósticos complementarios.
Revisa LCP y CLS junto con FCP, TTFB, TBT y Speed Index. Screpy identifica TBT como diagnóstico de respuesta en laboratorio, no como INP real de usuarios.
- Inspeccionar mediciones de carga y estabilidad visual
- Usar métricas de respuesta y renderizado para enfocar la siguiente comprobación
- Mantener separadas las afirmaciones de laboratorio y de campo
Pasa de una métrica débil a un cambio comprobable.
Usa la métrica actual más débil para decidir si revisar renderizado de contenido, reserva de espacio, respuesta del servidor, recursos o trabajo del hilo principal. Cambia una causa probable y vuelve a medir la misma URL.
- Priorizar páginas críticas para el negocio y plantillas compartidas
- Investigar la página y la ruta de entrega antes de cambiar código
- Validar la corrección enfocada con un resultado programado posterior
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.
- 01
Elige una URL pública representativa
Empieza por la página de inicio, una página de conversión o una URL de una plantilla importante. Monitorizar todas las páginas de poco valor crea ruido antes que información.
- 02
Deja que la comprobación programada establezca una referencia
Screpy comprueba diariamente las URL supervisadas elegibles y registra el veredicto, métricas complementarias, URL probada y hora actuales.
- 03
Sigue la métrica débil hasta una hipótesis concreta
Usa LCP, CLS, FCP, TTFB, TBT y Speed Index para decidir si investigar primero renderizado, reserva de espacio, respuesta, recursos o trabajo del hilo principal.
- 04
Cambia una causa y vuelve a medir
Publica la corrección relevante más pequeña, mantén estable la URL supervisada y usa el siguiente resultado programado para comprobar si mejoró la medición.
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.
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.
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 ayuda a diagnosticar la respuesta en laboratorio. INP requiere interacciones reales, por lo que un resultado TBT no debe presentarse como una medición INP.
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.
Ejecuta comprobaciones diarias para URL públicas seleccionadas y revisa veredicto, métricas y frescura.
Rastrea el sitio completo para encontrar patrones repetidos de páginas, recursos, renderizado y aspectos técnicos en una URL o plantilla afectada.
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
Sigue la guía de Screpy para elegir URL, leer cada métrica con su URL y fecha, distinguir datos de laboratorio y de campo y probar una mejora concreta.
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é mide la monitorización de Core Web Vitals de Screpy?
Screpy ejecuta comprobaciones basadas en laboratorio para URL públicas seleccionadas. Informa de LCP, CLS, FCP, TTFB, TBT, Speed Index, un veredicto de laboratorio y la última hora de comprobación.
¿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.
¿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.
¿Por qué Screpy muestra TBT en lugar de INP?
Interaction to Next Paint depende de interacciones reales y es una métrica de campo. Total Blocking Time se puede medir en un laboratorio controlado y ayuda a revelar trabajo del hilo principal, pero no son métricas intercambiables.
¿Con qué frecuencia se comprueban las URL monitorizadas?
Las URL activas pueden volver a comprobarse después de un día. La cola, la disponibilidad y el plan pueden afectar a cuándo está listo el resultado; utiliza la hora de la última comprobación antes de actuar.
¿Qué páginas debería monitorizar primero?
Empieza por la página de inicio, landing pages con mucho tráfico, entradas de conversión y una URL representativa de cada plantilla importante. Añade páginas donde una regresión afectaría a muchos visitantes o se reutiliza la misma implementación.
¿Un veredicto Bueno de Screpy significa que la URL supera Core Web Vitals de Google?
No necesariamente. Screpy resume una prueba de laboratorio, mientras la evaluación de Google usa LCP, INP y CLS de usuarios reales cuando hay datos suficientes. Usa el veredicto para orientar las pruebas y compáralo con el informe de campo cuando necesites una evaluación real.
¿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.
Mantén las comprobaciones de rendimiento enfocadas en las páginas importantes.
Elige URL públicas representativas, establece una referencia diaria de laboratorio, investiga la métrica más débil y vuelve a medir después de un cambio concreto.