¿Qué son los Core Web Vitals?

Qué son los Core Web Vitals y por qué Google los creó

Durante la mayor parte de la historia de Google, el posicionamiento dependía casi por completo del contenido y de los enlaces. ¿Su página respondía a la consulta? ¿Otros sitios con autoridad enlazaban hacia usted? Esas señales siguen siendo muy importantes. Pero a finales de la década de 2010, Google empezó a reconocer un problema real: las páginas técnicamente "relevantes" ofrecían experiencias de usuario terribles. Tiempos de carga lentos, diseños que saltaban mientras la página se cargaba, botones que no respondían durante varios segundos: estas experiencias frustraban a los usuarios y minaban la confianza en los resultados de Google.

En mayo de 2020, Google anunció los Core Web Vitals como una iniciativa formal: un subconjunto específico y medible de señales de experiencia de usuario que se incorporaría a sus sistemas de posicionamiento. El mensaje era claro: ya no bastaba con tener buen contenido y enlaces sólidos. La experiencia de cargar y usar realmente su página debía cumplir un estándar mínimo.

Actualmente, los Core Web Vitals constan de tres métricas: Largest Contentful Paint (LCP), que mide el rendimiento de carga; Cumulative Layout Shift (CLS), que mide la estabilidad visual; e Interaction to Next Paint (INP), que mide la capacidad de respuesta. Cada métrica tiene umbrales definidos de "Bueno", "Necesita mejorar" y "Deficiente". Google recopila datos reales de los usuarios de Chrome a través del Chrome User Experience Report (CrUX) y utiliza estos datos de campo, no pruebas sintéticas de laboratorio, como insumo principal para el posicionamiento.

El contexto más amplio es importante: los Core Web Vitals forman parte de lo que Google llama la señal de Page Experience, que también incluye la compatibilidad con celulares, la seguridad HTTPS y la ausencia de elementos intersticiales intrusivos. Los Core Web Vitals son el componente técnicamente más exigente de esa señal y el área donde la mayoría de los sitios tiene margen de mejora.

LCP: Largest Contentful Paint

Largest Contentful Paint mide cuánto tarda en renderizarse por completo, dentro del área visible del usuario, el elemento de contenido visible más grande de la página. Es el indicador preferido de Google para la velocidad de carga percibida: el momento en que el usuario siente que la página "llegó".

Qué mide el LCP

El LCP registra el tiempo de renderizado de la imagen más grande, la miniatura de video, la imagen de fondo renderizada mediante CSS o el elemento de texto a nivel de bloque más grande visible en el área inicial. En la práctica, el elemento LCP en la mayoría de las páginas es una imagen principal, el encabezado H1 o la miniatura de un video destacado. El navegador identifica el elemento más grande en cada momento de la carga y actualiza el candidato a LCP a medida que aparece más contenido. El tiempo final de LCP se registra cuando la página termina de cargar y comienza la interacción del usuario.

Umbrales del LCP

• Bueno: 2.5 segundos o menos
• Necesita mejorar: de 2.5 a 4.0 segundos
• Deficiente: más de 4.0 segundos

Google recomienda apuntar al percentil 75 de las cargas de página, es decir, que al menos el 75% de sus visitantes reales experimente un LCP dentro del rango "Bueno" para que su sitio reciba el beneficio completo en el posicionamiento. Una mediana de 2.3 segundos no significa nada si el 30% de sus visitantes en celular espera más de 5 segundos.

Por qué el LCP importa más allá del posicionamiento

Las investigaciones con usuarios muestran de forma consistente que la velocidad de carga se correlaciona directamente con la tasa de rebote y la tasa de conversión. Los propios estudios de Google encontraron que, cuando el tiempo de carga de la página aumenta de 1 a 3 segundos, la probabilidad de que un visitante móvil rebote aumenta un 32%. A los 5 segundos, esa probabilidad sube un 90%. El LCP es un fuerte predictor de estos resultados porque captura el momento en que los usuarios deciden si la página vale la espera. Un sitio con un LCP deficiente no solo pierde posiciones en el ranking: pierde clientes en la puerta.

