Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
Telemetría del frontend headless: información de usuarios reales más allá de los Web Vitals
Lighthouse te da el pulso de tu storefront en laboratorio. La telemetría de usuarios reales muestra lo que tus compradores experimentan de verdad y, en los storefronts composable, esos dos mundos se separan más que en ningún otro sitio. Este artículo explica por qué los Web Vitals clásicos no bastan para las arquitecturas headless y qué 5 señales de telemetría necesitas instrumentar ya.
Qué es la telemetría de usuarios reales y dónde termina Lighthouse
Definición: Real User Monitoring (RUM) vs. Synthetic Monitoring. El RUM recoge datos de rendimiento directamente en el navegador de los visitantes reales, en cada carga de página, en cada región y en cada dispositivo. El synthetic monitoring (Lighthouse, WebPageTest, pruebas de navegador con k6) ejecuta scripts predefinidos desde un entorno de laboratorio, normalmente con un puñado de perfiles de dispositivo y limitaciones de red.
Aspecto | Synthetic (Lighthouse) | RUM (telemetría de usuarios reales) |
|---|---|---|
Fuente de datos | Script de laboratorio | Tráfico real de navegador |
Tamaño de muestra | de 1 a N ejecuciones de prueba | 100% de las sesiones |
Red | Limitada, simulada | Enrutamiento real del operador |
Parque de dispositivos | Pocos perfiles | Larga cola de todos los dispositivos |
Realismo de la interacción | Basado en scripts | Comportamiento de usuarios reales |
Detecta | Regresiones previas al despliegue | Lo que sienten los compradores ahora mismo |
Puntos ciegos | Soft navigations, cola de hidratación | Daños previos al despliegue |
El synthetic es excelente para gates de CI y comprobaciones de cordura previas al despliegue. En el momento en que un storefront sale a producción, el RUM es la única fuente que te dice qué está experimentando realmente tu comprador móvil en Madrid con un Pixel 5 en 4G.
Por qué los storefronts composable tienen la mayor brecha de telemetría
Los frontends monolíticos clásicos son un único bundle, servido desde un único origen y renderizado por un único render path. Los storefronts composable rompen cada una de esas premisas:
- Múltiples orígenes: El shell del storefront desde una CDN, el contenido del CMS desde Hygraph o Storyblok, los datos de producto desde commercetools o Shopify, la búsqueda desde Algolia, los pagos desde Stripe. Cada origen tiene sus propios RTT, sus propios handshakes TLS y su propio perfil de caídas.
- Varias apps en el mismo layout: El header desde la app A, la parrilla de productos desde la app B, el motor de recomendación desde la app C. Las long tasks de una sola app bloquean el INP de toda la página, y las herramientas estándar no atribuyen ninguna.
- Múltiples render paths: SSR para las rutas de SEO, SSG para las páginas estáticas, CSR para el área de cuenta, renderizado en el edge para la personalización. Los Web Vitals se miden de forma distinta según el render path, y los valores extremos desaparecen en la media del dashboard.
El resultado: el p75 de LCP en Search Console parece aceptable, mientras que el 8% de tus sesiones móviles sufre una cola de soft navigation de 6 segundos que mata la intención de compra. Los Web Vitals estándar no te lo van a mostrar. Necesitas una capa por encima.
Las 5 señales de telemetría más allá de los Core Web Vitals
A partir de nuestros datos de campo en storefronts composable que funcionan sobre Next.js, Nuxt y Astro, cinco señales aparecen de forma constante como las que LCP, INP y CLS no cubren:
1. Spans de long tasks con atribución por app. Cuál de las apps integradas disparó la long task, no solo que se produjo. Sin atribución sabes que hay un problema de rendimiento, pero no qué surface lo causó.
2. Cola de hidratación por ruta. El tiempo entre el First Contentful Paint y la interactividad completa, medido por ruta y por render path. Las rutas SSR con hidratación de cliente pesada muestran aquí segundos que quedan invisibles en las puntuaciones móviles de Lighthouse.
3. INP en soft navigation. El INP en las navegaciones con routing de cliente, no solo en las cargas iniciales. En storefronts de estilo SPA con routing de cliente (habitual en áreas de cuenta, filtros y ordenación), las peores latencias se esconden en las soft navigations. Mira nuestro stress test de INP 2026 para ver lo rápido que se desmorona el umbral de 200 ms en los setups composable.
4. Histograma de roundtrips de API por backend. Las latencias p50, p75, p95 y p99 por cada origen de backend invocado, agrupadas por ruta. Así distingues si el eslabón lento de la página es tu backend de commerce, tu servicio de búsqueda o el origen de tu CMS.
5. Tasa de errores del storefront por surface. Excepciones de JavaScript, fetches fallidos y rechazos de promesas no gestionados, atribuidos a la app en la que se producen. Un motor de recomendación que falla en silencio en el 4% de las sesiones cuesta conversión sin que aparezca ni un solo aviso de error.
Estas cinco señales no tienen nada de exótico. Son la extensión directa de la especificación Web Vitals a los frontends multi-app y son la única base de datos que te permite encontrar regresiones de rendimiento en tiendas composable en horas en lugar de semanas.
Cómo lo hemos resuelto dentro de la Laioutr FMP
En Laioutr el rendimiento no es una tarea de sprint de fin de trimestre, es una propiedad de la plataforma. La Frontend Management Platform incorpora una capa dedicada de beacon pipeline que emite eventos de telemetría desde cada storefront renderizado en la FMP, sin que los equipos de cliente tengan que cablear sus propios scripts de RUM.
La arquitectura, en prosa: un colector de beacons ligero se ejecuta como edge worker junto al storefront, acepta eventos de PerformanceObserver y marcadores personalizados, deduplica por ID de sesión, muestrea a una tasa configurable y envía lotes a un servicio de agregación. De ahí salen dashboards por storefront con atribución por app, colas de INP en soft navigation e histogramas de roundtrips de API.
Esta es la traducción operativa de nuestra promesa de agentic frontend management: un Performance Monitoring Agent vigila los flujos de beacons de forma continua, detecta regresiones de LCP por surface y dispara alertas o rollbacks automáticos antes de que tu ingeniero de guardia reciba un DM por Slack. Calidad de frontend por defecto significa que la telemetría es lo predeterminado, no un add-on.
Lo que ganas
Métrica | Sin telemetría de frontend | Con RUM composable en la FMP |
|---|---|---|
Tiempo para detectar una regresión | de 2 a 7 días (detectada por una caída de ventas) | de 5 a 30 minutos (alerta en el p95 de una surface) |
Tiempo medio hasta la causa | de 4 a 12 horas de análisis forense | Visible directamente desde la atribución por app |
Mejora de conversión móvil al corregir el INP | no medible | de 4 a 9% en casos de cliente documentados |
Cobertura en todas las apps | solo la app del header en Sentry | 100% de las surfaces renderizadas |
Visibilidad de la cola de soft navigation | 0% | Histograma por ruta |
Para la parte arquitectónica, es decir, cómo razonar sobre los Core Web Vitals en setups headless, lee nuestro análisis a fondo sobre los Core Web Vitals en el commerce headless.
FAQ
¿Cuándo basta con Lighthouse? Lighthouse basta como gate de CI y para las comprobaciones de regresión previas al despliegue contra rutas de prueba fijas. En el momento en que añades personalización, soft navigations, composición multi-app o varios render paths, también necesitas RUM. Regla general: Lighthouse para «¿es seguro publicar esto?» y RUM para «¿qué está pasando en producción ahora mismo?».
¿Qué campos de los Web Vitals faltan para composable? Los tres Core Web Vitals (LCP, INP, CLS) cubren bien las cargas iniciales, pero no tienen ningún concepto de apps dentro de una página, ni de soft navigations, ni de latencia de API por origen. También necesitas atribución de long tasks, INP en soft navigation, cola de hidratación por ruta e histogramas de roundtrips de API.
¿Dónde se esconden los valores extremos de INP? En los storefronts composable, los peores valores de INP están casi siempre en (1) las interacciones de filtrado en los listados de producto, (2) el añadir al carrito en apps de recomendación integradas y (3) la primera soft navigation después de la hidratación. La Web Vitals API entrega atribución por evento. Más en nuestro stress test de INP 2026.
¿Integración con nuestra FMP? Si tu storefront funciona sobre la Laioutr FMP, el beacon pipeline está activo por defecto. Ninguna librería de RUM adicional que incrustar, ninguna infraestructura de agregación que operar. Los dashboards están disponibles en el Cockpit y la atribución por app se establece automáticamente mediante las identidades defineSection y defineBlock correspondientes.
¿Cumplimiento en materia de privacidad? El beacon pipeline cumple con el RGPD y está alojado en la UE. No se recogen datos personales, no se conservan direcciones IP y no se usa fingerprinting. Los ID de sesión son tokens aleatorios de vida corta que se borran a las 24 horas. El Consent Mode v2 está soportado de forma nativa y los beacons se apagan automáticamente cuando se rechaza el consentimiento de rendimiento.
Próximos pasos
La telemetría de frontend no es una capa opcional para los storefronts composable en 2026, es instrumentación obligatoria. Si estás averiguando dónde está tu brecha de RUM actual, o quieres tu stack composable en una plataforma que trae la telemetría de serie: Descubre cómo la Laioutr FMP ofrece telemetría de frontend por defecto.
Referencias externas: