Optimización de Velocidad Web 2026: Corrige LCP, INP y CLS Paso a Paso
Optimización de Velocidad Web 2026: Corrige LCP, INP y CLS Paso a Paso
¿Cómo mejorar los Core Web Vitals de un sitio web? Los Core Web Vitals son tres métricas de experiencia de usuario: LCP (carga del elemento principal, objetivo < 2.5s), INP (respuesta a interacciones, objetivo < 200ms) y CLS (estabilidad visual, objetivo < 0.1). Para mejorarlos necesitas identificar el elemento problemático en cada métrica con PageSpeed Insights, aplicar la técnica correcta (preload para LCP, reducción de JavaScript para INP, dimensiones explícitas para CLS) y verificar el impacto en datos reales de CrUX. El proceso iterativo de medir, cambiar y verificar es el único camino a métricas verdes sostenibles. Consulta Gratuita →
En 2021, Google convirtió los Core Web Vitals en un factor de ranking con la actualización Page Experience. En 2024, INP reemplazó definitivamente a FID como la métrica de interactividad. En 2026, los sitios con métricas en rojo tienen una desventaja real en posicionamiento — especialmente en SERPs competitivas donde el contenido de los candidatos es similar.
Pero más allá del SEO, los CWV son indicadores directos de experiencia de usuario. Un LCP alto significa que el usuario espera para ver el contenido principal. Un INP alto significa que los botones y formularios responden lento. Un CLS alto significa que el contenido salta mientras se carga — una de las experiencias más frustrantes en web.
Esta guía aborda cada métrica en profundidad: qué la causa, cómo diagnosticarla y las técnicas específicas para mejorarla, con ejemplos de código donde son necesarios.
Tabla de Contenidos
1. Qué son los Core Web Vitals y por qué importan en 2026 2. Herramientas de diagnóstico: cuál usar y cuándo 3. LCP: diagnóstico y optimización completa 4. INP: diagnóstico y reducción de latencia de interacción 5. CLS: causas y estabilización del layout 6. Métricas auxiliares: TTFB, FCP, TBT 7. Tabla de objetivos y herramientas 8. Guía práctica de implementación 9. FAQ 10. Conclusión
El Problema: Por Qué Tantos Sitios Tienen CWV en Rojo
Según los datos de CrUX de Google, menos del 50% de los sitios web cumplen con los umbrales de CWV en todos sus campos. Los problemas más frecuentes son:
- Imágenes hero sin preload y en formato no optimizado (causa LCP alto)
- Scripts de terceros que bloquean el hilo principal (causa INP alto)
- Anuncios, banners o elementos sin dimensiones definidas (causa CLS alto)
- Fuentes web que cambian el layout al cargarse (FOUT, causa CLS)
La mayoría de estos problemas son resolubles sin rediseñar el sitio. Requieren cambios técnicos específicos, muchos de ellos en el HTML o la configuración del servidor, no en el diseño visual.
Qué son los Core Web Vitals y Por Qué Importan en 2026
Google define tres señales de "experiencia de página" bajo el paraguas de Core Web Vitals:
LCP (Largest Contentful Paint): El tiempo hasta que el elemento visual más grande visible en el viewport se carga completamente. Generalmente es la imagen hero, el video de portada o el bloque de texto principal. Mide la percepción de velocidad de carga.
INP (Interaction to Next Paint): El tiempo desde que el usuario hace clic, toca o escribe hasta que el navegador actualiza la pantalla como respuesta. Reemplazó a FID en marzo de 2024 porque mide todas las interacciones a lo largo de la visita, no solo la primera.
CLS (Cumulative Layout Shift): Una medida de cuánto se desplaza el contenido visual durante la carga. Un botón que se mueve porque una imagen tardó en cargarse, un texto que salta porque se insertó un banner — todo esto acumula CLS.
Herramientas de Diagnóstico: Cuál Usar y Cuándo
| Herramienta | Tipo de Datos | Cuándo Usarla | Limitación |
|---|---|---|---|
| PageSpeed Insights | Lab + Field (CrUX) | Diagnóstico inicial y verificación | Una URL a la vez |
| Lighthouse (DevTools) | Lab | Iteración durante desarrollo | No refleja datos reales |
| CrUX Dashboard | Field (reales) | Monitoreo de tendencias | Requiere suficiente tráfico |
| Search Console (CWV) | Field (reales) | Ver URLs afectadas en producción | Sin desglose de causas |
| WebPageTest | Lab detallado | Diagnóstico profundo, filmstrip | Curva de aprendizaje |
| Chrome DevTools Performance | Lab | Análisis de JavaScript y renderizado | Solo una sesión |
| DebugBear | Lab + Field | Monitoreo continuo en CI/CD | Herramienta de pago |
La regla de oro: Usa datos Lab (Lighthouse, WebPageTest) para identificar problemas y medir el impacto de tus cambios. Usa datos Field (CrUX, Search Console) para confirmar que los cambios mejoraron la experiencia real de los usuarios. Los datos Lab miden condiciones controladas; los datos Field miden lo que realmente experimentan tus usuarios en sus dispositivos y conexiones.
LCP: Diagnóstico y Optimización Completa
Identificar el Elemento LCP
Abre Chrome DevTools, ve a la pestaña Performance y graba una sesión de carga. Haz clic en el punto LCP en la línea de tiempo. DevTools te muestra exactamente qué elemento es el LCP y por qué tardó.
Las categorías de LCP más frecuentes son:
- Imagen hero (
<img>o CSS background-image) - Video poster frame
- Bloque de texto con fuente web
- Elemento con imagen de fondo CSS
Cada categoría tiene sus técnicas específicas.
Optimización de LCP para Imágenes Hero
Técnica 1: Preload de la imagen LCP
El preload instruye al navegador a descargar la imagen LCP antes de procesar el resto del HTML. Sin preload, el navegador descubre la imagen solo cuando parsea el HTML y llega al tag <img> — demasiado tarde.
``html <link rel="preload" fetchpriority="high" as="image" href="/images/hero.webp" type="image/webp" /> ``
En Next.js, esto se consigue con la prop priority en next/image.
Técnica 2: Convertir a WebP o AVIF
WebP reduce el tamaño de imagen un 25-35% respecto a JPEG. AVIF reduce hasta un 50% pero tiene soporte de navegadores más limitado. Para producción, sirve WebP con fallback JPEG:
``html <picture> <source srcset="/images/hero.avif" type="image/avif" /> <source srcset="/images/hero.webp" type="image/webp" /> <img src="/images/hero.jpg" alt="Hero image" width="1200" height="630" /> </picture> ``
Técnica 3: CDN con edge locations
La distancia física entre el servidor y el usuario afecta directamente el TTFB y por tanto el LCP. Un CDN con edge locations en múltiples regiones sirve la imagen desde el nodo más cercano al usuario. Vercel, Cloudflare y AWS CloudFront son las opciones más habituales.
Técnica 4: Compression y dimensiones correctas
No sirvas una imagen de 2400px de ancho para un contenedor de 800px. Genera variantes de tamaño para cada breakpoint. En Next.js, next/image hace esto automáticamente con el atributo sizes.
Factores que Afectan el LCP
| Factor | Impacto en LCP | Técnica de Mejora |
|---|---|---|
| Sin preload en imagen hero | Alto | fetchpriority="high" + <link rel="preload"> |
| Imagen en formato JPEG/PNG | Medio | Convertir a WebP/AVIF |
| Imagen sin CDN (servidor lejano) | Alto | Activar CDN con edge locations |
| Imagen sobredimensionada | Medio | Imágenes responsive con srcset |
CSS en <head> que bloquea renderizado | Alto | Critical CSS inline + defer del resto |
| Fuentes web sin preload | Medio | <link rel="preload"> para la fuente principal |
| Servidor lento (TTFB > 800ms) | Muy Alto | ISR, caché de servidor, hosting mejorado |
INP: Diagnóstico y Reducción de Latencia de Interacción
INP (Interaction to Next Paint) es la métrica más técnica de los CWV porque requiere entender el event loop de JavaScript. Cuando el hilo principal está ocupado ejecutando JavaScript, las interacciones del usuario (clics, teclado) se ponen en cola y responden tarde.
Identificar Problemas de INP
En Chrome DevTools, la pestaña Performance muestra las tareas largas (Long Tasks) como barras rojas. Cualquier tarea que supere 50ms contribuye a un INP alto. Las causas más frecuentes son:
- Scripts de terceros (analytics, chat bots, tag managers con mucho JavaScript)
- Event listeners que ejecutan código pesado en cada keystroke o scroll
- Re-renderizados costosos en frameworks SPA (React, Vue, Angular)
- Hydration de componentes que ejecuta mucho JavaScript en carga inicial
Técnicas de Optimización INP
Técnica 1: Reducir el bundle de JavaScript
Cada kilobyte de JavaScript que el navegador descarga, parsea y ejecuta ocupa tiempo en el hilo principal. Analiza tu bundle con @next/bundle-analyzer o webpack-bundle-analyzer para identificar dependencias grandes que podrían eliminarse o reemplazarse.
Técnica 2: Code splitting y lazy loading
No cargues en la página principal el código que solo se necesita en interacciones específicas. En React/Next.js:
```typescript import dynamic from 'next/dynamic';
const HeavyModal = dynamic(() => import('./HeavyModal'), { loading: () => <div>Cargando...</div>, ssr: false, }); ```
El componente HeavyModal solo se carga cuando se necesita, no en el bundle principal.
Técnica 3: Debouncing en event listeners de alta frecuencia
Los event listeners en input, scroll o resize pueden dispararse cientos de veces por segundo. El debouncing retrasa la ejecución hasta que el usuario deja de interactuar:
```typescript function debounce<T extends (...args: unknown[]) => void>( fn: T, delay: number ): (...args: Parameters<T>) => void { let timer: ReturnType<typeof setTimeout>; return (...args) => { clearTimeout(timer); timer = setTimeout(() => fn(...args), delay); }; }
const handleSearch = debounce((query: string) => { fetchResults(query); }, 300); ```
Técnica 4: Diferir scripts de terceros
Los scripts de análisis, publicidad y chat no son críticos para la primera carga. Cárgalos con defer o async, o mejor aún, condicionalmente tras la primera interacción del usuario:
``typescript // Cargar analytics solo tras la primera interacción window.addEventListener('click', () => { loadGoogleAnalytics(); }, { once: true }); ``
Técnica 5: Web Workers para tareas pesadas
Las tareas de procesamiento intensivo (parseo de datos, cálculos complejos) pueden moverse a un Web Worker, liberando el hilo principal para las interacciones del usuario. Esta técnica es especialmente efectiva en dashboards y aplicaciones con mucho JavaScript de negocio.
CLS: Causas y Estabilización del Layout
CLS mide el desplazamiento acumulado del layout durante la vida de la página. Cada vez que un elemento se mueve inesperadamente, Google calcula un score de desplazamiento. La suma de todos estos desplazamientos durante la carga y la primera interacción es el CLS.
Causas Más Frecuentes de CLS Alto
Imágenes sin dimensiones explícitas: Cuando una imagen carga sin que el navegador conozca su tamaño, el layout se reorganiza al recibirla. La solución es siempre declarar width y height:
```html <!-- Causa CLS --> <img src="/imagen.jpg" alt="Descripción" />
<!-- Previene CLS --> <img src="/imagen.jpg" alt="Descripción" width="800" height="450" /> ```
En CSS moderno, puedes preservar el aspect ratio con:
``css img { aspect-ratio: attr(width) / attr(height); height: auto; width: 100%; } ``
Fuentes web con FOUT (Flash of Unstyled Text): Cuando la fuente web carga después del texto, puede cambiar el espaciado y tamaño de los caracteres, causando un layout shift. La solución es font-display: optional (no usa la fuente web si tarda demasiado) o font-display: swap combinado con preload de la fuente:
``css @font-face { font-family: 'MiFuente'; src: url('/fonts/mi-fuente.woff2') format('woff2'); font-display: swap; } ``
``html <link rel="preload" href="/fonts/mi-fuente.woff2" as="font" type="font/woff2" crossorigin /> ``
Banners y anuncios sin espacio reservado: Los elementos que se insertan dinámicamente (banners de cookies, notificaciones, anuncios) empujan el contenido existente. La solución es reservar el espacio con un placeholder de las mismas dimensiones antes de que el elemento cargue:
``css .banner-placeholder { min-height: 90px; /* Altura del banner cuando cargue */ width: 100%; } ``
Elementos posicionados dinámicamente: Los componentes que cambian de posición o tamaño en respuesta a datos asincrónicos (contadores, precios, disponibilidad) deben tener un estado de carga con las mismas dimensiones que el estado final.
Verificar el CLS con DevTools
Chrome DevTools tiene una capa de depuración específica para CLS. En la pestaña Performance, activa "Layout Shift Regions" en la opción de capas. Las regiones que shiftan se iluminan en azul durante la grabación, identificando exactamente qué elemento causó el desplazamiento.
Métricas Auxiliares
| Métrica | Objetivo | Qué Mide | Cómo Mejorarla |
|---|---|---|---|
| TTFB | < 800ms | Tiempo hasta primer byte del servidor | CDN, ISR, Edge Runtime |
| FCP | < 1.8s | Primera pintura con contenido | Critical CSS inline, preload fuentes |
| TBT | < 200ms | Total Blocking Time (proxy de INP en Lab) | Reducir Long Tasks, code splitting |
| Speed Index | < 3.4s | Velocidad de renderizado progresivo | Priorizar CSS above-the-fold |
Tabla de Objetivos y Puntuaciones
| Métrica | Verde (Bueno) | Amarillo (Necesita Mejora) | Rojo (Pobre) |
|---|---|---|---|
| LCP | < 2.5s | 2.5s - 4.0s | > 4.0s |
| INP | < 200ms | 200ms - 500ms | > 500ms |
| CLS | < 0.1 | 0.1 - 0.25 | > 0.25 |
| TTFB | < 800ms | 800ms - 1800ms | > 1800ms |
| FCP | < 1.8s | 1.8s - 3.0s | > 3.0s |
Guía Práctica: Proceso de Optimización en 6 Fases
Fase 1: Diagnóstico inicial. Ejecuta PageSpeed Insights en las 5 páginas más importantes de tu sitio: home, página de servicio principal, artículo de blog más visitado, página de contacto y cualquier landing page de campaña. Documenta las métricas de campo (CrUX) y las oportunidades identificadas por Lighthouse.
Fase 2: Identificar las causas raíz. Para cada métrica en rojo o amarillo, usa las herramientas específicas: Performance tab de DevTools para LCP e INP, Layout Shift Regions para CLS. No apliques técnicas al azar — identifica primero qué elemento específico está causando el problema.
Fase 3: Priorizar por impacto. No todos los problemas merecen el mismo esfuerzo. Prioriza: los cambios que mejoran métricas de campo reales (no solo datos Lab) y las páginas con más tráfico orgánico. Un LCP de 4.5s en una página con 10.000 visitas mensuales es más urgente que uno de 3.8s en una página con 100.
Fase 4: Implementar en orden de dificultad creciente. Empieza con los cambios de mayor impacto y menor complejidad: preload de imagen LCP, dimensiones explícitas en imágenes, diferir scripts de terceros. Luego avanza a cambios más técnicos: code splitting, Critical CSS, optimización de fuentes.
Fase 5: Verificar con datos reales. Los cambios en datos Lab son instantáneos. Los cambios en datos Field (CrUX) tardan 28 días en reflejarse completamente porque CrUX usa una ventana de 28 días. Configura un dashboard de seguimiento en Search Console o CrUX Dashboard para monitorear la tendencia.
Fase 6: Prevenir regresiones con CI/CD. Configura Lighthouse CI en tu pipeline de GitHub Actions o similar para que cada pull request incluya una comparativa de métricas. Define umbrales de fallo: si un PR empeora el LCP en más de 500ms, bloquear el merge hasta revisar.
FAQ
¿Los Core Web Vitals afectan directamente el ranking en Google? Sí, pero con matices. Google usa CWV como factor de desempate entre páginas con relevancia similar. En la práctica, una página con contenido muy relevante y CWV en rojo puede seguir superando a una página con CWV en verde pero contenido menos relevante. Sin embargo, en SERPs competitivas donde la calidad del contenido es homogénea, los CWV pueden ser el factor decisivo. Además, el impacto indirecto es mayor: mejores CWV significan menor tasa de rebote y más tiempo en página, señales que Google también considera.
¿CrUX y Lighthouse muestran valores diferentes para el mismo sitio. Cuál es correcto? Ambos son correctos, pero miden cosas diferentes. Lighthouse ejecuta una prueba controlada en condiciones simuladas desde un servidor con conexión y hardware específicos. CrUX recopila datos reales de usuarios de Chrome en sus dispositivos y conexiones reales. Un sitio puede pasar Lighthouse con 90+ pero tener CrUX en rojo si sus usuarios reales tienen dispositivos lentos o conexiones móviles. Para SEO, lo que importa son los datos de campo (CrUX), no los de laboratorio.
¿Qué es más importante optimizar primero: LCP, INP o CLS? Depende de cuál está más lejos del umbral verde en datos de campo reales. En la práctica, LCP es el problema más frecuente y tiene el mayor impacto percibido por los usuarios. CLS es el más frustrante para la experiencia de usuario. INP es el más técnico de resolver. Si los tres tienen problemas, empieza por LCP porque tiene las técnicas más impactantes y directas.
¿Cuánto tiempo tarda en mejorar el CWV en Google Search Console después de aplicar cambios? Search Console muestra datos de CrUX con una ventana de 28 días. Esto significa que los cambios tardan hasta 28 días en reflejarse completamente en los reportes de Search Console. Puedes usar PageSpeed Insights para ver la mejoría en los datos Lab inmediatamente, pero para confirmar el impacto en usuarios reales necesitas esperar el período de CrUX.
¿Los anuncios de Google Ads (AdSense) afectan los Core Web Vitals? Sí, significativamente. Los anuncios insertan elementos de forma asincrónica que pueden causar CLS si no se reserva espacio previo, y cargan JavaScript de terceros que aumenta el TBT y puede empeorar el INP. Para mitigar el impacto: reserva espacio fijo para cada unidad de anuncio, carga los scripts de AdSense con async y evita colocar anuncios en el área visible inicial (above-the-fold) si el LCP ya está cerca del umbral.
¿Los sitios de WordPress pueden alcanzar Core Web Vitals en verde? Sí, pero requiere más trabajo que en un sitio estático o Next.js. Las claves son: usar un hosting con soporte de caché de página completa (WP Rocket, NitroPack o Cloudflare APO), optimizar las imágenes con un plugin como ShortPixel o Imagify, limitar los plugins activos a los estrictamente necesarios y elegir un tema liviano que no cargue CSS y JavaScript innecesarios. Los themes de construcción visual como Elementor o Divi son problemáticos para INP — el código que generan es pesado.
¿Afectan los Core Web Vitals al SEO en dispositivos móviles y de escritorio por igual? Google evalúa CWV de forma separada para móvil y escritorio. El ranking móvil se basa en datos CWV de dispositivos móviles, y el ranking de escritorio en datos de escritorio. Los dispositivos móviles son generalmente más lentos y tienen conexiones más variables, por lo que es más difícil alcanzar los umbrales en móvil. Prioriza la optimización móvil porque la indexación mobile-first de Google hace que esos datos sean más determinantes.
¿Qué hago si no tengo suficiente tráfico para que aparezca CrUX para mi sitio? Si tu sitio no tiene suficiente tráfico para que Google recopile datos CrUX suficientes (generalmente se necesitan cientos de visitas mensuales de usuarios de Chrome), Search Console mostrará "datos insuficientes". En ese caso, usa exclusivamente Lighthouse y WebPageTest como referencia. Trabaja para alcanzar puntuaciones de 90+ en Lighthouse — cuando el tráfico crezca y CrUX empiece a recopilar datos, los valores reales probablemente reflejarán la calidad del trabajo en Lab.
Conclusión
Los Core Web Vitals son métricas de experiencia de usuario antes que métricas de SEO. Optimizarlos mejora el posicionamiento, pero más importante, reduce la tasa de rebote, aumenta el tiempo en página y mejora la tasa de conversión. Un sitio que carga en 1.5s convierte mejor que uno que carga en 4s, independientemente de su posición en Google.
El proceso es siempre el mismo: medir con datos reales, identificar la causa raíz específica de cada problema, aplicar la técnica correcta, verificar el impacto. No existe un atajo que mejore todos los CWV simultáneamente — cada métrica tiene sus causas y sus soluciones.
¿Quieres que auditemos los Core Web Vitals de tu sitio y generemos un plan de optimización priorizado? Nuestro equipo en Modern Web SEO combina auditoría técnica con implementación directa. Obtener Cotización Gratuita →
Para más contexto sobre cómo abordamos el rendimiento en nuestros proyectos, visita nuestra página de servicios de diseño web o el portafolio de proyectos. También puedes consultar nuestra página de nosotros para conocer al equipo.