CLS: Cumulative Layout Shift

Cumulative Layout Shift mide la inestabilidad visual de una página; en concreto, cuánto se mueve el contenido de forma inesperada durante y después de la carga inicial. Si alguna vez intentó tocar un botón y lo vio saltar justo cuando su dedo llegaba, haciéndole tocar algo completamente distinto, ha vivido un mal evento de CLS.

Qué mide el CLS

El CLS se calcula multiplicando dos factores: la fracción de impacto (qué porción del área visible se vio afectada por el desplazamiento) y la fracción de distancia (qué tanto se movió el elemento en relación con el área visible). Estos valores se suman a lo largo de todos los cambios de diseño inesperados que ocurren durante la vida de la página. Solo cuentan los desplazamientos inesperados; los movimientos provocados por la interacción del usuario, como hacer clic en un botón o desplazarse, se excluyen. El resultado es un puntaje sin unidades, donde un valor menor es mejor.

Umbrales del CLS

• Bueno: 0.1 o menos
• Necesita mejorar: de 0.1 a 0.25
• Deficiente: mayor que 0.25

Causas comunes de un CLS alto

Los culpables más frecuentes del CLS son predecibles una vez que se entiende el mecanismo. Cuando el navegador comienza a renderizar una página, distribuye los elementos según lo que sabe en ese momento. Si una imagen no tiene atributos de ancho y alto declarados, el navegador no reserva espacio para ella; por eso, cuando la imagen por fin se descarga y aparece, empuja hacia abajo todo lo que tiene debajo. Esta es la causa de CLS más común en la web actual.

• Imágenes y videos sin dimensiones explícitas. Defina siempre los atributos width y height en su HTML. Así, el CSS moderno puede escalarlos de forma adaptable sin provocar cambios de diseño.
• Anuncios e incrustaciones de carga tardía. Los espacios publicitarios que se expanden después del renderizado inicial, o el contenido incrustado (publicaciones de redes sociales, iframes) que se carga de forma asíncrona y empuja el contenido hacia abajo, son grandes contribuyentes al CLS.
• Fuentes web que causan FOUT (Flash of Unstyled Text). Cuando una fuente web se carga tarde, el navegador puede reemplazar la fuente de respaldo por la fuente web en pleno renderizado. Si las dos fuentes tienen métricas distintas, el texto se reacomoda y todo se desplaza. Usar font-display: swap con fuentes de respaldo de tamaño ajustado lo mitiga.
• Contenido inyectado dinámicamente. Los banners, las ventanas de consentimiento de cookies o las barras de boletín que se insertan sobre el contenido existente después de la carga provocan cambios de diseño enormes y son una fuente principal de puntajes de CLS deficientes en sitios que, por lo demás, están bien construidos.

INP: Interaction to Next Paint

Interaction to Next Paint es la más reciente de las tres Core Web Vitals y, para muchos desarrolladores y dueños de sitios, la más difícil de entender y de corregir. Reemplazó oficialmente a First Input Delay (FID) como Core Web Vital en marzo de 2024.

Por qué el INP reemplazó al FID

El FID medía el retraso antes de que el navegador pudiera comenzar a procesar la primera interacción del usuario en una página, normalmente un clic o un toque. Era un indicador razonable de la capacidad de respuesta en los primeros tiempos, pero tenía un punto ciego importante: solo medía el retraso de la primera interacción y únicamente el retraso previo al inicio del procesamiento, no cuánto tardaba la respuesta real. Una página podía aprobar el FID con facilidad y aun así sentirse lenta en todas las interacciones siguientes.

El INP corrige ambos problemas. Mide la latencia completa de la respuesta, desde que el usuario interactúa hasta que el navegador pinta el siguiente cuadro como respuesta, en todas las interacciones durante toda la sesión de la página, no solo la primera. El puntaje de INP reportado es la latencia de la peor interacción observada (o una cercana a la peor), lo que ofrece una imagen integral de qué tan constante es la capacidad de respuesta de una página.

Umbrales del INP

