Cómo mejorar las Core Web Vitals: LCP, INP y CLS

Por el equipo de Mayab Media · Nivel: Avanzado · Tiempo: 2 horas

Search Console marca tus URLs como Deficientes o Necesitan mejorar en Core Web Vitals. Corres PageSpeed Insights y la puntuación cambia en cada prueba. El informe nombra una métrica, como «Problema de INP: más de 200 ms», pero no te dice qué cambiar.

Las Core Web Vitals son tres mediciones tomadas de usuarios reales de Chrome. Largest Contentful Paint (LCP) mide la carga. Interaction to Next Paint (INP) mide qué tan rápido responde la página a clics, toques y teclas. Cumulative Layout Shift (CLS) mide cuánto brinca el diseño. El INP sustituyó a First Input Delay (FID) como Core Web Vital en marzo de 2024, así que los consejos viejos sobre FID ya no aplican.

Corregirlas es un ciclo. Identificas qué métrica falla y en qué plantilla, encuentras la causa concreta, publicas el cambio y esperas a que los datos de campo se actualicen. Esta guía sigue ese ciclo con las herramientas gratuitas de Google.

Respuesta rápida

1. En Search Console, abre Core Web Vitals, empieza por Móvil y anota qué métrica falla en qué grupo de URLs.
2. Analiza una URL de ejemplo en PageSpeed Insights. Confía en los datos de campo para saber si aprueba y usa los de laboratorio para encontrar causas.
3. Para el LCP: haz que la imagen o el texto principal cargue pronto, nunca le pongas carga diferida y reduce el tiempo de servidor y los archivos que bloquean el renderizado.
4. Para el INP: encuentra la interacción lenta, divide las tareas largas de JavaScript y recorta scripts de terceros.
5. Para el CLS: reserva espacio a imágenes, inserciones y anuncios, y deja de insertar contenido arriba de lo que la gente está leyendo.
6. Publica el cambio en toda la plantilla, inicia la validación en Search Console (Validate fix; la ayuda de Google también lo llama Start tracking) y deja pasar la ventana de 28 días.

Antes de empezar

Esto es lo que necesitas:

• Acceso a la propiedad de Search Console (cualquier permiso puede ver el informe; validar requiere Propietario o Usuario con permiso total).
• Google Chrome con DevTools para las pruebas.
• Alguien que pueda modificar plantillas, configuración de imágenes, scripts y la configuración del servidor o la CDN.
• Un sitio de pruebas o una forma de revertir cambios. Las mejoras de rendimiento pueden romper diseños o la medición.

Conoce los umbrales antes de empezar. Google mide cada métrica en el percentil 75 de las visitas, por separado en móvil y en computadora.

Una página aprueba las Core Web Vitals solo si las tres son buenas en el percentil 75.

Paso 1: Ubica la métrica y la plantilla que fallan en Search Console

En Search Console, abre Experience > Core Web Vitals (Experiencia > Métricas web principales). Verás dos tarjetas: Mobile (Móvil) y Desktop (Ordenador), cada una con un enlace OPEN REPORT (Abrir informe) y el conteo de URLs deficientes, que necesitan mejorar y buenas. Abre Mobile primero. La mayoría de los sitios tiene más tráfico móvil y resultados móviles más lentos.

Dentro del informe de cada dispositivo, cada fila de problema nombra la métrica, el dispositivo y el umbral que no cumple, con un formato como LCP issue: longer than 4s (mobile) o INP issue: longer than 200ms (mobile). Haz clic en la fila para ver los grupos de URLs que lo tienen. El informe agrupa URLs que se comportan igual, normalmente páginas construidas con la misma plantilla. Cada grupo toma el estado de su peor métrica. Haz clic en un grupo para ver una URL de ejemplo y el valor del grupo en esa métrica.

Anota tres cosas por cada problema:

• La métrica (LCP, INP o CLS).
• La plantilla del grupo, como entradas de blog, páginas de producto o el inicio.
• Una URL de ejemplo.

Si una tarjeta dice Not enough usage data in the last 90 days for this device type (no hay suficientes datos de uso en los últimos 90 días), tu sitio todavía no tiene suficiente tráfico de Chrome en ese dispositivo. Search Console solo muestra URLs indexadas con suficientes datos reales, y la tarjeta enlaza a Try PageSpeed Insights. Usa las pruebas de laboratorio de PageSpeed Insights y tus propias mediciones mientras se juntan datos.

