Cómo mejorar Core Web Vitals: guía práctica para LCP, INP y CLS

Si una página tarda en mostrarse, no responde al tocarla o se mueve justo cuando el usuario va a hacer clic, el problema no es "solo técnico". Ahí se pierden sesiones, ventas y señales SEO.

Por eso Core Web Vitals no debería quedarse en manos del equipo de performance. También importa a quien gestiona tráfico orgánico, a quien publica contenido y a quien depende de que una landing convierta.

Panel de métricas de rendimiento web con FCP, LCP, TTFB, INP y CLS

Qué son realmente los Core Web Vitals

Google resume la experiencia de página en tres métricas que conviene mirar juntas, no por separado:

1. LCP (Largest Contentful Paint)

Mide cuánto tarda en aparecer el bloque principal de la parte visible de la página. Suele ser la imagen hero, un banner, un vídeo destacado o el titular con su primer bloque de texto.

Un buen objetivo es 2,5 segundos o menos. Si tu LCP se va por encima de eso, el usuario siente que la página "no arranca".

2. INP (Interaction to Next Paint)

Mide cuánto tarda la página en reaccionar visualmente después de una interacción real: tocar un botón, abrir un menú, escribir en un formulario.

La referencia actual es 200 ms o menos. Cuando el INP es malo, la web se siente pesada aunque ya haya cargado.

3. CLS (Cumulative Layout Shift)

Mide cuánto se mueve el diseño de forma inesperada mientras la página carga o actualiza elementos.

La meta es 0,1 o menos. Un CLS alto suele traducirse en clics fallidos, lectura incómoda y sensación de poca calidad.

Cómo medirlo sin perder tiempo

Antes de optimizar, necesitas separar impresión de datos.

1. Search Console y PageSpeed Insights

Empieza por el informe de Core Web Vitals de Google Search Console. Te dice qué grupos de URLs están fallando con datos de usuarios reales. Después usa PageSpeed Insights para revisar una URL concreta y detectar patrones.

2. Lighthouse en Chrome

Lighthouse sigue siendo la forma más rápida de sacar hipótesis técnicas. Abre DevTools, ejecuta un análisis de rendimiento y revisa:

el elemento candidato a LCP
scripts que bloquean el hilo principal
recursos que frenan el primer renderizado
cambios de layout durante la carga

3. RUM (Real User Monitoring)

El laboratorio ayuda, pero no sustituye a usuarios reales. Si tu tráfico llega desde móviles antiguos, redes lentas o mercados con latencia variable, necesitas RUM para ver el problema de verdad.

Si quieres una lectura rápida desde el lado SEO, puedes cruzar estos datos con una revisión en SEO Analyzer para priorizar URLs antes de entrar al detalle técnico.

Cómo bajar el LCP sin tocar veinte cosas a la vez

La forma más rápida de mejorar LCP suele ser bastante poco glamourosa: arreglar imagen principal, respuesta del servidor y recursos bloqueantes.

1. Optimiza la imagen principal

En muchos sitios, el LCP es una imagen. Si esa imagen pesa demasiado o llega tarde, todo lo demás se retrasa.

Usa WebP o AVIF siempre que tenga sentido.
Sirve tamaños distintos con srcset o <picture>.
Comprime la imagen antes de subirla.
No apliques loading="lazy" a la imagen que probablemente sea el LCP.
Define width y height para reservar espacio desde el principio.

1<picture>
2  <source
3    srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w"
4    type="image/webp"
5    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
6  >
7  <source
8    srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w"
9    type="image/jpeg"
10    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
11  >
12  <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager">
13</picture>

2. Recorta el tiempo de respuesta del servidor

Si el TTFB es lento, el navegador ni siquiera puede empezar a dibujar.

activa caché de página o de fragmentos
usa CDN para imágenes, CSS y JS
revisa consultas lentas a base de datos
evita que cada visita dependa de lógica pesada en servidor

3. Quita recursos que bloquean el render

Hay páginas que se frenan por una cadena absurda de CSS, fuentes y scripts que el usuario ni necesita para ver la parte superior.

inyecta el CSS crítico del primer bloque
difiere scripts no esenciales con defer
carga scripts independientes con async
elimina librerías que solo se usan en una interacción secundaria

1<head>
2  <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
3  <script src="/js/main.js" defer></script>
4  <script src="https://analytics.example.com/script.js" async></script>
5</head>

4. Preload solo cuando de verdad haga falta

preload funciona muy bien para la imagen LCP, una fuente crítica o un script imprescindible. El error habitual es marcar demasiadas cosas como prioritarias y crear el atasco tú mismo.