• Bueno: 200 milisegundos o menos
• Necesita mejorar: de 200 a 500 milisegundos
• Deficiente: más de 500 milisegundos

Por qué el INP es más difícil de aprobar que el FID

Cuando el FID era el estándar, los sitios podían aprobar simplemente posponiendo la mayor parte del JavaScript hasta después de la primera interacción. Con el INP eso no funciona, porque evalúa todas las interacciones. Un sitio con frameworks de JavaScript pesados, controladores de eventos excesivos, tareas largas que monopolizan el hilo principal o una carga agresiva de scripts de terceros reprobará el INP aunque haya aprobado el FID con holgura. Muchos sitios que tenían puntajes en verde en todas las Core Web Vitals bajo el esquema anterior descubrieron que tenían un INP Deficiente o que Necesita mejorar cuando se implementó la métrica.

La implicación práctica: mejorar el INP suele requerir un trabajo de optimización de JavaScript más profundo, que incluye dividir las tareas largas en fragmentos más pequeños, mover los cálculos pesados fuera del hilo principal con Web Workers, auditar y reducir la carga de scripts de terceros, y posponer los controladores de eventos no críticos.

Cómo revisar sus Core Web Vitals

Antes de corregir cualquier cosa, necesita datos precisos. La distinción entre datos de laboratorio y datos de campo es fundamental aquí, y confundirla lleva a muchos dueños de sitios a sacar conclusiones equivocadas sobre su rendimiento.

Datos de campo frente a datos de laboratorio

Los datos de campo (también llamados monitoreo de usuarios reales o datos RUM) provienen de usuarios reales de Chrome que visitan su sitio. Google los recopila mediante el Chrome User Experience Report y los agrega en una ventana móvil de 28 días. Estos son los datos que influyen en el posicionamiento. Su limitación: se necesita suficiente tráfico para generar un conjunto de datos estadísticamente significativo, y tardan en reflejar los cambios que usted hace en su sitio.

Los datos de laboratorio provienen de herramientas sintéticas: pruebas automatizadas que se ejecutan en un entorno controlado que simula un dispositivo y una conexión de red específicos. Los datos de laboratorio están disponibles de inmediato y son reproducibles, por lo que son ideales para diagnosticar problemas y verificar correcciones. Sin embargo, Google no usa los puntajes de laboratorio para el posicionamiento, y un puntaje de laboratorio "Bueno" no garantiza que sus datos de campo también lo sean.

Herramientas para revisar las CWV

• Google Search Console: informe de Core Web Vitals. La fuente de referencia para datos de campo a gran escala. Muestra qué URL están en Bueno, Necesitan mejorar o están en Deficiente según datos de usuarios reales, agrupadas por tipo de problema. Aquí es donde se debe empezar.
• PageSpeed Insights (PSI). Muestra tanto datos de campo (de CrUX, para la URL específica) como datos de laboratorio (de Lighthouse). La herramienta individual más útil para diagnosticar páginas concretas.
• Chrome UX Report (CrUX). El conjunto de datos en bruto detrás de los datos de campo de Google. Se puede consultar mediante BigQuery o acceder a él con la API de CrUX para análisis programático.
• Lighthouse. La herramienta de auditoría de código abierto de Google, disponible en Chrome DevTools, como CLI y como motor detrás de PageSpeed Insights. Es la mejor opción para el diagnóstico en entorno de laboratorio y para identificar los problemas técnicos específicos que causan puntajes deficientes.
• Panel Performance de Chrome DevTools. Para el diagnóstico a fondo de la selección del elemento LCP, los eventos de cambio de diseño y las tareas largas que afectan el INP. Es esencial cuando los puntajes de PSI no cuentan toda la historia.

Fallas comunes del LCP y cómo corregirlas

Los puntajes de LCP deficientes casi siempre se deben a un pequeño conjunto de causas raíz. Comprender la secuencia (respuesta del servidor, carga de recursos, renderizado) le ayuda a identificar en qué capa está su problema.

Tiempo de respuesta lento del servidor (TTFB)

