Informe de Core Web Vitals en Search Console: cómo leerlo

El informe de Core Web Vitals en Search Console no mide el rendimiento de una página en el instante en que la abres: mide cómo la experimentaron usuarios reales de Chrome durante los últimos 28 días, agregada por grupos de URL con características similares. Por eso puede marcar un grupo como "necesita mejora" aunque esa misma URL, probada ahora en una herramienta de laboratorio, salga en verde. Son dos mediciones distintas que responden preguntas distintas.

Esta guía explica cómo leer el informe tal como aparece en Search Console: qué son los grupos de URL, por qué algunas páginas no muestran ningún dato, qué separa los estados "con problemas" y "necesita mejora", qué hace el botón "Validar corrección" y por qué cualquier cambio tarda semanas en reflejarse. No es una guía para arreglar un LCP lento —eso merece su propio artículo—; el objetivo aquí es entender el informe en sí.

Qué mide realmente el informe (y qué no)

El informe se alimenta del Chrome UX Report (CrUX), el conjunto de datos que Google construye a partir de usuarios reales que han dado su consentimiento para compartir métricas de uso mientras navegan con Chrome. Esto lo diferencia de herramientas de laboratorio como PageSpeed Insights o Lighthouse, que cargan tu página una sola vez, en condiciones controladas, y dan un diagnóstico inmediato pero sintético. El informe de Search Console, en cambio, es una fotografía agregada de tráfico real: dispositivos distintos, conexiones distintas, momentos del día distintos.

Las tres métricas que componen la evaluación son Largest Contentful Paint (LCP, velocidad de carga percibida), Interaction to Next Paint (INP, capacidad de respuesta ante una interacción) y Cumulative Layout Shift (CLS, estabilidad visual mientras carga la página). El informe evalúa cada URL —o grupo de URLs— contra las tres a la vez; basta con que una de las tres esté mal para que el grupo no se considere "bueno", aunque las otras dos estén perfectas.

El informe se divide siempre en dos vistas separadas, móvil y escritorio, porque el comportamiento real de los usuarios en cada plataforma es distinto: las conexiones móviles son más variables, los procesadores suelen ser menos potentes y eso se refleja directamente en LCP e INP. Es habitual que la vista de escritorio de un sitio esté en verde mientras la de móvil muestra páginas "con problemas"; no es un error del informe, es la realidad del tráfico.

• LCP: cuánto tarda en pintarse el elemento más grande visible del viewport inicial.
• INP: cuánto tarda la página en responder visualmente a un clic, una tecla o un toque, medido durante toda la visita, no solo en la carga.
• CLS: cuánto se mueven los elementos de la página después de que el usuario ya empezó a verla.

Los grupos de URL: por qué no ves cada página por separado

Search Console no reporta el estado de cada URL de tu sitio de forma individual; para ver datos de campo de una URL concreta hay que recurrir a PageSpeed Insights, que consulta CrUX por URL cuando hay suficientes visitas. En el informe general agrupa las páginas por patrón de URL y por plantilla, porque CrUX necesita un volumen mínimo de visitas reales para poder informar con algo de confianza sobre una URL; la mayoría de páginas individuales de un sitio nunca alcanzan ese volumen por sí solas, así que Google las agrupa con otras que comparten estructura —por ejemplo, todas las fichas de producto de una categoría, o todos los artículos de blog bajo el mismo patrón de plantilla.

Esto tiene una consecuencia práctica que sorprende a quien mira el informe por primera vez: si arreglas la imagen que causaba un LCP lento en una sola página de un grupo, el grupo entero no mejora, porque el problema real casi siempre vive en la plantilla compartida —un banner, una fuente, un script de terceros— y no en el contenido específico de esa URL. Al entrar en un grupo, Search Console muestra un puñado de URLs de ejemplo, no la lista completa; sirven para identificar qué tienen en común, no como lista exhaustiva de páginas afectadas.

El error habitual es optimizar solo la URL de ejemplo pensando que eso arregla el grupo entero. Si el problema es de plantilla, hay que corregir la plantilla y validar sobre el grupo completo; si es específico de esa URL, el resto del grupo puede seguir mal aunque esa página mejore.

Por qué aparecen URLs sin datos

Debajo de las categorías "bueno", "necesita mejora" y "con problemas" hay una cuarta situación que no es un estado de rendimiento: URLs que simplemente no aparecen en ningún grupo, por falta de datos suficientes. Esto ocurre cuando CrUX no ha recogido el volumen mínimo de visitas de Chrome necesario para calcular una métrica con confianza estadística sobre esa URL o ese grupo dentro de la ventana de 28 días.

Las causas más comunes son tres. La primera es que la página es nueva: como el informe se calcula sobre una ventana móvil de 28 días, una URL publicada ayer no tendrá datos hasta acumular tráfico real dentro de esa ventana, sin importar cuánto tiempo lleve indexada. La segunda es que la página recibe poco tráfico de Chrome específicamente: puede tener miles de visitas por otros canales y seguir sin aparecer, porque CrUX solo cuenta sesiones de Chrome con el reporte de uso activado. La tercera es que la URL nunca llegó a agruparse por no compartir suficiente patrón con otras páginas del sitio.

La ausencia de datos no significa que la página esté bien ni que esté mal: significa que Search Console no tiene base para opinar. Si necesitas un diagnóstico de esa URL hoy mismo, la vía es una herramienta de laboratorio, sabiendo que mide un escenario simulado y no el comportamiento real de tus visitantes.

Las categorías: bueno, necesita mejora y con problemas

