Core Web Vitals para principiantes: cómo medir y mejorar LCP, INP y CLS

Las Core Web Vitals miden tres aspectos de una visita: cuánto tarda en aparecer el contenido visible más grande, con qué rapidez responde la página a una interacción y si su diseño se mueve inesperadamente. Las métricas actuales son Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Empieza por los resultados de usuarios reales y utiliza después una grabación controlada del navegador para identificar el elemento, la interacción o el cambio de diseño que causa el problema.

Una página puede parecer terminada y responder mal a un toque. También puede reaccionar inmediatamente mientras un anuncio desplaza hacia abajo el párrafo que estás leyendo. Son problemas distintos. Tratarlos como una única puntuación genérica de velocidad dificulta innecesariamente la optimización.

No basta con preguntar si tu sitio es rápido. Lo útil es determinar qué parte de la visita falla, a qué visitantes afecta y qué pruebas demostrarían que el cambio ha servido.

Lee las tres métricas antes de interpretar la puntuación general

La metodología de Google para los umbrales de Core Web Vitals establece objetivos separados para la carga, la capacidad de respuesta y la estabilidad visual. Estos umbrales corresponden a los valores de las métricas, no a la puntuación de rendimiento coloreada de Lighthouse.

LCP sigue la imagen o el contenido de texto de mayor tamaño que puede participar en la medición y que aparece en el área visible durante la carga. Puede ser una fotografía de producto, el título de un artículo o un bloque de texto destacado. No indica cuándo termina la descarga de todas las imágenes. Un logotipo pequeño que aparece pronto no compensa la llegada tardía del contenido principal.

INP describe el retraso entre una interacción válida y la siguiente actualización visual. Cuentan los clics, los toques y las interacciones de teclado; desplazarse por la página no constituye esa misma medición. El valor registrado suele reflejar la interacción más lenta de la visita, con un tratamiento de valores extremos cuando hay muchas interacciones. Incluye la espera del hilo principal, la ejecución de los controladores de eventos y la preparación del siguiente fotograma.

CLS es una puntuación sin unidades. Describe los movimientos inesperados del contenido visible, teniendo en cuenta cuánto espacio de la ventana afectan y qué distancia recorren los elementos. Utiliza la mayor ráfaga válida de desplazamientos, en lugar de sumar todos los movimientos de una visita de duración indefinida. Se excluyen algunos movimientos posteriores a una entrada reciente del usuario, pero eso no convierte en inocuo cualquier cambio de diseño provocado por una interacción.

Estas diferencias explican por qué una intervención rara vez resuelve todo. Comprimir la imagen principal puede ayudar a la carga, pero no elimina el JavaScript costoso de un botón de filtrado. Reservar espacio para un elemento incrustado estabiliza el diseño sin acelerar necesariamente su script.

Entiende qué indica el percentil 75

Las evaluaciones de Core Web Vitals utilizan el percentil 75, normalmente abreviado p75. Si ordenas los valores registrados del más rápido al más lento, p75 marca el valor por debajo del cual, o igual al cual, se sitúan aproximadamente tres cuartas partes de las experiencias medidas. No es la media ni representa tu última visita personal.

Imagina, solo como ejemplo, un conjunto de visitas en el que la mayoría de las personas ve la página rápidamente, pero una minoría considerable espera mucho más. La media puede ocultar esa desigualdad. Un percentil permite comprobar si una parte amplia de los visitantes cumple el objetivo sin basar toda la evaluación en unos pocos casos extremos.

Evalúa por separado las poblaciones de móviles y ordenadores. Un diseño adaptable puede utilizar la misma URL en ambos dispositivos y, aun así, entregar imágenes distintas, mostrar otros controles y ejecutarse en hardware diferente. Un buen resultado de escritorio no demuestra que los visitantes móviles tengan la misma experiencia.

