Webs inmersivas sin perder velocidad: vídeo, 3D y Core Web Vitals

Una web inmersiva promete algo difícil: que la visita se sienta como entrar en un sitio, no como leer una página. Vídeo, 3D, animación ligada al desplazamiento, partículas… Todo eso tiene un coste, y quien lo paga es el móvil del usuario.

En esta guía contamos cómo construimos la portada de grupobeetle.com, qué salió mal por el camino y qué reglas usamos ahora para que lo espectacular no sea lento. No hay fórmulas mágicas: hay presupuestos, medición y la disposición a tirar una idea bonita cuando no cabe.

Primero, qué mide Google

Los Core Web Vitals son tres indicadores que Google usa para evaluar la experiencia real de carga e interacción. Sus umbrales de «bueno» son públicos:

• LCP (Largest Contentful Paint): el elemento principal de la pantalla debe pintarse en 2,5 segundos o menos.
• CLS (Cumulative Layout Shift): el contenido no debe saltar de sitio mientras carga; el umbral es 0,1.
• INP (Interaction to Next Paint): la página debe responder a toques y clics en 200 milisegundos o menos.

Una web inmersiva pone en riesgo los tres a la vez: archivos pesados retrasan el LCP, los medios sin tamaño reservado provocan saltos y el JavaScript de las animaciones bloquea la respuesta a la interacción.

Fija el presupuesto antes de diseñar

La decisión más útil del proyecto se tomó antes de dibujar nada: escribir los presupuestos de rendimiento y hacer que bloqueen la publicación.

• LCP menor de 2,5 s en móvil.
• CLS menor de 0,1.
• Menos de 150 KB de JavaScript inicial comprimido con gzip; todo lo 3D, en diferido.
• Modelos 3D (GLB) por debajo de 2 MB, comprimidos con Draco o Meshopt, y texturas en KTX2 o WebP.
• Densidad de píxeles del lienzo limitada a 1,5 y posprocesado solo en escritorio.
• Imagen de respaldo para navegadores sin WebGL, móviles lentos y usuarios con prefers-reduced-motion.

Un presupuesto escrito cambia las conversaciones. Ya no se discute si un efecto «merece la pena» en abstracto: se discute si cabe.

Caso real: de secuencias de fotogramas a vídeo

La portada de grupobeetle.com tiene un capítulo por marca. En el de Beetle Wood, por ejemplo, una mesita de noche abre su compartimento oculto; en el de Beetle Lab, un vinilo se apoya en el plato.

La primera versión: un mundo WebGL

Empezamos con una escena 3D completa con three.js. Era vistosa, pero dependía de la potencia gráfica de cada dispositivo y obligaba a cargar mucho código antes de mostrar nada. La aparcamos sin borrarla: la tecnología no era el problema, el encaje sí.

La segunda versión: secuencias de imágenes

La técnica de moda en webs de producto es la secuencia de fotogramas: se corta un vídeo en decenas de imágenes y se dibujan en un lienzo según el desplazamiento. Da un control absoluto y se ve muy fluida en escritorio.

En nuestro caso, cada capítulo usaba entre 81 y 121 imágenes WebP de 1600 × 904 píxeles. En disco, las secuencias sumaban unos 24 MB. El problema real no era la descarga sino la memoria: una imagen se comprime para viajar, pero para dibujarse se descomprime. 1600 × 904 píxeles × 4 bytes por píxel son unos 5,8 MB de memoria por fotograma. Con cientos de fotogramas, el navegador del móvil hacía lo único que puede hacer cuando se queda sin memoria: cerrar la pestaña. Para el usuario, la web «le echaba».

La versión actual: vídeo ligero

La solución fue volver a lo más sencillo: un vídeo por capítulo. Lo que importa es cómo se prepara y cómo se reproduce:

• Codificación pensada para la web: H.264, sin audio, con los metadatos al principio del archivo (+faststart) para que empiece a reproducirse antes de descargarse entero, y un fotograma clave frecuente para que los reinicios sean instantáneos.
• Dos tamaños: 1280 × 720 en escritorio y un recorte de 720 píxeles de ancho para móvil, encuadrado para que el producto no quede cortado.
• Archivos pequeños: ninguno de los vídeos de la portada supera 1,4 MB, y en móvil el conjunto de medios pasó de unos 24 MB de fotogramas a unos 2,4 MB de vídeo.
• Un solo vídeo activo: solo el capítulo visible tiene su fuente cargada. Al salir de pantalla, el vídeo se pausa y libera su fuente.
• Sin precarga: preload="none" y reproducción automática cuando el capítulo está visible al menos a la mitad.
• Planes B: si el usuario pide menos movimiento, activa el ahorro de datos o el navegador rechaza la reproducción, se muestra el póster del estado final y un botón para reproducir.

Resultado: la web dejó de cerrarse en móvil y la portada mantiene la sensación cinematográfica.

LCP: lo primero que se ve, primero

