Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
Core Web Vitals en el Storefront: Entrega de Contenido Multimedia y LCP
En la mayoría de los storefronts, el Largest Contentful Paint no es un problema de JavaScript. Es una imagen hero, una foto de producto o un fotograma poster de un video que tarda demasiado en llegar. Arregla el pipeline de contenido multimedia y la puntuación de los Core Web Vitals normalmente mejora en consecuencia.
Cómo se mide realmente el LCP
Largest Contentful Paint mide el tiempo de renderizado del elemento visible más grande en el viewport durante la carga de la página, normalmente una imagen hero, una foto de producto sobre el pliegue, un poster de video o, en diseños con mucho texto, un bloque de texto grande. Google lo puntúa en tres bandas: menos de 2,5 segundos es bueno, de 2,5 a 4 segundos necesita mejora, y más de 4 segundos es deficiente. Estos umbrales se aplican a los datos de campo del Chrome User Experience Report (CrUX), que es lo que realmente afecta al posicionamiento en buscadores, no los números de laboratorio que ves en una prueba local de Lighthouse.
La distinción importa porque los datos de laboratorio se ejecutan sobre una conexión y un perfil de dispositivo fijos. Los datos de campo reflejan a clientes reales en conexiones reales, incluido el móvil con 3G en un túnel de tren y el dispositivo Android antiguo que tu panel de analítica preferiría no mostrarte. Un storefront que obtiene 95 en Lighthouse puede seguir registrando un LCP de campo de 3,8 segundos una vez que se tiene en cuenta esa variación. En las páginas de categoría y de producto de e-commerce en particular, el elemento LCP es un recurso multimedia en la gran mayoría de los casos, que es exactamente hacia donde va el resto de este artículo.
Por qué la entrega de contenido multimedia domina el presupuesto del LCP
Una vez que aceptas que el elemento LCP en la mayoría de las PDP y PLP es una imagen o un poster de video, el presupuesto del LCP deja de ser una cuestión de framework y pasa a ser una cuestión de entrega. Un árbol de renderizado de Nuxt o Next.js perfectamente optimizado no sirve de nada si la solicitud de la imagen hero empieza tarde, llega en el formato equivocado o queda ralentizada detrás de un script de terceros. Ya hemos expuesto el argumento de ingresos en otro lugar: cómo el rendimiento del frontend impulsa los ingresos repasa el impacto de los Core Web Vitals en la conversión y la tasa de rebote. Lo que ese artículo no hace, y que aquí sí importa, es el mecanismo: la entrega de contenido multimedia es la palanca que realmente mueve la cifra del LCP en un storefront típico.
Cuatro patrones de fallo explican la mayor parte del daño: archivos de origen sobredimensionados servidos sin variantes responsive, un formato incorrecto (JPEG cuando AVIF o WebP reducirían el peso de 30 a 50 por ciento), un retraso de descubrimiento en el que el navegador no encuentra pronto la URL de la imagen porque está enterrada en JavaScript del lado del cliente en lugar de en el HTML inicial, y la latencia de una CDN de terceros o no gestionada que añade cientos de milisegundos antes de que siquiera empiece a descargarse el primer byte de la imagen. Ninguno de estos es un problema de framework. Todos son problemas de pipeline multimedia.
El pipeline de imágenes: formatos, tamaños responsive y entrega por CDN
Un pipeline multimedia diseñado para el LCP tiene que acertar en cuatro cosas a la vez: formato, dimensionamiento responsive, capacidad de descubrimiento y caché.
La selección de formato debería usar AVIF por defecto, con WebP como alternativa y JPEG solo como último recurso para casos extremos. El dimensionamiento responsive significa generar un `srcset` real con varios anchos y un atributo `sizes` correcto, para que un móvil descargue una imagen de 640px y no el mismo master de 2400px que recibe el escritorio. La capacidad de descubrimiento significa que la etiqueta de la imagen LCP debe estar presente en el HTML renderizado en el servidor desde el inicio, marcada con `fetchpriority="high"`, y nunca envuelta en `loading="lazy"` (un error que todavía vemos en storefronts en producción, y que por sí solo añade un segundo entero o más al LCP). La caché significa que los bytes reales deberían proceder de una image CDN con caché en el edge, no de una solicitud en frío al origen en cada petición.
Si quieres profundizar en cómo funciona realmente una image CDN, incluida la transformación al vuelo y la caché en el edge, lo tratamos en detalle por separado: cómo funciona realmente una image CDN. La versión corta para este artículo: una image CDN situada entre tu storefront y el origen de tus recursos es lo que hace posible la negociación de formato, el redimensionamiento responsive y la entrega en el edge sin un pipeline de recursos en tiempo de build por cada tamaño de dispositivo.
Errores de entrega de video que rompen el LCP
Las secciones hero con video son habituales en páginas de categoría y páginas de campaña, e introducen una segunda superficie de fallo. Si un video en autoplay está sobre el pliegue, el fotograma poster, no el archivo de video, suele convertirse en el elemento LCP, así que se aplican las mismas reglas al poster: formato correcto, tamaño correcto, prioridad de descarga alta. El error es tratar el poster como algo secundario mientras se sobreingenieriza el propio video.
El archivo de video tiene sus propios patrones de fallo: un único MP4 de alto bitrate sin escalera de bitrate adaptativo, una librería de reproductor de video que bloquea el hilo principal antes incluso de empezar a solicitar datos, y video autoalojado sin una CDN delante, que convierte cada visita al storefront en una nueva solicitud al origen. El video bajo el pliegue debería cargarse en diferido sin excepción. El video sobre el pliegue necesita streaming de bitrate adaptativo y una capa de CDN, o no debería reproducirse en automático en conexiones móviles, donde los límites de datos y el ancho de banda variable convierten un archivo de video grande y no gestionado en una de las cosas más costosas que se pueden poner en una página.
Una capa de rendimiento, no un caos de etiquetas del lado del cliente
El patrón de fallo habitual no es falta de esfuerzo. Es una pila de parches del lado del cliente: una librería de carga diferida, un plugin independiente de optimización de imágenes, un video incrustado de terceros y un script de personalización, cada uno cargado de forma independiente, cada uno compitiendo por el mismo hilo principal y la misma prioridad de red, ninguno consciente de la existencia de los demás. Cada una de estas herramientas se eligió para resolver un problema real, y juntas crean uno nuevo: un LCP descoordinado e impredecible.
La alternativa es tratar el rendimiento como una capa de plataforma en lugar de una acumulación de herramientas del lado del cliente. En Composable Headless Frontend, la entrega de contenido multimedia, la generación de imágenes responsive y la caché en el edge están integradas directamente en la propia capa de renderizado y hospedaje, no añadidas después en cada proyecto. Esa es también la premisa detrás de Frontend as a Service: el storefront, la capa de conexión y la capa de entrega en la nube funcionan como un único sistema gestionado, de modo que un presupuesto de rendimiento definido una vez se aplica a todas las páginas y todos los locales, en lugar de tener que volver a defenderlo cada vez que se añade un nuevo script de marketing seis meses después.
FAQ
¿Comprimir imágenes por sí solo arregla el LCP? No. La compresión reduce el tamaño del archivo pero no corrige un formato equivocado, variantes responsive ausentes o una ruta de descubrimiento retrasada. Los cuatro factores (formato, tamaño, prioridad, caché) tienen que estar bien resueltos a la vez.
¿Qué puntuación de LCP debería tener como objetivo un storefront de e-commerce? Apunta a datos de campo por debajo de 2,5 segundos como mínimo, y considera 1,8 segundos como objetivo realista en móvil. Los propios frontends en producción de Laioutr registran un LCP mediano de 1,2 segundos en datos de campo, lo que muestra lo que puede lograr una capa de contenido multimedia y hospedaje bien gestionada.
¿Puede un video ser el elemento LCP alguna vez, y debería serlo? Sí, si el fotograma poster es el elemento visible más grande antes de que cargue el video. Trata ese poster exactamente igual que una imagen hero: formato correcto, tamaño correcto, prioridad de descarga alta, y nunca en carga diferida.
Próximos pasos
Si el LCP de tu storefront es inconsistente entre dispositivos y mercados, la forma más rápida de averiguar si es un problema de framework o de entrega de contenido multimedia es una revisión técnica de tu pipeline actual. Consulta los precios de la plataforma o habla con nosotros sobre lo que cambiaría una capa de rendimiento gestionada en tu storefront concreto.