Cómo mejorar el INP y conseguir una web que responda

Cuando el INP sale mal, casi siempre hay un culpable claro: demasiado trabajo en el hilo principal.

1. Adelgaza JavaScript

No todo el JS debe viajar en la carga inicial.

divide bundles grandes
usa importación dinámica para funciones secundarias
elimina código muerto
reduce hidratar componentes que no necesitan interacción inmediata

1document.querySelector('.open-chart').addEventListener('click', async () => {
2  const { renderChart } = await import('./chart-module.js');
3  renderChart();
4});

2. Controla scripts de terceros

Chat widgets, píxeles, mapas, popups, pruebas A/B, reproductores embebidos. Cada script tercero compite por CPU y por red.

Haz una auditoría honesta:

qué script aporta negocio real
cuál puede cargarse tras la primera interacción
cuál puede retirarse directamente

3. Rompe tareas largas

Si una tarea de JS dura más de 50 ms, el navegador se queda ocupado y la interacción se atasca. Ahí suelen ayudar:

dividir procesos largos en trozos
usar requestIdleCallback para tareas secundarias
mover cálculos pesados a Web Workers

Cómo bajar el CLS y dejar de pelearte con layouts que saltan

CLS no suele venir de un único gran error. Viene de muchos pequeños descuidos.

1. Reserva espacio para medios y embeds

Siempre que una imagen, vídeo o iframe aparece sin tamaño previsto, el navegador tiene que recolocar el contenido.

define width y height
usa aspect-ratio cuando el bloque sea responsive
deja un contenedor estable para mapas, vídeos y embeds

2. No insertes elementos "por sorpresa"

El clásico aviso, banner o módulo de recomendaciones que entra por arriba puede destrozar la estabilidad visual.

reserva hueco antes de cargar el elemento
usa overlays si no quieres empujar el contenido
fija un alto mínimo para slots publicitarios

3. Revisa fuentes web

Las fuentes también provocan saltos.

precarga la fuente principal
usa font-display: swap
elige una tipografía fallback con métricas parecidas

Un caso típico: mejoras pequeñas, impacto grande

Un comercio electrónico B2C con bastante tráfico móvil llegó con este punto de partida:

LCP: 4,8 s
INP: 180 ms
CLS: 0,25
conversión: 1,2 %
rebote: 65 %

Se aplicaron siete cambios bastante concretos:

Se migraron imágenes principales a WebP.
Se corrigieron tamaños y espacios reservados para banners y fichas.
Se retrasó la carga de scripts de analítica y anuncios.
Se precargó la imagen hero de las landings clave.
Se redujo el CSS crítico a lo realmente visible.
Se activó CDN para recursos estáticos.
Se ajustó la carga de fuentes con font-display: swap.

El resultado después de la iteración principal:

LCP: 1,9 s
INP: 65 ms
CLS: 0,08
conversión: 2,8 %
rebote: 42 %

No hubo magia. Hubo prioridades claras.

La parte que casi todos olvidan: mantenerlo así

Core Web Vitals no se arregla una vez y listo. Cada nueva plantilla, widget o experimento puede empeorar otra vez la situación.

1. Monta un sistema de seguimiento

Vigila Search Console, RUM y tus plantillas más importantes. No esperes a notar la caída en negocio para mirar performance.

2. Define presupuestos

Pon límites razonables a:

peso total de JavaScript
tamaño máximo de imágenes
número de fuentes
cantidad de scripts de terceros

3. Mete performance en el flujo de publicación

Antes de lanzar una landing, una funcionalidad o un rediseño, alguien tiene que revisar el impacto en LCP, INP y CLS. Si no entra en el proceso, siempre llega demasiado tarde.

4. Haz que no dependa de una sola persona

Diseño, contenido, desarrollo y marketing afectan estas métricas. Si solo una persona entiende el problema, vas a repetirlo.

Resumen rápido

Qué conviene recordar:

LCP mejora cuando aceleras el recurso principal, el servidor y el primer render.
INP mejora cuando liberas el hilo principal y recortas JavaScript innecesario.
CLS mejora cuando reservas espacio y evitas insertar elementos sin previsión.
Los datos de laboratorio sirven, pero los datos de usuario real mandan.
El objetivo no es una puntuación bonita. El objetivo es una página que cargue, responda y convierta mejor.

Si necesitas detectar primero qué URLs están perdiendo más por rendimiento, empieza por una revisión en SEO Analyzer y luego baja al detalle técnico con Lighthouse y datos de campo.