Paso 2: Lee PageSpeed Insights de la forma correcta

Entra a PageSpeed Insights (pagespeed.web.dev), pega la URL de ejemplo y haz clic en Analyze (Analizar). Elige la pestaña Mobile o Desktop. Los resultados tienen dos partes muy distintas: Discover what your real users are experiencing (datos de campo) y Diagnose performance issues (datos de laboratorio).

• Datos de campo. Vienen del Chrome UX Report: visitas reales de los últimos 28 días. Con suficiente tráfico, esta sección muestra una Core Web Vitals Assessment (evaluación aprobada o no) con LCP, INP y CLS. Es la misma fuente que usa Search Console. Si no hay tráfico suficiente, verás No data.
• Datos de laboratorio. Es una sola carga simulada con Lighthouse en un celular de gama media emulado y con red limitada. Úsala para encontrar causas, no para medir el éxito. Junto a Performance también aparecen Accessibility, Best Practices, SEO y una revisión nueva llamada Agentic browsing; ninguna es una Core Web Vital.

Unas reglas que te ahorran horas:

• La puntuación de Rendimiento no es una Core Web Vital. Una página puede sacar 60 y aprobar, o sacar 90 y reprobar por INP.
• Las pruebas de laboratorio no miden el INP, porque nadie hace clic en nada. Las métricas de laboratorio son First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift y Speed Index. El Total Blocking Time es la pista más cercana al INP.
• Si la pestaña This URL (Esta URL) no tiene datos, cambia a Origin (Origen) para ver todo el sitio.
• Los datos de campo cambian despacio. Son una ventana móvil de 28 días, así que un cambio publicado hoy muestra su efecto completo unas cuatro semanas después.

Baja más allá de la tira de capturas. Desde Lighthouse 13 ya no existen los nombres antiguos (como «Eliminate render-blocking resources»). Los diagnósticos están ahora bajo INSIGHTS, con nombres como Render-blocking requests, LCP breakdown, Layout shift culprits, Network dependency tree, Forced reflow, Legacy JavaScript y Third parties. Los que aparecen dependen de la página, y pueden mostrarse traducidos si usas PageSpeed Insights en español. Usa Show audits relevant to: para filtrar por FCP, LCP, TBT o CLS.

Paso 3: Corrige el LCP (carga lenta)

Primero identifica el elemento LCP. En PageSpeed Insights, haz clic en LCP junto a Show audits relevant to: y abre el insight LCP breakdown. Te dice cuál es el elemento y divide su tiempo en partes. Casi siempre es una imagen principal, un encabezado grande o una imagen de fondo.

El tiempo de LCP se divide en cuatro partes. Cada una tiene su propia solución.

Haz que la imagen LCP cargue pronto

El problema más común es una imagen principal que el navegador descubre tarde. Pasa cuando es un fondo de CSS, cuando la inserta JavaScript o cuando tiene carga diferida.

<!-- Bien: en el HTML, prioridad alta, sin carga diferida -->
<img src="/img/hero-1200.avif"
     width="1200" height="630"
     fetchpriority="high"
     alt="Equipo revisando la auditoría de un sitio web">

<!-- Si la imagen es un fondo de CSS, precárgala en el <head> -->
<link rel="preload" as="image" href="/img/hero-1200.avif" fetchpriority="high">

Nunca pongas loading="lazy" en la imagen LCP. Muchos temas y plugins aplican carga diferida a todas las imágenes, incluida la primera. Excluye la imagen principal. Usa fetchpriority="high" en una o dos imágenes como máximo.

Reduce el archivo

Sirve la imagen en un tamaño cercano al que se muestra. Una foto de 3000 píxeles mostrada a 800 desperdicia casi toda la descarga. Usa srcset para que los celulares reciban un archivo más chico, y usa AVIF o WebP.

Reduce el tiempo de servidor

Si aparece el insight Document request latency, o la parte de tiempo hasta el primer byte del LCP breakdown es grande, revisa el servidor antes que cualquier otra cosa:

• Activa la caché de página completa o la caché en el borde de tu CDN.
• Elimina saltos de redirección. Enlaza directo a la URL final.
• Evita parámetros que se salten la caché, como parámetros de seguimiento únicos en enlaces internos.

Quita lo que bloquea el renderizado

Los archivos CSS grandes y los scripts síncronos en el <head> retrasan el primer pintado. Difiere los scripts que no hacen falta para mostrar la parte superior. Elimina CSS sin uso. Haz que el administrador de etiquetas y los widgets de chat no bloqueen el renderizado. Si cargas etiquetas con Google Tag Manager, nuestra guía para instalar Google Tag Manager explica el fragmento asíncrono estándar.

