Core Web Vitals

Core Web Vitals es el nombre que Google le da al trío de métricas con el que califica la experiencia real de la página. Son un factor de ranking real, una palanca aún más fuerte para la conversión y la superficie de diagnóstico más accionable del SEO técnico; por eso abren el clúster Técnico.

Este artículo recorre qué mide cada métrica, cuáles son los umbrales, qué hace típicamente que una página falle y qué arreglos rinden más.

“Los CWV son un desempate para el ranking y un multiplicador para todo lo demás. Las páginas que ofrecen una buena experiencia cargan más rápido, convierten mejor y se ganan la interacción que después compone en mejores rankings.”

Las tres métricas, de un vistazo

Los umbrales se miden en el percentil 75 de los usuarios reales de Chrome: la métrica tiene que estar en “bueno” en al menos el 75% de las cargas de página, tanto en móvil como en escritorio, para que la URL pase la evaluación.

LCP: Largest Contentful Paint

LCP mide el momento en que el elemento más grande arriba del fold termina de renderizar. En la mayoría de las páginas es la imagen del hero; en páginas con mucho texto puede ser el H1 o un bloque grande de párrafo. La percepción del usuario es “la página ya cargó” en el instante en que se dispara el LCP.

Qué falla típicamente en LCP

• Imagen del hero demasiado grande o en formato incorrecto. Un JPEG de 2 MB que debería ser un WebP de 200 KB. La causa más frecuente de LCP malo.
• Imagen del hero con lazy-load. El lazy-load es excelente para contenido abajo del fold; sobre el elemento LCP impide activamente un buen resultado. El arreglo: fetchpriority="high" y loading="eager" en el hero.
• JavaScript que bloquea el render. Scripts de terceros síncronos, frameworks grandes del lado del cliente, fuentes cargadas en línea: cualquier cosa que ocupe el hilo principal antes de que el elemento LCP pueda pintarse.
• Servidor de origen lento o sin CDN. El HTML tarda más de un segundo en llegar, así que el LCP no puede arrancar el reloj hasta entonces.
• Cambio de fuentes web cuando el elemento LCP es un bloque de texto: la pintura visible queda esperando a que llegue la fuente.

Qué arregla el LCP más rápido

• Identifica el elemento LCP con la extensión Web Vitals (lo resalta directamente en la página).
• Convierte las imágenes del hero a WebP o AVIF, sirve tamaños responsivos vía srcset y define width y height explícitos.
• Añade <link rel="preload" as="image"> para la imagen del hero, más fetchpriority="high".
• Pon defer o async al JavaScript no crítico; elimina las etiquetas de terceros que bloquean el render.
• Usa font-display: swap con un fallback del sistema para no bloquear el renderizado del texto.
• Haz preconnect a cualquier origen externo necesario (CDN, host de fuentes, analítica) para que el DNS y el TLS no se resuelvan en la ruta crítica.

INP: Interaction to Next Paint

INP reemplazó a FID (First Input Delay) en marzo de 2024. Mide el retraso más largo entre una interacción del usuario (clic, tap, tecla) y la siguiente pintura visible, a lo largo de toda la sesión, no solo en la primera interacción. Es una métrica mucho más estricta, y muchos sitios que pasaban FID fallan en INP.

Qué falla típicamente en INP

• Handlers de JavaScript pesados en click, submit o scroll. El hilo principal está ocupado cuando el usuario interactúa, así que la respuesta se pinta tarde.
• Tareas largas (más de 50 ms) que bloquean el hilo principal: típicamente scripts de terceros, hidrataciones grandes o actualizaciones de estado sin agrupar.
• Llamadas de red síncronas dentro de la interacción (clics que esperan a un fetch antes de pintar respuesta).
• Apps grandes de React/Vue/Angular sin code splitting: el framework sigue hidratando cuando el usuario hace clic.
• Jank en animaciones: animar propiedades de layout (width, height, top) en lugar de propiedades que solo afectan al compositor (transform, opacity).

Qué arregla el INP más rápido

• Audita las tareas largas en Chrome DevTools → pestaña Performance. Cualquier cosa por encima de 50 ms es candidata.
• Trocea el JavaScript de larga duración con requestIdleCallback, setTimeout(0) o startTransition de React.
• Aplica code splitting a las rutas y haz lazy-load de los componentes que no se necesitan en la primera pintura.
• Usa requestAnimationFrame para las actualizaciones visuales; evita animaciones que disparen layout.
• Muestra UI optimista al hacer clic (skeleton, loading state, estilo de botón presionado) para que el usuario reciba respuesta visible antes del round-trip de red.
• Audita los scripts de terceros sin piedad: la analítica, los widgets de chat y las herramientas de pruebas A/B son los principales asesinos de INP.

