Cómo Corregir Problemas de Core Web Vitals: LCP, INP y CLS Explicados
Prueba AuditMe en vivo — Escaneo instantáneo gratuito
Pega cualquier URL a continuación y obtén una puntuación SEO real en unos 60 segundos. Sin registro: es el mismo motor descrito en este artículo.
¿Qué son los Core Web Vitals? (Y por qué importan de verdad)
Los Core Web Vitals son el conjunto de métricas de mundo real de Google que miden la experiencia del usuario en tu sitio. Desde 2022, son factores de posicionamiento directos. En 2026 siguen siendo críticos, tanto para el SEO como para evitar que la gente abandone tu página frustrada.
Lo que le digo a cada cliente: a Google no le importa lo bonito que sea tu sitio. Le importa lo rápido que carga, lo estable que se siente y lo rápido que responde cuando alguien toca un botón. Esas tres cosas son lo que miden los Core Web Vitals.
Las tres métricas con las que debes preocuparte son:
- LCP (Largest Contentful Paint) — Rendimiento de carga (lo rápido que aparece tu contenido principal)
- INP (Interaction to Next Paint) — Interactividad (lo ágil que se siente tu página)
- CLS (Cumulative Layout Shift) — Estabilidad visual (cuánto salta el contenido mientras carga)
También están FCP y TTFB, que son métricas de apoyo importantes, pero LCP, INP y CLS son las tres grandes que Google usa realmente para posicionar. He pasado los últimos dos años corrigiendo estas métricas para clientes, y te voy a mostrar exactamente lo que funciona: no teoría, sino lo que de verdad movió la aguja.
Corregir el LCP (Objetivo: menos de 2,5s)
El LCP mide cuánto tarda en renderizarse el elemento visible más grande. En la mayoría de los sitios, es tu imagen principal o un gran bloque de encabezado. Google lo quiere por debajo de 2,5 segundos. Cualquier cosa por encima y pierdes tanto posicionamiento como usuarios. Para un desglose completo del diagnóstico y la corrección del LCP específicamente, consulta nuestra guía en profundidad sobre el LCP.
Pasé tres semanas corrigiendo el LCP en la tienda WooCommerce de un cliente el año pasado. Sus páginas de producto cargaban a 6,8 segundos en móvil. Lo bajamos a 2,1 segundos. Así exactamente lo hicimos.
1. Optimiza las imágenes (aquí es donde están la mayoría de las victorias)
Las imágenes son el asesino número uno del LCP. Punto. Nunca he visto un sitio con una mala puntuación de LCP que no tuviera un problema de imágenes.
- Convierte a formato WebP o AVIF. WebP te da archivos un 40-80% más pequeños que JPEG con básicamente la misma calidad. AVIF es aún mejor, pero el soporte del navegador todavía se está poniendo al día.
- Usa imágenes responsivas con srcset para que los usuarios de móvil no descarguen imágenes de 4000px de ancho en una pantalla de 375px. Eso es un desperdicio.
- Aplica carga diferida (lazy-load) a las imágenes que están fuera de la pantalla. No cargues la imagen del pie de página hasta que alguien se desplace hasta ella.
- Sirve imágenes de tamaño adecuado para el viewport. Una imagen de 1200px de ancho está bien para escritorio. Para móvil, 400px son suficientes.
Lo que cambié de verdad: En esa tienda WooCommerce, servíamos las mismas imágenes de producto de 2400px a todos los dispositivos. Usamos `html<img srcset="product-400.webp 400w, product-800.webp 800w, product-1200.webp 1200w" sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px" src="product-800.webp" alt="Product name">` y convertimos todo a WebP. Solo eso recortó el LCP en 2,3 segundos.
2. Elimina los recursos que bloquean el renderizado
Tu <head> probablemente está cargando CSS y JavaScript que bloquean el renderizado. Cada recurso que bloquea el renderizado añade milisegundos a tu LCP.
- Diferir el CSS y el JavaScript no críticos. Si no se necesita para el contenido visible, difiérelo.
- Inserta el CSS crítico en el <head> para los estilos visibles. Esto elimina por completo una petición que bloquea el renderizado.
- Usa rel="preload" para tu imagen principal y las fuentes críticas. Dile al navegador que empiece a descargarlos de inmediato en lugar de esperar.
Lo que cambié de verdad: Encontré tres archivos CSS cargándose en el <head> que bloqueaban el renderizado. Dos de ellos eran para un slider que solo aparecía en la página de inicio. Los movimos a <link rel="preload" as="style" onload="this.rel='stylesheet'"> e insertamos el CSS crítico visible. El LCP bajó otros 0,8 segundos.
3. Mejora el tiempo de respuesta del servidor
Si tu servidor es lento, todo lo demás que hagas será luchar contra corriente.
- Usa un CDN (Cloudflare, Vercel Edge, Fastly). No hay excusa para no usarlo en 2026.
- Activa HTTP/2 o HTTP/3. Múltiples peticiones pueden multiplexarse sobre una sola conexión.
- Optimiza las consultas de base de datos en el backend. Por mi experiencia, sitios WooCommerce donde una sola página disparaba más de 200 consultas de base de datos.
- Implementa estrategias de caché. Caché de página, caché de objetos, caché de navegador: úsalas todas.
Lo que cambié de verdad: Ese mismo cliente de WooCommerce estaba en un hosting compartido de $5/mes. Solo su TTFB era de 1,8 segundos. Lo movimos a un hosting de WooCommerce gestionado con caché a nivel de servidor y un CDN de Cloudflare. El TTFB bajó a 180ms. Esa fue la mayor mejora de LCP que hicimos.
4. Optimiza las fuentes web
Las fuentes personalizadas son bonitas, pero pueden destrozar tu LCP si no tienes cuidado.
- Usa font-display: swap para que el texto sea visible inmediatamente con una fuente de reserva y luego cambie a la fuente personalizada cuando cargue.
- Sub-conjunta las fuentes para incluir solo los caracteres que necesitas. La mayoría de los sitios no necesitan los juegos de caracteres cirílico, griego y vietnamita.
- Precarga las fuentes críticas con <link rel="preload"> para que el navegador las busque pronto.
Lo que cambié de verdad: El cliente estaba cargando tres pesos diferentes de una familia de fuentes (400, 600, 700) más dos familias de fuentes distintas. Sub-conjuntamos cada una solo a caracteres latinos y eliminamos el peso ligero. El tamaño de los archivos de fuente pasó de 380KB en total a 85KB.
El resultado final del LCP
Después de todos estos cambios, llevamos su LCP de 6,8 segundos a 2,1 segundos en móvil. Eso es una mejora del 70%. El tráfico orgánico hacia las páginas de producto aumentó un 34% en los dos meses siguientes. No es una coincidencia.
Corregir el INP (Objetivo: menos de 200ms)
El INP (Interaction to Next Paint) reemplazó al First Input Delay (FID) en 2024 y, sinceramente, es una métrica mucho más difícil de dominar. El FID solo medía el retraso antes de la primera interacción. El INP mide lo rápido que responde tu página a todas las interacciones durante toda la sesión. Si tienes un manejador lento escondido en tu código, el INP lo detecta.
Lo que nadie te cuenta sobre el INP: la mayoría de los sitios fallan por JavaScript que ellos mismos no escribieron. Scripts de terceros, herramientas de analítica, widgets de chat: son los asesinos silenciosos del INP.
1. Divide las tareas largas
El hilo principal del navegador solo puede hacer una cosa a la vez. Si una tarea de JavaScript tarda más de 50ms, bloquea todo: el desplazamiento, los clics, el renderizado. Los usuarios lo perciben como un tartamudeo (jank).
- Divide la ejecución de JavaScript en fragmentos de menos de 50ms usando requestIdleCallback o setTimeout.
- Usa requestIdleCallback para trabajos no urgentes como analítica, precarga o actualizaciones de interfaz no críticas.
- Implementa code splitting y carga diferida para que los usuarios solo descarguen lo que necesitan para la página actual.
Lo que cambié de verdad: Encontré una página de producto que ejecutaba una tarea de JavaScript de 340ms al cargar: un complejo calculador de precios que calculaba impuestos para 12 regiones diferentes. Nadie interactuaba con él al cargar. Lo envolvimos en requestIdleCallback y lo diferimos hasta que el navegador estuviera inactivo. El INP bajó de 420ms a 85ms.
2. Optimiza los manejadores de eventos
Cada clic, toque, desplazamiento y pulsación de tecla dispara un manejador de eventos. Si ese manejador hace demasiado trabajo, tu página se siente lenta.
- Aplica debounce a los manejadores de scroll y resize. Ejecutar lógica compleja en cada evento de scroll casi nunca es necesario.
- Evita manipulaciones complejas del DOM en los callbacks de eventos. Agrupa las lecturas y escrituras del DOM.
- Usa listeners de eventos pasivos cuando sea posible (`htmladdEventListener('scroll', handler, { passive: true })`). Esto permite que el navegador se desplace mientras tu manejador se ejecuta.
Lo que cambié de verdad: Un cliente tenía un encabezado fijo que recalculaba su posición en cada evento de scroll, sin debounce ni throttle. Eso es cientos de veces por segundo. Añadir un simple debounce con un retraso de 16ms lo arregló de inmediato. El INP pasó de 380ms a 120ms.
3. Reduce el trabajo del hilo principal
Cuanto menos JavaScript obligues al navegador a ejecutar, más rápido podrá responder a las interacciones.
- Minimiza el tamaño del bundle de JavaScript. Usa tree-shaking, elimina los exports no utilizados y analiza tu bundle con herramientas como webpack-bundle-analyzer.
- Elimina polyfills y código heredado no utilizados. Si no estás dando soporte a IE11, deja de enviar polyfills para él.
- Usa Web Workers para cálculos pesados como procesamiento de datos, manipulación de imágenes o cálculos complejos.
Lo que cambié de verdad: Al revisar una landing page de SaaS encontré 400KB de JavaScript que nunca se ejecutaba. Era una biblioteca heredada de testeo A/B que había sido reemplazada pero nunca eliminada. Borrarla redujo el bundle en un 40% y el INP mejoró de 290ms a 110ms.
El resultado final del INP
La mayoría de mis clientes aterrizan entre 80-150ms de INP tras la optimización. Menos de 200ms es aprobar, pero apunto a menos de 150ms para darme un margen de seguridad. Recuerda, el INP se mide en el percentil 98: tus peores interacciones importan más que la media.
Corregir el CLS (Objetivo: menos de 0,1)
El CLS mide la estabilidad visual: cuánto se desplaza el diseño de tu página después de empezar a cargar. Piensa en ese momento en el que estás a punto de hacer clic en un enlace y un anuncio carga encima, empujándolo todo hacia abajo. Eso es el CLS, y los usuarios lo odian absolutamente.
El mayor problema de CLS que vi jamás lo causó un sitio de noticias con 14 unidades de anuncios diferentes cargando de forma asíncrona. La página se desplazaba tres o cuatro veces antes de asentarse. Su puntuación de CLS era 0,45. La bajamos a 0,03.
1. Establece dimensiones explícitas
Si no le dices al navegador el tamaño que tendrá un elemento, tiene que adivinar. Y cuando carga el contenido real, todo se desplaza.
- Siempre establece width y height en imágenes y vídeos. Incluso si usas CSS para hacerlos responsivos, el navegador necesita las dimensiones intrínsecas para calcular la relación de aspecto.
- Usa la propiedad CSS aspect-ratio para elementos responsivos: `htmlaspect-ratio: 16 / 9;`
- Reserva espacio para anuncios y embeds. Uso un div placeholder con las dimensiones esperadas que el anuncio rellena cuando carga.
Lo que cambié de verdad: El blog de un cliente insertaba vídeos de YouTube solo con el iframe, sin especificar dimensiones. Envolvimos cada iframe en un contenedor con aspect-ratio: 16 / 9; width: 100%; y establecimos atributos width y height explícitos en el iframe. El CLS bajó de 0,28 a 0,05.
2. Evita el contenido de carga tardía
Cualquier cosa que aparezca después de la carga inicial de la página y empuje el contenido contribuye al CLS.
- No inyectes contenido por encima del contenido existente después de la carga. Si debes hacerlo, pre-asigna espacio para ello.
- Pre-asigna espacio para elementos dinámicos como banners, avisos de cookies y widgets de chat.
- Usa pantallas esqueleto con dimensiones fijas para que el diseño no se desplace cuando cargue el contenido real.
Lo que cambié de verdad: Ese sitio de noticias que mencioné tenía un banner de noticias de última hora que aparecía 2-3 segundos después de cargar la página. Empujaba todo el artículo 120px hacia abajo. Le dimos posición al banner con un placeholder de CSS: `html<div class="banner-slot" style="height: 120px;"></div>` — el espacio siempre estaba ahí, solo permanecía vacío hasta que cargaba el banner.
3. Usa font display swap (de forma estratégica)
Las fuentes personalizadas pueden causar desplazamientos de diseño cuando cargan: la fuente de reserva podría tener un tamaño diferente, haciendo que el texto se refluya.
- Usa font-display: swap para el texto del cuerpo. El texto aparece inmediatamente en una fuente de reserva y luego cambia a la fuente personalizada.
- Usa font-display: optional para fuentes no críticas. Esto elimina el desplazamiento por completo: el navegador o usa la fuente personalizada o se queda con la de reserva, sin cambio.
- Haz coincidir las métricas de tu fuente de reserva. Usa herramientas como fontaine para encontrar fuentes del sistema que se parezcan mucho a tus fuentes web.
Lo que cambié de verdad: Un cliente tenía tres fuentes personalizadas que causaban un CLS de 0,12 solo por el reflujo del texto. Usamos font-display: optional para la fuente de encabezados (solo se usaba en tamaños grandes, donde la diferencia apenas se notaba) y ajustamos las métricas de la fuente de reserva con CSS size-adjust. El CLS por la carga de fuentes bajó a cero.
El resultado final del CLS
La mayoría de los problemas de CLS vienen de anuncios, imágenes y contenido inyectado dinámicamente. Arregla esas tres categorías y normalmente aterrizarás por debajo de 0,1. He logrado que todos los clientes con los que he trabajado aprueben el CLS: normalmente es la más fácil de las tres métricas de corregir una vez que sabes qué buscar.
Lo que cambié de verdad (resumen)
La realidad es que acabo de darte muchos consejos técnicos. Déjame reducirlos a lo que realmente marca la diferencia, por orden de impacto:
- Imágenes — Convierte a WebP, establece dimensiones explícitas, usa srcset, aplica carga diferida bajo el pliegue. Esto corrige el LCP y el CLS simultáneamente.
- JavaScript — Elimina código no utilizado, difiere scripts no críticos, divide las tareas largas. Esto corrige el INP.
- Servidor — Usa un CDN, activa el caché, mejora el hosting si es necesario. Esto corrige el LCP y el FCP.
- Fuentes — Sub-conjunta, precarga y usa font-display de forma estratégica. Esto corrige el LCP y el CLS.
- Estabilidad del diseño — Establece dimensiones en todo, reserva espacio para contenido dinámico. Esto corrige el CLS.
Si solo haces una cosa, arregla tus imágenes. Es el cambio de mayor impacto con el menor esfuerzo. Por mi experiencia, la optimización de imágenes por sí sola mejora el LCP en más de 2 segundos en sitios con muchas imágenes.
Herramientas para medir Core Web Vitals
No puedes arreglar lo que no puedes medir. Estas son las herramientas que uso a diario:
- Google PageSpeed Insights — Datos de laboratorio y de campo. Gratis, fiable y lo que Google usa realmente.
- Chrome User Experience Report (CrUX) — Métricas de usuarios reales de Chrome. Es el estándar de oro para datos de campo.
- Informe de Core Web Vitals en Search Console — Muestra problemas a nivel de URL en todo tu sitio. Genial para encontrar páginas que necesitan atención.
- AuditMe — Análisis automatizado de CWV con recomendaciones de corrección específicas. No solo te dice qué está roto: te dice exactamente qué cambiar.
- Panel Performance de Chrome DevTools — Para profundizar en interacciones específicas e identificar tareas largas.
¿Mi consejo? Empieza con PageSpeed Insights para una vista rápida, luego usa Search Console para encontrar los peores infractores de tu sitio. Una vez identificadas las páginas problemáticas, usa el panel Performance de DevTools para señalar exactamente qué causa el problema. Para sitios WordPress específicamente, nuestra guía sobre optimización de Core Web Vitals para WordPress cubre correcciones plugin a plugin.
Artículos relacionados
- Checklist de SEO Técnico 2026: Crawl, Index, Render, Rank
- Core Web Vitals para WordPress: Guía de Optimización Plugin a Plugin
- Inmersión en el LCP: Diagnosticar y Corregir el Core Web Vital Más Difícil
Pon a prueba tus Core Web Vitals ahora
Deja de adivinar y empieza a medir. Ejecuta un análisis gratuito de Core Web Vitals en cualquier URL. Obtendrás una puntuación de semáforo para las cinco métricas más pasos de optimización específicos ordenados por impacto. Sin registro: solo pega tu URL y mira exactamente dónde estás.
Eduard Tymchenko
SEO Expert & Founder of AuditMe
“I built AuditMe after 10+ years of manual SEO audits — every check in this report is one I used to run by hand.”
Specializes in technical SEO, Core Web Vitals, and WordPress optimization.
Ejecuta tu auditoría SEO gratuita
Obtén un análisis SEO completo de cualquier URL en 60 segundos. Sin registro.
O abre el analizador completo con más detalles
Analiza tu sitio gratisHerramientas SEO gratuitas
Artículos relacionados
Continúa aprendiendo con estas guías y tutoriales de SEO:
Your Website Was Seen 116,181 Times and Clicked 9 Times. Here's What Search Engines and AI Systems Are Actually Doing.
A first-party 2026 investigation from AuditMe into the Visibility Gap: how crawling, indexing, retrieval, ranking, AI citations, clicks, trust, and conversions form one measurable website intelligence system.
21 min read
How AI Systems Read the Web in 2026: Discovery, Retrieval, Citations and Agents
An evidence-first guide to AI search, GEO, retrieval, entity clarity, citations and agent-ready websites — with a practical framework, implementation patterns and a proposed open benchmark methodology.
45 min read
The New SEO: When Search Engines Stop Reading Websites and Start Using Them
Search is moving from ranking pages to running them as machine interfaces. This guide explains the six-dimension Website Intelligence framework — discoverability, understanding, verification, actionability, reliability, and observability — that makes your site machine-readable, verifiable, and actionable for AI search engines and agents.
23 min read
AI Readiness Guide: llms.txt, AI Bot Access & Semantic HTML for AI Search in 2026
Is your website ready for AI search? Complete guide to llms.txt, AI bot access, semantic HTML, and content architecture for ChatGPT, Claude, Perplexity, and Gemini in 2026.
24 min read