Si el servidor tarda 800 ms en responder con el HTML inicial, es imposible que el LCP baje de 2.5 segundos en una conexión lenta. El Time to First Byte (TTFB) es la base sobre la que se construye todo lo demás. Las soluciones incluyen mejorar la infraestructura de hosting, implementar almacenamiento en caché del lado del servidor, usar una red de entrega de contenido (CDN) para servir respuestas desde servidores geográficamente más cercanos a los usuarios y optimizar las consultas a la base de datos en las páginas generadas dinámicamente.

Recursos que bloquean el renderizado

Los archivos CSS y JavaScript que se cargan en el <head> impiden que el navegador renderice cualquier contenido hasta que terminen de descargarse y procesarse. Cada milisegundo que el navegador dedica a analizar un paquete de CSS de 200 KB o a ejecutar un archivo JavaScript síncrono es un milisegundo que se suma al LCP. Las soluciones incluyen incorporar el CSS crítico en línea, posponer o cargar de forma asíncrona el JavaScript no crítico y eliminar el CSS/JS sin uso de la ruta crítica.

Imágenes sin optimizar

Cuando el elemento LCP es una imagen, como ocurre en la mayoría de las páginas, la optimización de imágenes es la corrección de mayor impacto disponible. Las técnicas clave incluyen: convertir las imágenes a formatos modernos como WebP o AVIF (normalmente entre 30 % y 50 % más livianos que JPEG con una calidad equivalente), servir imágenes del tamaño adecuado con el atributo srcset para que los dispositivos móviles no descarguen imágenes con resolución de escritorio, agregar indicaciones <link rel="preload"> en el <head> para la imagen LCP de modo que el navegador la descubra y comience a descargarla de inmediato, y asegurarse de que la imagen LCP no use carga diferida (la carga diferida es contraproducente para el contenido que aparece en la parte superior de la página).

Scripts de terceros lentos

Las plataformas de analítica, los widgets de chat en vivo, las herramientas de pruebas A/B, los píxeles publicitarios y las incrustaciones de redes sociales son JavaScript de terceros que se ejecuta en su página. Cualquiera de ellos puede introducir retrasos importantes en el LCP si bloquea el renderizado o compite por el ancho de banda durante la ventana crítica de carga. Audite sus scripts de terceros con regularidad usando el panel Network de Chrome DevTools. Cargue los scripts no críticos con los atributos async o defer, y evalúe si cada etiqueta de terceros en su administrador de etiquetas realmente aporta un valor de negocio medible.

Causas del CLS y cómo corregirlas

El CLS es una de las Core Web Vitals más fáciles de corregir una vez que se comprenden las causas raíz. La mayoría de las soluciones son cambios sencillos de HTML y CSS que no requieren un trabajo complejo de infraestructura.

Defina siempre dimensiones explícitas en imágenes y videos

Cada elemento <img> y <video> debe tener los atributos width y height definidos con las dimensiones intrínsecas del medio. Los navegadores modernos usan estos valores para calcular la relación de aspecto correcta y reservar el espacio adecuado antes de que el medio se cargue, eliminando por completo el desplazamiento. Combínelo con el CSS height: auto para mantener el comportamiento adaptable. Esta única corrección resuelve la mayoría de los problemas de CLS en páginas con muchas imágenes.

Reserve espacio para anuncios e incrustaciones

Los espacios publicitarios deben tener un tamaño mínimo reservado en CSS para que, cuando se cargue un anuncio, ocupe el espacio existente en lugar de empujar el contenido hacia abajo. Use un elemento contenedor con un min-height fijo que coincida con el tamaño esperado de la unidad publicitaria. Para las incrustaciones (videos de YouTube, tarjetas de Twitter, mapas), use la propiedad CSS aspect-ratio o el truco de padding-bottom para mantener la reserva de espacio adecuada antes de que se cargue la incrustación.

Use font-display: swap con fuentes de respaldo de tamaño ajustado