Paso 4: Corrige el INP (respuesta lenta a clics y toques)

El INP revisa las interacciones de una página y reporta una de las más lentas. Cada interacción tiene tres fases:

1. Retraso de entrada: el navegador está ocupado con otra cosa cuando el usuario toca.
2. Duración del procesamiento: tus controladores de eventos tardan en ejecutarse.
3. Retraso de presentación: el navegador tarda en pintar el resultado.

Encuentra la interacción lenta

Abre la página en Chrome. Abre DevTools y luego el panel Performance (Rendimiento). Las versiones recientes de Chrome muestran en la pantalla inicial del panel los valores locales en vivo de LCP, CLS e INP mientras usas la página, junto con un registro de Interactions (interacciones) con el elemento y la duración de cada clic, toque o tecla. Abre el menú, despliega acordeones, agrega al carrito, envía formularios. Observa qué interacción sube el INP.

Un registro corto en esa vista podría verse así (es una ilustración, no una captura real):

El botón lento de agregar al carrito es el que hay que perfilar. Los colores siguen los umbrales: verde hasta 200 ms, rojo arriba de 500 ms.

Luego haz clic en Grabar, repite la interacción lenta y detén la grabación. En el trace, las tareas largas llevan una esquina roja. Ábrelas para ver qué script se ejecutó. La barra lateral Insights de DevTools incluye un INP breakdown que muestra las tres fases de esa interacción. PageSpeed Insights avisa que sus insights también están en el panel Performance de DevTools cuando grabas un trace.

Para datos de campo de usuarios reales, la librería abierta de JavaScript web-vitals puede enviar a tu analítica el elemento y la fase lentos. Así sabes qué interacciones fallan en celulares reales, no solo en tu laptop.

Correcciones comunes del INP

• Divide las tareas largas. Si un clic dispara mucho trabajo, haz primero la actualización visible y cede el hilo principal antes del resto.
• Pospón lo que no es urgente. Eventos de analítica, registros y recálculos pueden correr después del siguiente pintado.
• Recorta scripts de terceros. Widgets de chat, mapas de calor, herramientas de pruebas A/B y algunas configuraciones de etiquetas ejecutan código pesado en cada interacción. Revisa el insight Third parties. Quita las etiquetas que ya no usas.
• Mantén el DOM pequeño. Las páginas enormes vuelven lenta cada actualización de estilos y diseño. El insight Optimize DOM size lo señala cuando aplica.
• Evita forzar el diseño. Leer medidas (como offsetHeight) justo después de cambiar estilos obliga al navegador a recalcular. El insight Forced reflow indica el código responsable.

// Muestra el resultado primero y cede antes del trabajo pesado
button.addEventListener('click', () => {
  showSpinner();                 // actualización visible inmediata
  setTimeout(() => {
    recalculateCart();           // el trabajo pesado corre después del pintado
    sendAnalyticsEvent();
  }, 0);
});

En navegadores compatibles, scheduler.yield() hace lo mismo con menos espera. Revisa la compatibilidad antes de depender de él y deja setTimeout como respaldo.

Paso 5: Corrige el CLS (saltos de diseño)

Haz clic en CLS junto a Show audits relevant to: y abre el insight Layout shift culprits en PageSpeed Insights o en un trace de DevTools. Enumera los elementos que se movieron y, muchas veces, la razón: una imagen sin tamaño, una fuente web o contenido insertado.

Con Layout shift culprits abierto, verás algo parecido a esto (una ilustración):

Corrige primero el desplazamiento más grande. Muchas veces un solo banner explica casi todo el valor.

Correcciones comunes del CLS

Ponle tamaño a cada imagen y video. Agrega los atributos width y height. El navegador los usa para reservar el espacio correcto, incluso con CSS adaptable.

img { max-width: 100%; height: auto; }   /* conserva la proporción de width/height */
.video-embed { aspect-ratio: 16 / 9; }   /* reserva espacio para iframes */
.ad-slot { min-height: 250px; }          /* reserva el tamaño de anuncio más probable */

Reserva espacio para el contenido tardío. Los avisos de cookies, barras promocionales, anuncios y bloques de «productos relacionados» suelen cargar después del renderizado y empujan el contenido. Dales un espacio fijo con min-height o muéstralos como capa superpuesta que no mueva la página.