Para una evaluación completa de las tres métricas, los resultados p75 correspondientes deben cumplir los tres umbrales buenos. Las mediciones ausentes requieren un tratamiento distinto. En particular, una visita sin una interacción válida no genera un valor INP. No rellenes ese hueco con un cero en una hoja de cálculo: indicaría una respuesta instantánea realmente medida.

Las herramientas de Google también aplican sus propias reglas sobre suficiencia de datos. PageSpeed Insights puede evaluar LCP y CLS cuando no dispone de suficientes datos INP. Lee la evaluación real y su cobertura, sin inventar el valor ausente ni suponer que todas las herramientas muestran la información de la misma manera.

Distingue un informe de usuarios reales de una prueba controlada

Los datos de campo describen visitas registradas. Los datos de laboratorio describen una prueba controlada. Ambos son útiles, pero responden a preguntas distintas.

Chrome User Experience Report, o CrUX, agrega experiencias de Chrome que cumplen sus requisitos. Su API presenta un período de recopilación móvil de 28 días. PageSpeed Insights utiliza CrUX en su sección de usuarios reales y ejecuta Lighthouse en su sección de laboratorio para analizar una página en condiciones concretas. Las dos secciones pueden discrepar sin que ninguna esté equivocada.

Una ejecución de laboratorio puede cargar la página de inicio sin una elección de consentimiento, sin una sesión iniciada y sin interacciones. Tus visitantes pueden cerrar un aviso, abrir la navegación, filtrar productos, desplazarse hasta un vídeo incrustado y volver a una página almacenada en caché. Esos recorridos revelan trabajo que una prueba limitada a la carga nunca activa.

También puede suceder lo contrario. Una prueba de laboratorio con recursos limitados puede parecer peor que la experiencia de buena parte de tu público. Eso justifica investigar las condiciones, no descartar el resultado. La prueba puede revelar un cuello de botella real que adquiere importancia con dispositivos o conexiones más lentos.

CrUX tampoco representa todos los navegadores ni a todos los visitantes. Las páginas necesitan suficiente tráfico apto y deben cumplir los requisitos de inclusión. La ausencia de un informe significa que faltan datos, no que la página sea rápida o lenta. Google no publica un número universal de visitantes que garantice la inclusión.

Consulta nuestra guía sobre datos de campo y laboratorio cuando los informes discrepen. Antes de comparar cifras, anota la URL, la categoría de dispositivo, el período de recopilación y si el resultado corresponde a una URL o al origen completo.

Elige el informe que responda a tu pregunta

PageSpeed Insights es un punto de partida útil para una URL pública. Revisa primero la sección de usuarios reales, si existe. Comprueba si describe la página solicitada o utiliza datos del origen. Un origen agrupa páginas con el mismo esquema, nombre de host y puerto; no diagnostica individualmente cada plantilla.

Después revisa la sección de laboratorio. Sus diagnósticos y recomendaciones señalan causas que conviene investigar. No constituyen una lista de descuentos independientes sobre la puntuación, y no debes sumar sus ahorros estimados como si fueran una mejora garantizada. Varias recomendaciones pueden afectar al mismo retraso subyacente.

Search Console ayuda a encontrar grupos de URL con problemas de experiencia similares. Un problema de grupo resulta especialmente útil cuando una plantilla compartida afecta a muchos artículos o productos. Abre URL representativas e inspecciona la implementación común, sin asumir que modificar un único ejemplo resuelve todo el grupo.

Chrome DevTools permite investigar la secuencia real. Graba la carga para examinar LCP. Graba interacciones para analizar la respuesta. Observa los eventos de desplazamiento de diseño mientras reproduces contenido tardío, avisos o elementos incrustados. Guarda las condiciones junto con las notas para que otra persona pueda reproducir el hallazgo.

Tu propia monitorización de usuarios reales, normalmente llamada RUM, añade detalles que los informes agregados no ofrecen. Puede asociar una regresión con una versión desplegada o una plantilla, según la cobertura y las decisiones de privacidad de la implementación. No esperes una coincidencia exacta con CrUX: pueden diferir las poblaciones, las API del navegador y los detalles de medición.