Cada métrica tiene dos umbrales documentados que separan las tres franjas, evaluados sobre el percentil 75 de las visitas reales dentro de la ventana de 28 días —es decir, el valor que el 75% de las visitas igualó o mejoró—:

• LCP: bueno hasta 2,5 segundos; necesita mejora entre 2,5 y 4 segundos; con problemas por encima de 4 segundos.
• INP: bueno hasta 200 milisegundos; necesita mejora entre 200 y 500 milisegundos; con problemas por encima de 500 milisegundos.
• CLS: bueno hasta 0,1; necesita mejora entre 0,1 y 0,25; con problemas por encima de 0,25.

El estado que domina y qué significa cada franja

El estado que ves en el informe para un grupo de URLs es el peor de los tres, no un promedio. Un grupo con LCP y CLS perfectos pero con INP en la franja "con problemas" aparece como "con problemas", sin más: el informe no pondera las métricas ni les da un peso relativo entre sí, exige que las tres superen el umbral de "bueno" para calificar el grupo completo como bueno.

La diferencia entre "necesita mejora" y "con problemas" no es solo de grado en el número: en la práctica indica cuántos usuarios reales están sufriendo el problema. Un grupo en "necesita mejora" suele significar que una parte sustancial de las visitas —pero no la mayoría— cae en un rango incómodo; "con problemas" indica que el percentil 75 completo ya está en zona mala, lo que en términos llanos quiere decir que al menos una cuarta parte de tus visitas reales, y probablemente más, tuvo una experiencia clasificada como pobre.

Cómo interpretar el gráfico de tendencia

El informe incluye un gráfico temporal que muestra la evolución del número de URLs en cada categoría, y aquí es donde más se malinterpreta el desfase de 28 días. Cada punto del gráfico no es "cómo estaba el sitio ese día": es el promedio de los 28 días anteriores, actualizado a diario. Al día siguiente de una corrección, el gráfico apenas se mueve, porque un solo día de datos buenos representa como mucho una veintiochoava parte de la ventana; el resto sigue siendo el comportamiento previo.

Esto significa que, contado desde el día del despliegue, el gráfico tarda hasta 28 días en reflejar por completo el nuevo comportamiento, y durante ese tiempo la línea se mueve de forma gradual, no en escalón. Es un error frecuente revisar el informe a los tres o cuatro días de un cambio, ver que sigue en rojo y concluir que la corrección no funcionó; lo que hay que mirar en esos primeros días es la dirección de la línea, no su valor absoluto.

El mismo mecanismo funciona al revés y explica caídas que no tienen que ver con ningún cambio de código: una campaña de marketing que trae de golpe mucho tráfico móvil desde redes más lentas, un pico de visitas desde un país con peor infraestructura, o simplemente un cambio en la mezcla de dispositivos de tus visitantes puede empeorar el percentil 75 sin que nadie haya tocado una línea del sitio. Antes de investigar el código ante una caída repentina, vale la pena revisar si el origen del tráfico cambió en esa misma ventana.

El botón "Validar corrección", paso a paso

Dentro de cada grupo de URLs con problemas, Search Console ofrece un botón para iniciar una validación una vez crees haber corregido la causa. No es un botón que "aplique" nada ni que fuerce un recálculo instantáneo: pone en marcha un proceso de monitorización que dura hasta 28 días, durante el cual Search Console vuelve a comprobar periódicamente si las URLs de ese grupo siguen mostrando el problema en los datos reales de CrUX conforme estos se renuevan.

El proceso pasa por estados visibles en la interfaz: primero aparece como validación no iniciada; al pulsar el botón pasa a validación en curso, y ahí permanece mientras se acumulan datos suficientes dentro de la ventana. Al final, el resultado es aprobado, si el grupo ya cumple el umbral de "bueno", o no aprobado, si siguen sobrando URLs en la franja mala. Un resultado no aprobado no borra el trabajo hecho: indica que el problema persiste en una proporción suficiente del grupo, y se puede corregir de nuevo y volver a validar.

Un matiz importante: iniciar la validación es sobre todo un mecanismo de seguimiento dentro de la propia interfaz. No es un paso necesario para que el cambio "cuente" de cara a los datos de CrUX ni a cómo se evalúa la página como señal de posicionamiento; esa evaluación ocurre de forma continua con o sin el botón. La validación existe para dar una fecha de referencia y un veredicto claro, no para activar nada por sí misma.

Cómo usar este informe en tu flujo de trabajo

El informe de Search Console es el punto de partida para decidir qué merece atención, no la herramienta para diagnosticar la causa exacta. Una vez identificado un grupo problemático, el siguiente paso natural es llevar una URL representativa de ese grupo a una herramienta de laboratorio que desglose la métrica en sus componentes —qué recurso concreto retrasa el LCP, qué script bloquea el hilo principal antes de una interacción—, porque el informe de Search Console dice qué grupo falla y en qué métrica, pero no dice por qué.

Para priorizar entre varios grupos con problemas, el tamaño del grupo suele ser mejor guía que la gravedad aparente del número: un grupo pequeño muy por encima del umbral afecta a menos páginas que un grupo grande apenas en "necesita mejora", y en sesiones reales impactadas puede ser este segundo el que merezca ir primero. Revisar por separado móvil y escritorio evita optimizar la vista que ya está bien mientras la que realmente sufre —casi siempre la móvil— queda sin tocar.

Por último, conviene tratar el historial de validaciones como un registro de qué se intentó y cuándo, útil para detectar regresiones: si un grupo que ya había sido validado como aprobado vuelve a aparecer con problemas meses después, eso normalmente señala un cambio posterior —una nueva librería, un widget añadido, un cambio de plantilla— y no un fallo de la corrección original.