Controla las fuentes web. Cuando entra una fuente web, el texto puede cambiar de tamaño y mover líneas. Precarga la fuente principal, elige una fuente de respaldo parecida y considera font-display: optional o ajustes de métricas como size-adjust para que el cambio no mueva el texto.

Anima con transform. Animar top, left, height o margin mueve otros elementos. Usa transform.

Revisa la caché de avance y retroceso. Las páginas restauradas desde la bfcache no repiten sus saltos de carga. Evita lo que las vuelve inelegibles, como los controladores unload.

Las herramientas de laboratorio solo ven los saltos durante la carga. Si tu CLS de campo es mucho peor que el de laboratorio, los saltos pasan después: al hacer scroll, tras un clic o cuando carga contenido diferido. Reproduce ese recorrido en DevTools con las métricas en vivo abiertas.

¿Sigue sin funcionar? Causas comunes

Plugins de caché que crean problemas nuevos

Los plugins de optimización ayudan, pero algunas opciones salen contraproducentes. Combinar todo el JavaScript en un archivo puede crear una sola tarea larga que daña el INP. La carga diferida en todas las imágenes daña el LCP. Retrasar todos los scripts hasta la interacción puede romper formularios y medición. Activa las opciones de una en una, prueba y toma notas.

Límites del hosting

Si el TTFB es alto incluso en una página sencilla y en caché, el servidor puede ser el cuello de botella. Una CDN con caché de página suele ayudar más que cualquier ajuste del front end. Si no puedes usar caché (por ejemplo, en páginas con sesión iniciada o de carrito), trabaja con tu proveedor o tu desarrollador en la velocidad de la base de datos y del backend.

Cómo confirmar que quedó resuelto

Revisa justo después del despliegue:

1. Vuelve a analizar la URL de ejemplo en PageSpeed Insights. El LCP, el TBT y el CLS de laboratorio deben mejorar, y los insights que trabajaste deben pasar de rojo a gris o desaparecer.
2. En las métricas en vivo de DevTools, repite las interacciones lentas. El INP debe quedar por debajo de 200 ms con la CPU limitada.
3. Usa URL inspection > TEST LIVE URL (Probar URL publicada) en Search Console con un par de páginas para confirmar que Google las sigue renderizando bien.

Después inicia la validación en Search Console. Abre el problema en el informe Core Web Vitals y haz clic en VALIDATE FIX (Validar corrección). La ayuda de Google llama a este botón Start tracking, así que la etiqueta puede variar. Search Console vigila las URLs afectadas durante 28 días. Si el problema no aparece en ninguna URL en ese periodo, se marca como corregido.

En PageSpeed Insights, la sección de datos de campo se actualiza conforme avanza la ventana de 28 días. Espera un cambio gradual, no un salto.

Las páginas rápidas también ayudan al rastreo y al descubrimiento. Si tus páginas nuevas tardan en salir en Google, lee cómo lograr que Google indexe tu sitio.

Preguntas frecuentes

¿Las Core Web Vitals afectan el posicionamiento?

Forman parte de las señales de experiencia en la página de Google. Una buena calificación no rescata contenido débil, y una mala rara vez hunde por sí sola una página excelente. Trátalas como una mejora de experiencia que además elimina un riesgo de posicionamiento.

¿Por qué PageSpeed Insights dice «Sin datos» en los datos de campo?

La URL no tiene suficientes visitas de Chrome en el Chrome UX Report. Cambia a Origin (Origen) para ver todo el sitio si tiene datos, o recopila tus propios datos de usuarios reales con la librería web-vitals.

¿Todavía se mide el FID?

No. El INP sustituyó al FID como Core Web Vital en marzo de 2024. Quita el FID de tus informes y tableros.

¿Qué corrijo primero?

Empieza por la métrica que falla en la plantilla con más tráfico, normalmente en móvil. Una corrección de plantilla suele mover cientos de URLs a la vez.

¿Los datos estructurados afectan las Core Web Vitals?

No de forma significativa. Un bloque JSON-LD pesa poco y no se renderiza. Si vas a agregarlo, revisa cómo agregar marcado de schema y probarlo.

Fuentes

• web.dev: /articles/vitals
• support.google.com: /webmasters/answer/9205520
• web.dev: /articles/optimize-lcp
• web.dev: /articles/optimize-inp
• web.dev: /articles/optimize-cls
• developer.chrome.com: /docs/performance/insights