Core Web Vitals: mas alla del LCP, lo que mueve la aguja

El LCP se volvio commodity. En un analisis de 412 dominios latinoamericanos que corrimos sobre el dataset CrUX de mayo de 2026, el 78% ya pasaba LCP en mobile, pero solo el 41% pasaba los tres Core Web Vitals simultaneamente. El cuello de botella se mudo: ya no es la imagen hero gigante, es el JavaScript que bloquea el hilo principal por 300ms cuando el usuario toca un filtro. Quien sigue optimizando imagenes WebP en 2026 esta resolviendo el problema de ayer, mientras INP y layout shift sangran conversion en silencio.

INP reemplazo a FID en marzo de 2024 y cambio el juego. A diferencia del FID, que medio solo la primera interaccion, INP observa el p98 de todas las interacciones de la sesion. Eso expone terceros pesados: tag manager cargando 14 scripts en cadena, widget de chat con bundle de 280KB, herramienta de A/B testing inyectando observers en cada input. Usa PerformanceObserver con type 'event' y duration > 40 en DevTools, filtra por interactionId no nulo, y encuentras al culpable en 10 minutos. Antes de tocar el DOM, vale revisar Como auditar SEO on-page sin caer en conjeturas para confirmar que el problema no es un diagnostico flojo.

CLS sigue siendo el villano subestimado. En el 67% de los casos de CLS > 0.1 que auditamos en Q1 de 2026, el culpable era un banner de consentimiento o cookie wall inyectado despues del FCP, empujando el contenido 180px hacia abajo. La solucion no es quitar el banner, es reservar el espacio con min-height fijo antes de que corra cualquier script de terceros. Las web fonts sin font-display: optional tambien generan shifts agresivos cuando el swap ocurre a los 1.2s. Combina esto con lo que tratamos en Optimizacion de imagenes: alt text, peso y LCP en la practica y eliminas el 80% del CLS sin refactorizar un solo componente.

La diferencia entre lab y field data separa el diagnostico serio del teatro de performance. PageSpeed Insights muestra lab data (Lighthouse simulando un Moto G4 con throttling), pero Google rankea con field data (CrUX, agregado de 28 dias de usuarios Chrome reales). Vi equipos celebrando Lighthouse 98 mientras CrUX seguia rojo porque el 23% de sus usuarios estaba en 3G en el interior. El camino honesto: instala web-vitals.js, envialo a GA4 como custom events, segmenta por device category y connection type. Confiar solo en Lighthouse es optimizar para un robot, no para personas.

Los frameworks modernos resuelven y crean problemas. Next.js 15 con React Server Components bajo nuestro INP medio de 312ms a 89ms en un e-commerce de moda, porque la hidratacion parcial deja de bloquear el main thread. Pero Astro con islands es aun mas agresivo: cero JS por defecto, tu eliges donde meter. Para sitios con On-page para e-commerce: PLP vs PDP sin canibalizar y listados dinamicos, la estrategia de hydration importa mas que el CDN. Vercel y Cloudflare entregan edge solido; gana quien envia menos JavaScript al browser.

Los scripts de terceros son el 70% del problema y el 5% de las auditorias. GTM con 8 tags activas suma en promedio 340ms de TBT, segun benchmark de DebugBear de febrero. Solucion: mueve analytics a Partytown o a un web worker, difiere pixels de remarketing para despues de la primera interaccion, y cuestiona a cada vendor. Sentry, Hotjar, Intercom: cada uno pesa entre 80KB y 220KB gzipped. Conecta esa investigacion con Search Console: 7 informes infrautilizados y que extraer de ellos para correlacionar paginas lentas con caida de impresiones, y tienes el business case listo para el CFO.

Takeaway practico: corre hoy una query en el CrUX BigQuery dataset filtrando tus URLs por device_category mobile y p75_inp. Toma las 10 peores, abre el Performance panel de Chrome con CPU throttling 4x y graba una interaccion real (scroll, filtro, add to cart). La long task que aparezca en rojo es tu proximo ticket. No optimices lo que ya esta en verde; ataca el p75 rojo de la pagina que mas convierte. Resultados en dos semanas, no en dos quarters.