Vídeo, WebGL o CSS: qué usar de fondo en un hero
Cada uno falla de una forma distinta. Cómo elegimos entre ellos en 64 webs y qué medimos antes de publicar.
En resumen
Usa vídeo de fondo en un hero cuando la imagen sea la idea, WebGL cuando lo que hace quien visita deba cambiar lo que ve, y CSS para tipografía, interfaz y degradados sencillos. La compatibilidad no decide, porque el vídeo H.264 llega al 97,49 % de los navegadores y WebGL 2 al 97,13 %, según Can I use. El peso los separa más. Nuestros bucles de escritorio tienen una mediana de 2,91 MB, three.js añade unos 194 KB con gzip y CSS casi nada. Si la imagen debe parecer fotográfica, empieza por el vídeo.
- Elige vídeo para escenas fotográficas, con una mediana de 2,91 MB en escritorio.
- Elige WebGL para la interacción, y cuenta con unos 194 KB con gzip si usas three.js.
- Elige CSS para texto e interfaz, donde casi no añade descarga.
- Renderiza WebGL bajo demanda, con lo que medimos 0 draw calls en reposo.
- Publica primero una imagen estática, porque una GPU por software solo llega a 10-15 fotogramas por segundo.
La comparativa de un vistazo
Elige según lo que deba hacer el hero: el vídeo muestra, WebGL responde y CSS lleva el texto y la interfaz. La compatibilidad está casi igualada entre vídeo y WebGL, según Can I use (se abre en una pestaña nueva), así que la elección depende del peso, el aspecto y qué falla antes.
| CSS y SVG | Vídeo en bucle | WebGL | |
|---|---|---|---|
| Ideal para | Tipografía, interfaz, degradados, formas simples | Escenas fotográficas | Escenas que responden al puntero, al scroll o a datos |
| Descarga | Casi nada | Escritorio de 1,09 a 4,84 MB, móvil de 0,45 a 3,74 MB | Nuestros módulos de 2,3 a 126 KB, three.js 194 KB, más modelos y texturas |
| Compatibilidad | Universal en lo básico | 97,49 % (H.264) | 97,13 % (WebGL 2) |
| Responde a la interacción | En parte | Solo controlándolo con el scroll | Por completo |
| Móvil | El mejor de los tres | Bien, con un recorte vertical | Necesita un modo ligero y una alternativa |
| Qué falla antes | Capas grandes con fusión | Varios reproduciéndose a la vez | Render por software y memoria de GPU |
| Alternativa | No hace falta | Póster | Imagen estática |
| Uso en nuestras 64 webs | Las 64 | 30 | 53 |
Pesos medidos en nuestros archivos el 4 de noviembre de 2026, con el código en gzip nivel 9. Compatibilidad según Can I use en la misma fecha. Los recuentos abarcan toda la web, de modo que una web puede usar una tecnología fuera del hero.
Usa vídeo cuando la imagen sea la idea
Si lo primero que debe sentir quien visita la página viene de la propia imagen, usa vídeo. La luz sobre materiales reales, el clima, la piel y el paisaje son lo más difícil de conseguir en tiempo real, y un buen bucle los tiene desde el primer fotograma. Las escenas procedurales rápidas suelen verse baratas al lado de la fotografía, y hemos descartado varias por ese motivo.
El peso es el primer riesgo. Nuestro bucle mediano para móvil, de 1,35 MB, añade más de la mitad de una página de inicio móvil mediana, que pesaba 2362 KB en julio de 2025 según el Web Almanac (se abre en una pestaña nueva). El segundo riesgo es reproducir demasiado a la vez. En una pantalla 2×, las previsualizaciones automáticas de nuestro catálogo bajaron el scroll de 60 a unos 30 fotogramas por segundo, y volvió a 60 al desactivarlas. Lee nuestra guía para hacer un vídeo de fondo en bucle antes de codificar.
Usa WebGL cuando la interacción cambie lo que se ve
WebGL compensa su coste cuando el puntero, el scroll o datos en vivo cambian la imagen. Un campo de partículas que se curva alrededor del cursor, o un vidrio que responde a quien visita, no se puede grabar de antemano. Si nada responde, un vídeo grabado suele verse mejor con menos trabajo. 53 de nuestras 64 webs usan WebGL en algún punto, y estas reglas contienen el coste:
- Renderiza bajo demanda. Si nada se mueve, la página no trabaja. Medimos 0 draw calls en reposo y 16,7 ms por fotograma al animar, en una GPU física.
- Limita la densidad de píxeles a 2. Los fotogramas sostenidos de más de 25 ms pueden bajarla más, hasta 0,75, sin cambiar el diseño.
- Pausa el canvas fuera de pantalla. Nadie lo necesita en marcha detrás del pie.
- Detecta antes el render por software. SwiftShader y llvmpipe tardan segundos en crear un contexto y funcionan a 10-15 fotogramas por segundo. Lee
WEBGL_debug_renderer_info(se abre en una pestaña nueva) y pasa directamente a la imagen estática. - Prueba en una GPU física. Los navegadores sin interfaz suelen renderizar por software, lo que dice poco de cómo irá la página para las visitas.
Un <canvas> no está en la lista de elementos de Largest Contentful Paint de web.dev (se abre en una pestaña nueva), así que la métrica suele medir tu título o tu imagen estática. No te avisará de un motor lento, de modo que hay que medirlo aparte.
Para comparar las técnicas en movimiento, mira nuestros ejemplos de sección hero.
Usa CSS para tipografía, interfaz y degradados sencillos
CSS casi no añade descarga ni tiene un motor que pueda fallar, así que deja que haga todo lo que pueda. Las apariciones de texto, los paneles, los hovers, los degradados y las líneas dibujadas rara vez necesitan más. web.dev recomienda (se abre en una pestaña nueva) animar transform y opacity, que los navegadores pueden gestionar sin recalcular el diseño ni repintar.
Su límite es la memoria de GPU. En una plantilla parpadeaban baldosas negras por la página, con los bordes en múltiplos del tamaño de la baldosa. Parecía un error de maquetación, y la causa eran tres capas: un grano al 200 % de la pantalla, una máscara a pantalla completa con modo de fusión y capas ocultas que seguían en el árbol. Quitarlas lo arregló. Reunimos más casos así en nueve errores que rompen las webs animadas.
Combínalos cuando un trabajo necesite dos herramientas
La mejor respuesta suele ser una mezcla, con vídeo para la imagen, WebGL para el momento de interacción y CSS para la interfaz. 21 de nuestras 64 webs usan vídeo y WebGL. En APSIS rechazamos 4 formas de cambiar entre ediciones: un portal con shader sobre una foto, transiciones de vídeo generadas, una foto en vivo con partículas y un mundo completo de partículas. La versión aceptada mantuvo los fotogramas generados como bucles de 5 segundos e hizo solo el cambio en WebGL, en 0,62 segundos.
Mantén el texto en HTML elijas lo que elijas, para que se pueda leer, traducir e indexar. Si lo vas a escribir en un prompt, indica qué tecnología se encarga de cada trabajo, como explicamos en cómo escribir un prompt para crear una web.
Veredicto. Empieza por el vídeo cuando la imagen lleve la idea, añade WebGL solo para lo que deba responder a la visita y deja el resto a CSS. Ese orden conserva la calidad fotográfica, limita el motor al momento que lo necesita (0,62 segundos en APSIS) y deja el texto en HTML. Publica primero una imagen estática y mide en un dispositivo físico.
Preguntas
Respuestas cortas a lo que suele venir después.
¿WebGL perjudica el SEO?
No, siempre que el texto siga en el HTML. Los buscadores leen tus títulos y textos, y un canvas no contiene ninguno de los dos. El coste que hay que vigilar es la velocidad, así que carga el motor cuando la página ya se haya pintado y muestra antes una imagen estática. Un canvas no está en la lista de elementos de Largest Contentful Paint de web.dev, de modo que se mide el título o la imagen.
¿WebGL funciona en todos los navegadores, o es mejor WebGPU?
WebGL 2 tiene compatibilidad total en el 97,13 % de los navegadores según Can I use en noviembre de 2026, y una imagen estática cubre el resto. WebGPU tiene compatibilidad total en el 85,8 % y parcial en otro 3,66 %, así que aún necesita su propia alternativa. Ninguno de nuestros 64 prompts usa WebGPU todavía.
¿Puedo controlar un vídeo con el scroll?
Sí, pero necesita otra codificación, con fotogramas clave muy frecuentes y sin fotogramas B, para llegar rápido a cualquier punto. Con un grupo de 8 fotogramas, nuestros clips quedaron en 11 a 18 MB cada uno, más un recorte vertical de 5 a 6 MB para móvil. Son unas 4 a 6 veces un bucle normal, así que resérvalo para la película principal.
¿El vídeo siempre pesa más que WebGL?
No. Nuestros módulos de motor ocupan de 2,3 a 126 KB con gzip, y three.js añade unos 194 KB, así que un shader sin texturas queda muy por debajo de un bucle de 2,91 MB. Una escena con modelos y texturas puede superarlo con facilidad. Mide los dos en tu propia página, porque los recursos deciden más que la técnica.
¿Puedo usar vídeo y WebGL en la misma página?
Sí, y a menudo da el mejor resultado. De nuestras 64 webs, 21 usan los dos y solo 2 no usan ninguno. Da a cada uno su propio trabajo, como el vídeo para la imagen y WebGL para el momento de interacción, y no dejes que dos motores animen la misma propiedad del mismo elemento.
¿Qué alternativa debe tener un fondo de hero?
Una imagen estática, en los tres casos. La servimos cuando se prefiere movimiento reducido, algo que el 97,22 % de los navegadores puede indicar, y cuando un dispositivo informa de menos de 4 GB de memoria, menos de 4 núcleos o ahorro de datos. También la servimos si WebGL pasa a renderizar por software, demasiado lento para una escena en movimiento.
Olvídate de la página en blanco
Empieza desde una web terminada.
Cada plantilla es un prompt probado con su código, sus recursos y su movimiento.Sigue leyendo
Todos los artículos
Cómo escribir un prompt para crear una web completa
Las seis partes que necesita un prompt para crear una web completa, medidas en 62 prompts de nuestro catálogo.
Cómo hacer un vídeo de fondo en bucle sin corte para una web
Cinco pasos para un bucle de hero sin corte visible, desde el prompt de generación hasta la etiqueta de vídeo final.