Core Web Vitals: qué miden realmente y cómo mejorarlos sin volverse loco

Tres números que Google usa para evaluar tu web

LCP, CLS e INP son las tres Core Web Vitals que Google incluye como señal de ranking. No son las métricas más importantes del SEO — el contenido y la autoridad pesan más — pero sí son las más directamente relacionadas con la experiencia que tiene el usuario cuando visita tu web.

Lo que mide cada una, sin rodeos:

LCP (Largest Contentful Paint): Cuánto tiempo tarda en aparecer el contenido principal de la página. No todo el contenido — el elemento más grande visible en la pantalla inicial. Normalmente es la imagen hero, el título principal o un bloque grande de texto. Si tarda más de 2.5 segundos, Google lo considera “necesita mejora”.

CLS (Cumulative Layout Shift): Cuánto se mueve el contenido de la página mientras carga. Cuando estás leyendo algo y de repente el texto se desplaza porque cargó un banner por encima — eso es CLS. Una puntuación de 0.1 o menos se considera buena.

INP (Interaction to Next Paint): Cuánto tarda la página en responder cuando el usuario interactúa — hacer clic en un botón, abrir un menú, escribir en un campo. Sustituyó a FID a principios de 2024. Un INP por debajo de 200ms se considera bueno.

Por qué importan para SEO — y por qué no son lo que más importa

Google confirmó en 2021 que las Core Web Vitals son un factor de ranking. Lo que no ha confirmado — y lo que vemos en la práctica — es cuánto pesan respecto a otros factores.

La realidad que hemos observado: si dos páginas tienen contenido y autoridad similares, las Core Web Vitals pueden desempatar. Pero hemos visto páginas con LCP de 4 segundos posicionando por encima de páginas con LCP de 1 segundo porque el contenido y los backlinks lo compensan con creces.

Lo que sí es cierto: una web lenta o con CLS alto tiene tasas de rebote más altas. Si el usuario se va antes de interactuar, eso tiene impacto directo en conversiones — y potencialmente en señales de comportamiento que Google puede leer.

Causas más comunes de cada problema

Lo que encontramos en auditorías reales, no en documentación técnica.

LCP lento. La causa más frecuente, con diferencia, es una imagen hero sin optimizar: 2-4 MB en formato JPG, sin WebP, sin dimensiones especificadas. La segunda causa más común es un servidor lento — hosting compartido con TTFB alto que retrasa la descarga de todo. La tercera son fuentes web que bloquean el renderizado: si la fuente tarda 800ms en cargarse, el texto que es el LCP tampoco aparece hasta entonces.

CLS alto. Casi siempre viene de uno de tres sitios. Imágenes sin atributos de ancho y alto especificados — el navegador no sabe cuánto espacio reservar y mueve el contenido cuando carga la imagen. Fuentes web que cambian el layout cuando se cargan (el llamado FOUT, Flash of Unstyled Text). Banners de cookies mal implementados que aparecen de forma invasiva encima del contenido ya cargado.

INP alto. Normalmente causado por JavaScript que bloquea el hilo principal. Los scripts de terceros son los principales sospechosos: chatbots, herramientas de heat mapping, sistemas de analytics complejos, widgets de redes sociales. Cada uno puede parecer inofensivo individualmente, pero cinco scripts de terceros ejecutándose en la carga inicial pueden hacer que cualquier interacción del usuario tenga que esperar a que terminen.

Las palancas que más mueven la aguja

Esto es lo que en nuestra experiencia resuelve la mayoría de problemas con un esfuerzo razonable.

Para LCP:

Servir la imagen hero en WebP, optimizada por debajo de 200KB, con fetchpriority="high" para que el navegador la priorice sobre otros recursos. Mover las fuentes a self-hosted y añadir font-display: swap para que el texto sea visible mientras la fuente carga. Mejorar el hosting si el TTFB supera los 300ms: un cambio de hosting puede hacer más por el LCP que cualquier optimización de frontend.

Para CLS:

Añadir width y height explícitos a todas las imágenes, especialmente las que están sobre el fold. Usar font-display: optional si el CLS por fuentes es alto — muestra la fuente de sistema si la web no carga en un tiempo razonable. Revisar el banner de cookies: si está mal implementado y genera CLS, hay soluciones que lo fijan como overlay sin afectar el layout.

Para INP:

Auditar qué scripts de terceros se cargan y en qué momento. Muchos pueden cargarse con defer o async sin perder funcionalidad. Si hay JavaScript propio que es pesado, buscar si puede ejecutarse fuera del hilo principal con Web Workers. Eliminar scripts que no aportan valor real — cada herramienta de terceros tiene un coste de rendimiento que hay que justificar.

Lo que no merece la pena optimizar si lo básico está roto

Hay optimizaciones que tienen retorno marginal si los problemas principales no están resueltos. No tiene sentido implementar preconnect para Google Fonts si la imagen hero pesa 3MB. No tiene sentido hacer code splitting del JavaScript si el servidor tiene un TTFB de 800ms.

La secuencia que seguimos en auditorías: primero el servidor, luego las imágenes, luego las fuentes, luego los scripts de terceros. Solo después de resolver esas cuatro categorías tiene sentido profundizar en optimizaciones más técnicas.

Herramientas para medirlo

PageSpeed Insights — mide el rendimiento de una URL específica, da datos de campo reales (CrUX) y diagnósticos de laboratorio. Es el punto de partida para cualquier auditoría.

Chrome UX Report (CrUX) — los datos reales de usuarios en Chrome. Se puede consultar en PageSpeed Insights o directamente en BigQuery. Es importante porque las puntuaciones de laboratorio pueden diferir significativamente de los datos reales de usuario.

Search Console — tiene un informe específico de Core Web Vitals que muestra qué URLs tienen problemas según datos reales de usuarios, agrupadas por tipo de problema. Es el más práctico para priorizar qué páginas arreglar primero.

Una opinión directa

El 80% de las mejoras en Core Web Vitals vienen del 20% de cambios. En la mayoría de webs que auditamos, resolver tres cosas — imagen hero optimizada con fetchpriority, fuentes self-hosted con font-display swap, y eliminar los scripts de terceros innecesarios — mueve la puntuación de 60 a 90+ en PageSpeed.

El resto — prefetch de recursos, lazy loading agresivo, code splitting granular — son optimizaciones de segundo nivel que tienen sentido cuando lo básico está resuelto. Intentar hacer esas optimizaciones antes de resolver lo básico es como ajustar el carburador de un coche con una rueda pinchada.

Para la mayoría de empresas medianas, el objetivo no debería ser un LCP de 0.5s. Debería ser verde en las tres métricas según datos reales de usuarios en Search Console. Eso es alcanzable sin una arquitectura perfecta — requiere atención a los problemas específicos, no una reescritura completa.