Core Web Vitals: qué son, cómo medirlas y cómo mejorarlas (LCP, INP y CLS)

Hace algunos años, Google anunció en su blog oficial la introducción de una serie de métricas que evalúan la experiencia de usuario de un sitio web y que se consideraban imprescindibles para una buena experiencia de navegación y una web mucho más agradable. Esos factores fueron la base del proyecto Core Web Vitals, y se integraron en SEO como señales de experiencia de página, convirtiéndose en un tema “sí o sí” para cualquiera que se tome en serio el rendimiento y el posicionamiento.

Qué son las Core Web Vitals y por qué importan en SEO

Las Core Web Vitals (CWV) son un conjunto de métricas que Google usa para evaluar la experiencia real de una página desde el punto de vista del usuario. Cuando lo explico en sencillo: Google no solo quiere que tu contenido sea bueno, quiere que se sienta bien usar tu web. Y eso significa cargar rápido, responder rápido cuando tocas algo, y no hacer “saltos” raros mientras se renderiza.

En mi día a día con SEO, esto se nota muchísimo porque muchas veces estamos un poco “a merced” de los cambios de Google: hoy una señal pesa más, mañana se refina, y si no lo tienes controlado te puedes llevar un susto en un nicho competitivo. Aquí las CWV funcionan como un filtro de calidad: si dos páginas están empatadas en contenido y enlaces, la que ofrece mejor experiencia suele tener ventaja.

CWV vs “Page Experience”: cómo encaja todo

Las Core Web Vitals viven dentro del paraguas de experiencia de página (Page Experience): móvil friendly, seguridad (HTTPS), ausencia de intersticiales molestos, etc. La idea es la misma: menos fricción, más satisfacción, más confianza. Y sí: al final esto no es “solo SEO”. Si una web se siente lenta o torpe, baja el engagement… y eso se traduce en menos leads, menos ventas o menos lecturas.

Las métricas Core Web Vitals actualizadas

Durante años se hablaba del “trío” clásico: LCP, FID y CLS. Pero el enfoque actual está en LCP + INP + CLS (INP sustituye la lógica de FID porque refleja mejor la experiencia de interacción real, no solo el primer toque).

LCP (Largest Contentful Paint): qué mide y valores objetivo

LCP mide el tiempo que tarda en mostrarse el elemento principal más grande visible en la parte superior de la página (un “hero”, una imagen destacada, un bloque grande de texto…). Es la métrica que más se relaciona con la sensación de “esta web carga rápido / carga pesada”.

Objetivo habitual: por debajo de 2,5 s suele considerarse “bien”.
Qué suele fastidiar el LCP en la vida real:

Imagen hero gigante sin optimizar (o formato antiguo).
Servidor lento o TTFB alto.
CSS/JS bloqueando renderizado.
Fuentes externas o terceros que frenan el “pintado” inicial.

Y aquí va una observación práctica: muchas webs “parecen rápidas” si tú las pruebas con buena Wi-Fi y un portátil decente, pero cuando miras el LCP real en móvil… se desmorona. Por eso conviene medir con datos reales, no solo con “a mí me carga”.

INP (Interaction to Next Paint): qué mide y por qué es clave

INP mide cómo de rápido responde tu web a las interacciones del usuario a lo largo de la sesión: clics, taps, inputs… y cuánto tarda en reflejarse esa respuesta visualmente.

Esto es clave porque (y esto lo he visto mil veces): una página puede cargar “ok”, pero en cuanto empiezas a tocar filtros, menús, acordeones, carrito, buscador… la web se siente como atascada. Normalmente es por:

JavaScript pesado.
Demasiadas librerías.
Tareas largas bloqueando el hilo principal (main thread).
Scripts de terceros (trackers, chat, A/B testing) pegando latigazos.

Objetivo habitual: mantener INP bajo (la referencia común es < 200 ms como bueno). Si tu web “tarda en reaccionar”, INP suele ser el sospechoso.

CLS (Cumulative Layout Shift): qué mide y cómo interpretarlo

CLS mide la estabilidad visual: esos saltos de layout que pasan cuando la página se está cargando y, de repente, el contenido se mueve porque apareció una imagen, un banner, una fuente o un anuncio.

Ejemplo muy típico: vas a hacer clic en un botón y ¡zas!, aparece un banner de cookies y el botón se desplaza. Eso es CLS alto. Es una experiencia bastante frustrante.

Objetivo habitual: CLS < 0,1.

Cómo medir Core Web Vitals sin liarte

Te recomiendo medir con dos “lentes”: datos reales (campo) y tests controlados (laboratorio).

Datos reales vs laboratorio: cuándo usar cada uno

Campo (real): te dice cómo lo viven los usuarios de verdad en diferentes móviles/redes/países. Es lo que más me interesa para tomar decisiones que impacten tráfico y negocio.
Laboratorio: te ayuda a diagnosticar rápido “qué está pasando” en una URL concreta, con un entorno repetible.

Si tengo que elegir una ruta rápida: primero miro datos reales para priorizar, y luego uso laboratorio para encontrar la causa técnica.

Search Console, PageSpeed Insights y Lighthouse: qué te da cada herramienta

Google Search Console (Métricas web principales): ideal para ver grupos de URLs con problemas y priorizar por impacto.
PageSpeed Insights: mezcla campo + laboratorio y te da recomendaciones por URL.
Lighthouse (DevTools): perfecto para diagnóstico técnico y repetir pruebas tras cambios.

En mi flujo habitual, empiezo por Search Console para saber “dónde duele” y después paso a PSI/Lighthouse para saber “por qué duele”.