La propiedad CSS font-display: swap le indica al navegador que renderice el texto de inmediato con la fuente de respaldo y cambie a la fuente web cuando esta se cargue, evitando el texto invisible. Sin embargo, si la fuente de respaldo y la fuente web tienen anchos de carácter y alturas de línea distintos, el cambio en sí provoca un desplazamiento de diseño. La solución moderna es usar los descriptores CSS size-adjust, ascent-override y descent-override para que las métricas de su fuente de respaldo coincidan lo más posible con las de la fuente web, de modo que, cuando ocurra el cambio, la diferencia visual sea imperceptible.

Evite inyectar contenido sobre el contenido existente

Los banners de consentimiento de cookies, las notificaciones promocionales y las ventanas de suscripción son herramientas de negocio legítimas, pero nunca deben insertarse sobre el contenido existente después de que la página se haya renderizado. Use posicionamiento fixed o sticky para superponer los banners en la parte superior o inferior de la ventana gráfica sin desplazar el contenido de la página. Si un banner debe aparecer dentro del flujo del contenido, reserve su espacio en el HTML inicial para que el navegador asigne ese espacio antes de que se cargue el script del banner.

Causas del INP y cómo corregirlas

Mejorar el INP suele ser el trabajo más exigente desde el punto de vista técnico dentro de las Core Web Vitals. Requiere comprender los patrones de ejecución de JavaScript, la arquitectura de renderizado del navegador y el impacto del código de terceros, áreas que van más allá de la optimización SEO habitual.

Tareas largas en el hilo principal

El hilo principal del navegador se encarga de la ejecución de JavaScript, los cálculos de diseño, las operaciones de pintado y el procesamiento de las entradas del usuario. Cuando una tarea larga (cualquier operación de JavaScript que tarde más de 50 milisegundos) se ejecuta en el hilo principal, el navegador no puede responder a las interacciones del usuario hasta que la tarea termine. Esta es la causa principal de un INP deficiente. Solución: audite su paquete de JavaScript en busca de tareas largas con el panel Performance de Chrome DevTools y luego divida las funciones monolíticas en fragmentos más pequeños usando setTimeout con retraso cero, requestIdleCallback o la API Scheduler para devolverle el control al navegador entre una tarea y otra.

Frameworks de JavaScript pesados

Las aplicaciones de una sola página construidas con React, Vue, Angular o frameworks similares pueden introducir problemas importantes de INP cuando las interacciones del usuario desencadenan nuevos renderizados de componentes. Si un clic en un botón provoca que se vuelva a renderizar un árbol grande de componentes, el navegador debe procesar todo ese cálculo antes de pintar la respuesta. Las estrategias de optimización incluyen memorizar los cálculos costosos, virtualizar las listas largas, dividir el código para reducir el JavaScript que se ejecuta en cada interacción y posponer la hidratación del contenido que aparece en la parte superior de la página.

Controladores de eventos excesivos

Cada event listener asociado a elementos del DOM consume tiempo de procesamiento cuando esos eventos se disparan. Los sitios que asocian cientos de listeners de clic, desplazamiento o entrada, en particular los que aprovechan mal la delegación de eventos o los que disparan lecturas de diseño síncronas dentro de los controladores, pueden acumular una latencia de interacción considerable. Audite los listeners con Chrome DevTools, consolide los controladores mediante delegación de eventos a nivel de documento y evite los diseños síncronos forzados (leer propiedades de diseño como offsetHeight inmediatamente después de modificar el DOM).

Impacto de los scripts de terceros en el INP

Los mismos scripts de terceros que perjudican el LCP también pueden devastar el INP. Un widget de chat que realiza sondeos continuos en el hilo principal, o un script de analítica que ejecuta cálculos pesados durante la interacción con la página, puede sumar cientos de milisegundos a cada medición de INP. Use el panel Performance para identificar qué scripts de terceros se ejecutan durante las interacciones del usuario. Cárguelos en Web Workers cuando sea posible, pospóngalos hasta que la página sea interactiva o evalúe si el valor de negocio justifica el costo en rendimiento.

Cómo afectan las Core Web Vitals al posicionamiento

