INP sustituyó a FID como Core Web Vital el 12 de marzo de 2024. En 2026 las tres métricas siguen siendo LCP, INP y CLS. INP evalúa la respuesta durante la visita, no solo el retraso antes de la primera interacción. Esto cambia qué problemas conviene investigar.
Google evalúa los valores reales en el percentil 75, por separado para móvil y escritorio: LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1. Una prueba de laboratorio con Lighthouse no sustituye esa evaluación. Mejorar estos valores ayuda a la experiencia, pero no garantiza posiciones, consultas ni ventas.
LCP (Largest Contentful Paint): Velocidad de Carga Percibida#
LCP mide cuanto tiempo tarda en renderizarse completamente el elemento visible mas grande en el viewport. Típicamente es una imagen hero, un poster de video o un bloque de texto grande. Google espera un valor LCP inferior a 2,5 segundos.
Problemas de LCP Mas Comunes#
- Imágenes sin comprimir: Una imagen hero de 2,4 MB en lugar de 180 KB como WebP
- CSS/JS que bloquean el renderizado: Hojas de estilo y scripts que retrasan el rendering
- Tiempos de respuesta del servidor lentos (TTFB): Consultas a base de datos que tardan 800ms+
- Falta de indicaciones de preload: El navegador descubre el elemento LCP demasiado tarde
Estrategia de Optimización#
Optimización de Imágenes:
- WebP o AVIF como formato estándar (30-50% mas pequeño que JPEG)
srcsetresponsive con breakpoints definidos: 640w, 768w, 1024w, 1280w, 1920wloading="eager"yfetchpriority="high"para el elemento LCP<link rel="preload" as="image">en el head para la imagen hero
Lado del Servidor:
- Static Generation (SSG) donde sea posible. El HTML pre-renderizado puede reducir trabajo del servidor; mide la entrega real y el efecto en LCP
- Caching en CDN con headers stale-while-revalidate
- Edge Functions para contenido personalizado sin round-trips al backend
- TTFB inferior a 200ms como objetivo
INP (Interaction to Next Paint): La Nueva Métrica Reina#
INP mide la capacidad de respuesta de una pagina a traves de todas las interacciones del usuario. Clics, toques, entradas de teclado. A diferencia de FID, que solo evaluaba la primera interacción, INP captura una de las interacciones más lentas durante toda la visita. Google espera un valor INP de hasta 200 milisegundos.
Cuando hay muchas interacciones, INP descarta algunos valores atípicos: excluye una de las más lentas por cada 50 interacciones. Desplazarse y pasar el cursor no cuentan como interacciones de INP, aunque sus manejadores pueden ocupar el hilo principal.
Por Que INP Es Mas Exigente Que FID#
FID era relativamente fácil de optimizar porque solo contaba el primer clic. INP es mas estricto: si un usuario hace clic en un botón después de 30 segundos y el hilo principal esta bloqueado por un bundle JavaScript pesado, eso degrada la puntuación INP de toda la pagina.
Estrategia de Optimización#
Optimización de JavaScript:
- Code Splitting: Cargar solo el código JavaScript necesario para la pagina actual. Con Next.js, esto ocurre automáticamente por ruta
- Dynamic Imports: Cargar bibliotecas pesadas (vistas de mapa, gráficos, editores) solo bajo demanda
- Web Workers: Trasladar tareas de computación intensiva fuera del hilo principal
- Debouncing y Throttling: Limitar handlers de scroll y resize
Optimización de Renderizado:
content-visibility: autopara secciones fuera de pantalla- CSS Containment (
contain: layout style paint) para componentes aislados - Virtualizacion para listas largas (react-window, @tanstack/virtual)
requestAnimationFrameen lugar desetTimeoutpara actualizaciones visuales
Scripts de Terceros:
- Cargar analytics y tracking de forma asíncrona o diferida
- Verificar el impacto en rendimiento de las plataformas de gestión de consentimiento (algunas bloquean el hilo principal 300ms+)
- Mantener los tag managers ligeros. Los tags adicionales pueden afectar la respuesta
CLS (Cumulative Layout Shift): Estabilidad Visual#
CLS mide cuanto se desplazan los elementos visibles durante la carga. Nada frustra mas a los usuarios que un botón que salta en el ultimo momento. Google espera un valor CLS inferior a 0,1.
Causantes Mas Comunes de CLS#
- Imágenes sin dimensiones: El navegador no reserva espacio hasta que la imagen carga
- Banners publicitarios inyectados dinamicamente: Empujan el contenido hacia abajo
- Web fonts: El cambio de fuente (FOUT/FOIT) desplaza bloques de texto
- Contenido dinámico: Banners de cookies, widgets de chat, barras de notificación
Estrategia de Optimización#
Reserva de Layout:
- Atributos
widthyheighten todos los elementos<img>y<video> aspect-ratioen CSS como fallback- Skeleton screens para contenido dinámico (placeholders con el tamaño exacto del elemento final)
Carga de Fuentes:
font-display: optional: El navegador decide si muestra la web font según tiempo y conexión. Comprueba la fuente de respaldo y posibles cambios de layout.- Precargar archivos de fuentes con
<link rel="preload"> - Usar fuentes subset (embeber solo los caracteres necesarios)
- Variable fonts en lugar de multiples archivos de fuentes
Elementos Dinámicos:
- Banners de consentimiento de cookies con
position: fixeden lugar de layout de flujo - Ads con min-height reservado
- Widgets de chat como overlay, no como parte del flujo del documento
Medir las mejoras de forma comparable#
Anota URL, fecha, dispositivo, conexión y herramienta en cada medición. Compara datos reales en periodos equivalentes. Una prueba habitual de carga con Lighthouse no da el INP de toda una visita; hacen falta interacciones reales, datos de CrUX o RUM propio. Documenta los cambios por separado cuando sea posible. Un mejor resultado no demuestra por sí solo un efecto sobre ingresos o posiciones.
SSR vs. Static Generation: La Estrategia de Rendering Correcta#
La estrategia de rendering tiene un impacto masivo en los Core Web Vitals:
- Static Site Generation (SSG): Las paginas se generan en tiempo de build. Puede agilizar la entrega; LCP depende también de imágenes, CSS, red y dispositivo. Ideal para landing pages, artículos de blog, catálogos de productos
- Server-Side Rendering (SSR): Las paginas se generan por petición. Mas flexible pero TTFB mas lento. Necesario para contenido personalizado o altamente dinámico
- Incremental Static Regeneration (ISR): Combinación de ambos. Paginas estáticas que se actualizan en segundo plano. Mejor compromiso para la mayoría de sitios web
Recomendación: Use SSG como opción predeterminada y SSR solo donde sea realmente necesario. Cada pagina que pueda servirse como HTML estático puede reducir trabajo del servidor; mide el efecto real en LCP.
Configuración CDN: Optimizando la Ultima Milla#
Un CDN mal configurado puede anular todas las optimizaciones. Estas configuraciones son criticas:
- Headers Cache-Control:
public, max-age=31536000, immutablepara assets estáticos - Stale-While-Revalidate: Sirve la version en cache mientras actualiza en segundo plano
- Compresión Brotli: 15-20% mas pequeño que Gzip, soportado por todos los navegadores modernos
- HTTP/3: Reduce la latencia mediante el protocolo QUIC
- Edge Computing: Ejecutar tareas de computación intensiva mas cerca del usuario
Conclusion: El Rendimiento No Es un Proyecto, Sino un Proceso#
La optimización de Core Web Vitals no es una tarea puntual. Cada nueva funcionalidad, cada plugin, cada integración de terceros puede degradar las puntuaciones. Integre el monitoreo de rendimiento en su proceso de desarrollo:
- Lighthouse CI en el pipeline de build (bloquea deployments ante regresión de puntuación)
- Real User Monitoring (RUM) via la API Chrome UX Report
- Revisiones semanales de rendimiento dentro del equipo
Mide periódicamente qué cambios ayudan de verdad a tus visitantes. Compara también consultas y acciones completadas, sin confundir un mejor valor de laboratorio con un éxito comercial automático.