Cómo mejorar Core Web Vitals paso a paso (prioridades reales)

Aquí va el enfoque que mejor me funciona: no intentes arreglar 50 cosas a la vez. Ataca lo que más mueve la aguja.

Primero LCP (lo que el usuario ve y siente al llegar)
Luego INP (lo que el usuario siente al interactuar)
Después CLS (lo que el usuario sufre cuando todo salta)

Mejorar LCP

Acciones con impacto real:

Optimiza el recurso “hero”: formato moderno (WebP/AVIF), compresión bien hecha y tamaño correcto.
Prioriza contenido crítico: evita que CSS/JS bloqueen el render del above-the-fold.
CDN + servidor decente: a veces el salto más grande viene de aquí.
Reduce peso de la página: si estás cargando cosas que no aportan, estás pagando con LCP.

Una regla mental que me gusta: si tu “primera pantalla” pesa como una landing entera, el LCP te va a pasar factura.

Mejorar INP

INP suele ser “JavaScript y amigos”. Lo que ataca el problema:

Recorta JS innecesario (librerías por capricho, sliders eternos, efectos que no suman).
Divide y difiere: carga lo imprescindible primero, y el resto cuando haga falta.
Cuida terceros: píxeles, tags, chat, heatmaps… pueden destrozar interacciones.
Simplifica DOM: estructuras gigantes hacen más costosa la renderización y el manejo de eventos.

Y aquí una verdad incómoda: “meter plugins” rara vez arregla INP. Normalmente lo arreglas quitando cosas, no añadiendo.

Mejorar CLS

Checklist de CLS (muy efectiva):

Reserva espacio para imágenes, embeds, anuncios y banners (dimensiones explícitas).
Evita insertar elementos arriba de contenido ya renderizado (especialmente banners).
Ojo con las fuentes: cambios de tipografía pueden provocar saltos (precarga cuando toque).
Componentes que aparecen tarde (cookie banner, promos, “sticky bars”): dales un espacio o muévelos sin empujar el contenido.

Con CLS, pequeños detalles suman muchísimo. He visto mejoras grandes solo por declarar tamaños y ordenar cargas.

Checklist rápida por tipo de web

WordPress

Plugin de caché (uno bueno, bien configurado).
Limita plugins a los que aportan valor real.
Tema rápido (los “multi-purpose” pesados suelen sufrir).
Imágenes optimizadas + lazy load con criterio (no al hero).
Control de scripts de terceros (tag manager con cabeza).

Ecommerce

Optimiza PLP/PDP: imágenes, scripts de reviews, buscador interno, filtros.
INP suele caer por filtros y carritos: prioriza ahí.
Evita banners que empujen contenido (CLS clásico en ecommerce).

Web corporativa / blog

Hero ligero, tipografías cuidadas, anuncios moderados.
Evita popups agresivos en el primer render.
Simplifica componentes “bonitos” pero caros (animaciones pesadas).

Errores típicos que veo una y otra vez

“Pongo lazy load a todo y empeora”

Lazy load está genial… excepto cuando se lo aplicas al contenido crítico (el elemento que define LCP). Resultado: el usuario llega y la web parece vacía o tarda en pintar lo importante.

“Instalo 5 plugins de caché y… caos”

Más plugins no es más velocidad. Es más conflictos. Uno (bien) suele ganar a cinco (mal).

“Un banner/cookie rompe el CLS”

Es el clásico: aparece arriba, empuja todo, y CLS se dispara. Solución: reserva espacio o cambia el patrón de aparición para no desplazar el contenido.

FAQs sobre Core Web Vitals

¿Las Core Web Vitals son factor de ranking?
Son señales relacionadas con experiencia de página. En competitivos pueden marcar diferencia, sobre todo cuando el resto está empatado.

¿Qué importa más: escritorio o móvil?
En la práctica, móvil suele ser el campo de batalla (redes lentas, CPU más limitada). Si lo clavas en móvil, normalmente el resto mejora.

¿Search Console y Lighthouse dan resultados distintos?
Sí: Search Console refleja datos reales agregados; Lighthouse es un test controlado. Úsalos juntos: uno prioriza, el otro diagnostica.

¿Por dónde empiezo si tengo poco tiempo?

Optimiza imagen/hero (LCP), 2) recorta JS/terceros (INP), 3) fija espacios y banners (CLS).

Conclusión

Las Core Web Vitals ya no son “una cosa técnica para frikis”: son la forma en la que Google y tus usuarios te dicen si tu web se siente rápida, fluida y estable. Yo lo abordo siempre con un orden claro: primero LCP para la primera impresión, luego INP para que la web responda como debe, y por último CLS para que no parezca un castillo de naipes.

Si haces esto bien, normalmente no solo subes en visibilidad: también mejoras la experiencia real y eso se nota en negocio.

¿Quieres que lo haga yo por ti?

Si prefieres no pelearte con métricas, plugins, scripts y mil tests, puedo encargarme yo de la auditoría y optimización de tus Core Web Vitals de principio a fin.

Entra en mi página de servicio:
O, si lo tienes más a mano, rellena el formulario de abajo para una asesoría gratuita

Y te lo digo con total sinceridad: en esa asesoría revisaré tu caso y te diré si esta es la estrategia más óptima para tu web, qué priorizar primero (LCP, INP o CLS) y cómo lo mejoraría paso a paso según tu tecnología (WordPress, ecommerce, web a medida, etc.). Si no merece la pena invertir en esto todavía (o hay algo más urgente), también te lo diré.