Diagnostica un LCP lento siguiendo el recurso

Identifica primero el elemento LCP de la grabación, utilizando el tamaño de ventana pertinente. Una imagen grande en escritorio puede convertirse en una imagen pequeña o un bloque de texto en móvil. El recurso que optimices debe ser el que realmente determina la métrica.

Cuando LCP corresponde a una imagen, revisa cuatro etapas: el tiempo hasta el primer byte de HTML, el retraso hasta iniciar la solicitud de la imagen, la descarga y la espera entre el final de la descarga y el renderizado. Un archivo pequeño puede aparecer tarde si JavaScript incorpora su URL solo después de inicializar la aplicación.

Las primeras comprobaciones son concretas. Comprueba si la imagen se descubre en el HTML inicial, si está marcada incorrectamente para carga diferida y si su configuración adaptable selecciona un archivo innecesariamente grande. Averigua también si una hoja de estilos o un script impide mostrarla una vez descargada.

Este ejemplo proporciona dimensiones y prioridad de descarga alta a una imagen importante. Los archivos mencionados deben existir en tu proyecto.

<img
  src="/images/article-hero-960.webp"
  srcset="/images/article-hero-960.webp 960w,
          /images/article-hero-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A request moving from a browser to a server"
>

La ausencia de loading="lazy" es deliberada. fetchpriority es una indicación de planificación, no una orden que anule todas las decisiones del navegador. Resérvala para recursos realmente importantes, en lugar de asignar prioridad alta a toda una galería.

Si el propio HTML llega tarde, optimizar imágenes no elimina la espera previa al descubrimiento de la página. Investiga el tiempo de respuesta del servidor y TTFB, especialmente las redirecciones, los fallos de caché y el trabajo de la aplicación. Si la imagen llega pronto, pero sigue invisible, investiga el renderizado y el trabajo del hilo principal.

Diagnostica un INP deficiente reproduciendo una interacción real

Elige una acción concreta: abrir el menú de navegación, seleccionar una variante de producto, enviar una búsqueda o desplegar una sección extensa. Grábala después de la carga y mientras se ejecutan los scripts habituales en segundo plano. Una grabación sin interacciones no explica por qué una interacción real tarda.

El retraso puede empezar antes del controlador. Otro script puede ocupar el hilo principal y dejar la entrada esperando. También puede producirse dentro del controlador, por ejemplo si un filtro recalcula una colección grande, o después, cuando el navegador calcula estilos, distribuye los elementos y pinta una actualización amplia.

Trata esas fases por separado. Eliminar una devolución de llamada redundante de analítica no resuelve una operación costosa de diseño. Acortar el controlador no elimina la tarea que impide que empiece. La traza debe identificar la fase dominante antes de elegir una solución.

Primero reduce el trabajo innecesario. Después divide el que no necesita terminar antes de ofrecer una respuesta visual. Ceder el control entre fragmentos permite al navegador atender otras tareas; trasladar cálculos adecuados que no usan el DOM a un worker los saca del hilo principal. Ninguna técnica justifica un algoritmo que procesa repetidamente datos innecesarios.

Una prueba de navegación habitual de Lighthouse utiliza Total Blocking Time como indicador de laboratorio del bloqueo del hilo principal. TBT no es INP y no debe introducirse en el campo INP de un comprobador. Las grabaciones interactivas controladas sí pueden medir la latencia de interacción: la limitación corresponde a la prueba que solo carga la página, no a toda medición de laboratorio.

Diagnostica CLS identificando qué provocó el movimiento

El elemento que se mueve puede ser la víctima, no la causa. Si un párrafo baja, revisa qué apareció encima. Un aviso insertado después o una imagen sin dimensiones reservadas pueden modificar el espacio disponible para ese párrafo.