El LCP suele ser la imagen o el titular más grande de la primera pantalla. Tres ajustes nos dieron el margen:

No precargues lo que no está arriba. Teníamos una precarga de 78 KB de una tipografía condensada que solo se usa por debajo del primer pliegue. Competía con lo que sí se ve al entrar. La quitamos y la fuente se carga con font-display: swap cuando hace falta.

No ocultes el elemento principal para animarlo. Una entrada elegante que parte de opacity: 0 puede hacer que el navegador no cuente el elemento como pintado hasta que termina la animación. El párrafo de portada ya no empieza invisible.

Deja lo interactivo para después. El logotipo de partículas de la portada es un módulo aparte de unos 4,6 KB comprimidos que se pide cuando el navegador queda libre tras el primer pintado (requestIdleCallback). Mientras tanto, y si algo falla, se ve el logotipo en SVG. El usuario nunca espera a la animación para ver la marca.

CLS: reserva cada hueco

Los saltos de diseño casi siempre tienen una de estas causas, y todas se evitan reservando espacio:

• Medios sin dimensiones. Cada vídeo y cada imagen tiene su caja con aspect-ratio o width y height. Nuestro verificador rechaza cualquier <img> sin dimensiones.
• Fuentes que cambian de tamaño al llegar. Definimos una fuente de respaldo con las métricas ajustadas a la tipografía final (size-adjust, ascent-override, descent-override), de modo que el texto ocupa lo mismo antes y después.
• Estilos críticos tardíos. Las variables que colocan la cabecera y los márgenes de la portada se definen directamente en el <head>. Antes dependían de un selector :has() y un pintado parcial podía perderlas durante un instante, lo suficiente para provocar un salto.

INP: anima sin bloquear

Para que la página responda rápido mientras algo se mueve:

• Usa requestAnimationFrame y detén el bucle cuando no hay nada que animar o el elemento no está en pantalla.
• Prefiere arrays tipados y cálculos sencillos para sistemas de partículas en Canvas 2D.
• Limita la densidad de píxeles del lienzo (DPR máximo 1,5): en móviles de alta densidad la diferencia visual es mínima y el ahorro de trabajo es grande.
• Escucha el puntero con eventos pasivos y aplica los cambios en el siguiente fotograma, no en cada evento.

¿Y el 3D de verdad?

Three.js y React Three Fiber siguen en nuestro stack. Cuando un proyecto necesita una escena 3D real, aplicamos las mismas reglas:

• Carga diferida: la escena se importa cuando el contenedor se acerca a la pantalla, nunca en el JavaScript inicial.
• Modelos comprimidos: geometría con Draco o Meshopt, texturas en KTX2 o WebP, y un tope de 2 MB por modelo.
• Calidad adaptativa: posprocesado solo en escritorio y menos detalle en dispositivos modestos.
• Siempre un respaldo: una imagen fija bien optimizada para quien no tiene WebGL o prefiere menos movimiento.
• Texto en HTML: lo importante para SEO y accesibilidad nunca vive solo dentro del lienzo.

Accesibilidad no es opcional

Una web inmersiva tiene que poder recorrerse sin ver la animación. Lo que aplicamos:

• prefers-reduced-motion respetado en todo: sin reproducción automática, sin desplazamiento suave y sin efectos de entrada.
• Botones reales para abrir, reproducir o repetir, con nombres accesibles y objetivos táctiles de al menos 44 píxeles.
• Vídeos con aria-label descriptivo y pósters con texto alternativo.
• Diálogos con el foco atrapado y cierre con Esc.

Mide en móvil, no en tu portátil

Tu portátil miente. Las pruebas que cuentan son en móvil y con red limitada:

• Lighthouse en modo móvil para cada página importante. En la portada de grupobeetle.com obtenemos 100 en Accesibilidad, Buenas prácticas y SEO.
• Un presupuesto automatizado en cada compilación: nuestro verificador calcula el JavaScript inicial de cada página. La portada carga hoy unos 48 KB comprimidos, muy por debajo del límite de 150 KB.
• Pruebas reales en un móvil de gama media, porque los fallos de memoria como el de las secuencias no aparecen en un simulador de escritorio.

Lista de comprobación

• Presupuestos de rendimiento escritos y conectados a la publicación.
• Un único vídeo activo por pantalla, sin precarga y con póster.
• Fuentes de respaldo con métricas ajustadas y sin precargas innecesarias.
• Todos los medios con dimensiones reservadas.
• Lo interactivo cargado en diferido y con respaldo estático.
• prefers-reduced-motion y ahorro de datos respetados.
• Pruebas en móvil real antes de dar nada por terminado.

Lo inmersivo y lo rápido no están reñidos. Lo que no cabe es improvisar. Si quieres el contexto completo de cómo encaja esto en una estrategia más amplia, lee la guía sobre cómo montar un ecosistema digital para una marca. Y si buscas una web así para tu empresa, en Beetle Studio la diseñamos contigo.