CLS: Cumulative Layout Shift

CLS mide cuánto se mueve el layout visible mientras la página carga o mientras el usuario interactúa. Es la métrica que más odian los usuarios (hacer clic en un botón, que un anuncio cargue justo encima y terminar pulsando el anuncio sin querer) y, históricamente, la más fácil de arreglar de las tres.

Qué falla típicamente en CLS

• Imágenes sin atributos width/height. El navegador no sabe cuánto espacio reservar, así que cuando carga la imagen todo lo que está debajo se desplaza hacia abajo.
• Anuncios o embeds sin contenedores reservados. Un slot de anuncio pre-roll que crece de 0 a 250 px después de que la página ya renderizó.
• Fuentes web con métricas de fallback muy distintas. El texto se vuelve a maquetar cuando entra la fuente personalizada en el swap.
• Contenido dinámico inyectado por encima del contenido existente: un banner que aparece, una prueba A/B que cambia el hero, un banner de cookies que empuja todo hacia abajo.
• Animaciones sobre propiedades que disparan layout (top, left, width) en lugar de transform.

Qué arregla el CLS más rápido

• Pon width y height en cada imagen y cada iframe. El navegador reserva el espacio correcto antes de que el recurso cargue.
• Reserva contenedores de altura fija para anuncios, embeds y cualquier componente de tamaño dinámico.
• Usa font-display: optional o fuentes de fallback cuidadosamente dimensionadas (size-adjust) para evitar el reflow al cambiar la fuente.
• Inyecta los banners dinámicos y el consentimiento de cookies por debajo del layout existente, nunca por encima.
• Usa transform para las animaciones, no top/left/width/height.

Cómo medir los CWV de verdad

Tres fuentes de medición, en orden de confianza:

Lighthouse (sintético) y los datos reales de usuario no siempre concuerdan. Lighthouse corre en un entorno controlado, con una máquina rápida y una conexión limitada artificialmente: es reproducible, pero no refleja cómo vive la página tu usuario real. Los datos de CrUX y Search Console son la verdad, con un retraso de 28 días.

Orden de prioridad cuando los CWV están fallando en todo el sitio

Cuando heredas un sitio con las tres métricas en “malo”, trabaja en este orden:

• 1. Arregla la imagen del hero o elemento LCP en la home y en las 5 páginas con más tráfico. El mayor impacto percibido por el usuario, los arreglos más sencillos, y lo que más rápido se propaga en los agregados de Search Console.
• 2. Audita y elimina los scripts de terceros que bloquean el render. Las etiquetas de marketing se acumulan durante años; borrar la mitad suele mejorar LCP e INP a la vez.
• 3. Pon width y height en cada imagen a nivel de plantilla. El arreglo de CLS que más rinde; suele ser un cambio de una línea en la plantilla.
• 4. Reserva espacio explícito para anuncios, embeds y UI dinámica. Elimina la segunda gran fuente de CLS.
• 5. Audita las tareas largas y el tamaño del bundle de JavaScript. Es el trabajo de INP: normalmente un proyecto de ingeniería de 2 a 4 semanas, no un arreglo de contenido.
• 6. Configura RUM (paquete npm web-vitals) y vigila las regresiones de cerca. Sin monitoreo real de usuario, puedes lanzar una regresión que no aparezca en Search Console hasta 28 días después.

Lo que los CWV no hacen

Los CWV miden la experiencia de página, no la calidad de la página. Un sitio puede pasar los tres umbrales y aun así posicionar mal porque el contenido es flojo, la autoridad temática es débil o no satisface la intención de búsqueda. Lo contrario también es cierto: un sitio puede fallar los CWV y aun así posicionar para consultas en las que es la mejor respuesta.

Considera los CWV como el piso: la base de rendimiento mínima exigible. Por encima del piso, el ranking lo deciden la calidad del contenido, las señales de autoridad y el calce con la intención. En cómo funciona el algoritmo verás cómo se apilan las capas.

El veredicto

Tres métricas, tres umbrales, tres patrones de arreglo. LCP va, sobre todo, de la imagen del hero y de los scripts que bloquean el render. CLS va de reservar espacio para todo lo que carga de forma asíncrona. INP va de mantener libre el hilo principal cuando el usuario interactúa. Llega a “bueno” en las tres en el percentil 75 y los CWV dejan de ser una preocupación de ranking; por debajo de ese listón, cualquier otra mejora técnica se construye sobre cimientos blandos.