Empieza por las imágenes y los vídeos. Sus dimensiones o una relación de aspecto adecuada permiten reservar espacio antes de que llegue el contenido. Revisa después anuncios, reproductores incrustados, recomendaciones y otros elementos asíncronos. Un marcador de posición necesita un tamaño realista en cada punto de adaptación, no solo una animación decorativa de carga.

Las fuentes también requieren atención. La fuente de reserva y la fuente web descargada pueden tener distintas anchuras y métricas verticales. El intercambio puede cambiar los saltos de línea y desplazar el contenido cercano. Elige un comportamiento de carga adecuado y considera ajustar las métricas de reserva, sin asumir que mostrar texto inmediatamente elimina todo riesgo de movimiento.

No soluciones un desplazamiento haciendo la página inaccesible. Las superposiciones fijas pueden tapar contenido o controles, especialmente en pantallas estrechas o con texto ampliado. Tras modificar un aviso o un espacio reservado, prueba el teclado, el zoom y el espacio disponible para la tarea principal.

Una grabación limitada a recargar puede omitir desplazamientos posteriores. Déjala activa mientras te desplazas, abres los controles pertinentes y esperas el contenido que suele llegar después. Compara el movimiento registrado con el problema de campo antes de darlo por resuelto.

Crea una rutina de medición pequeña y repetible

Elige páginas representativas en lugar de probar solo el inicio. Incluye un artículo, una categoría, una página de producto u otra plantilla importante. Anota los componentes compartidos: navegación, fuentes, espacios publicitarios y controles de consentimiento.

Conserva una referencia inicial para cada categoría de dispositivo pertinente. Guarda el informe, la fecha, la versión probada y los valores importantes. Repite las pruebas comparables de laboratorio bajo las mismas condiciones. Un único resultado favorable no permite distinguir una mejora de la variación normal.

En un proyecto que ya integra el paquete web-vitals, este módulo de diagnóstico registra las métricas que comunica el navegador. Es un ejemplo de depuración local, no un sistema de analítica completo.

import { onCLS, onINP, onLCP } from 'web-vitals';

function logMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id
  });
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

Algunas devoluciones de llamada dependen del ciclo de vida de la página o de las interacciones realizadas. No esperes tres valores significativos nada más abrir una pestaña inactiva. La recopilación en producción necesita un endpoint, agregación, decisiones de muestreo y controles de privacidad apropiados; la salida de consola no proporciona nada de eso.

Después del despliegue, vigila posibles regresiones y deja que el período de recopilación incorpore nuevas visitas. Una ventana móvil contiene experiencias anteriores y posteriores hasta que transcurre suficiente tiempo. Ejecutar Lighthouse repetidamente no acelera ese proceso ni genera el tráfico de CrUX que falta.

Sitúa Core Web Vitals en su contexto SEO

Google Search Central indica que sus sistemas de posicionamiento utilizan Core Web Vitals, pero también aclara que buenos resultados no garantizan posiciones altas. Siguen importando la relevancia, el contenido útil y otros aspectos de la experiencia. No existe una equivalencia documentada entre aumentar la puntuación de Lighthouse y subir posiciones.

Esto facilita priorizar. Si los visitantes no pueden usar un filtro, corrígelo porque bloquea su tarea. Si una imagen destacada tarda en una plantilla muy utilizada, resuelve la causa compartida. Evita consumir todo el presupuesto para ganar un punto sintético cuando el contenido importante sigue siendo difícil de encontrar o utilizar.

Convierte el primer hallazgo en un cambio concreto

Elige una URL representativa y una métrica deficiente. Anota la causa observada, la modificación propuesta y las pruebas que compararás después. Así delimitas una tarea que otra persona puede implementar y revisar.

Utiliza el comprobador de Core Web Vitals para clasificar valores medidos, conservando su origen y sus unidades. Sigue la implementación con la lista de comprobación de rendimiento. Las guías de Core Web Vitals ofrecen la siguiente vía de diagnóstico cuando ya sabes qué parte de la visita necesita atención.