Google incorporó oficialmente las Core Web Vitals a sus sistemas de posicionamiento como parte de la actualización Page Experience, que se lanzó en junio de 2021 y se completó en agosto de 2021. Con ello se convirtieron en una señal de posicionamiento confirmada: no una consideración futura ni una vaga buena práctica, sino un factor documentado en la forma en que Google evalúa las páginas para posiciones competitivas.

El impacto real en el posicionamiento requiere algunos matices. Las Core Web Vitals funcionan más como un criterio de desempate que como una señal de posicionamiento principal. Una página con excelentes puntajes de Core Web Vitals no superará a otra mucho más autorizada y relevante solo por cargar más rápido. La relevancia y la autoridad siguen siendo los factores de posicionamiento dominantes. Sin embargo, en nichos competitivos donde varias páginas de alta calidad compiten por las mismas posiciones, los puntajes de Core Web Vitals pueden ser el factor diferenciador que determina cuál página selecciona Google para los tres primeros resultados frente a las posiciones cuatro a diez.

También existe un efecto indirecto en el posicionamiento que con frecuencia se subestima. Las páginas con puntajes de Core Web Vitals deficientes, en particular con un LCP lento, generan peores señales de comportamiento. Los usuarios rebotan más rápido, pasan menos tiempo en la página e interactúan con menos páginas por sesión. Google incorpora las señales de comportamiento en sus evaluaciones de calidad. Una página que hace regresar de manera constante a los usuarios a los resultados de búsqueda le indica implícitamente a Google que no satisfizo la consulta, lo que deprime el posicionamiento con el tiempo, sin importar qué tan sólidos sean el contenido y los enlaces.

El consejo práctico: trate las Core Web Vitals no como un truco de posicionamiento, sino como un estándar de calidad básico. Si sus puntajes están en el rango Deficiente, corregirlos mejorará tanto su elegibilidad directa para posicionarse como sus métricas de comportamiento. Si sus puntajes ya son Buenos, mantenerlos es una medida defensiva competitiva, porque sus competidores también están trabajando en los suyos.

El argumento de negocio para corregir las Core Web Vitals

Para los dueños de negocios que evalúan si invertir en la optimización de Core Web Vitals, el argumento del posicionamiento por sí solo puede no bastar para justificar el trabajo. El argumento de negocio basado en los resultados directos de la experiencia del usuario suele ser más convincente.

Los datos sobre la velocidad de carga y los resultados de negocio son extensos y consistentes. Las investigaciones de Google en sitios de comercio electrónico encontraron que mejorar la velocidad del sitio móvil en 0.1 segundos aumentó las tasas de conversión en 8 % en sitios de venta minorista y en 10 % en sitios de viajes. Un estudio de Deloitte encargado por Google encontró que una mejora de 0.1 segundos en la velocidad de los sitios móviles se tradujo en un aumento de 8 % en las conversiones. Walmart encontró que cada segundo de mejora en el tiempo de carga de la página generaba un aumento de 2 % en las conversiones. Estos no son efectos marginales: representan diferencias de ingresos significativas a escala.

La tasa de rebote es la consecuencia de negocio más directamente medible de unas Core Web Vitals deficientes. Cuando una página tarda en cargar (LCP deficiente), es visualmente inestable (CLS deficiente) o no responde a las entradas (INP deficiente), los usuarios se van. Cada visitante que rebota antes de convertir es una oportunidad perdida: tráfico pagado u orgánico que no generó ningún retorno. Mejorar los puntajes de Core Web Vitals reduce las tasas de rebote, aumenta el tiempo en el sitio y eleva la probabilidad de que los visitantes completen las acciones que su negocio necesita que realicen.

Para los negocios que invierten en publicidad pagada (Google Ads, campañas de Meta, redes de display), las mejoras en Core Web Vitals potencian el retorno de la inversión publicitaria. Si usted paga por clics que llegan a una página con un LCP de 5 segundos, está pagando por un porcentaje significativo de visitantes que se van antes de que la página termine de cargar. Corregir la experiencia de la página convierte más del tráfico por el que ya está pagando, con lo que reduce de forma efectiva su costo por conversión sin reducir su presupuesto publicitario.