WebGL o animaciones CSS: cuándo usar cada una (2026)

La elección entre WebGL y una animación CSS se reduce a una pregunta: ¿el efecto necesita la GPU como motor de render de propósito general, o solo como compositor? Una animación CSS le pasa dos o tres propiedades al navegador y consigue 60fps casi gratis. Con WebGL coges la GPU en bruto y un lienzo vacío, y luego construyes tú la geometría, la iluminación y el bucle de render. La mayoría de las interfaces de producto nunca necesitan la segunda vía.

Esta decisión aparece en cada web de marketing y en cada panel con movimiento. Si te inclinas demasiado hacia WebGL, envías un bundle de 600KB y gastas batería por un fundido que el CSS hace en cuatro líneas. Si te inclinas demasiado hacia el CSS, pasas tres semanas peleando con el compositor para fingir un campo de partículas que WebGL dibuja sin esfuerzo. Así trazamos la línea.

La respuesta en 30 segundos: quién elige qué

Usa una animación CSS cuando el efecto mueve elementos del DOM que ya existen: fundidos, deslizamientos, escala al pasar el ratón, un spinner de carga, un menú que se abre, una tarjeta que se eleva. Si puedes expresar el movimiento como un cambio en transform y opacity, el CSS es la herramienta correcta y cualquier cosa más pesada sobra.

Usa WebGL cuando el efecto es el contenido, no un adorno encima del contenido: un configurador 3D de producto, un sistema de partículas con miles de puntos, un efecto de fluido o un shader, una visualización que anima 10.000 nodos, una escena alrededor de la que el usuario orbita. El DOM no puede representar estas cosas, así que la pregunta de si el CSS podría hacerlo ni siquiera surge.

Los casos interesantes están en medio. Ahí es donde la comparación sirve de verdad.

WebGL y animaciones CSS de un vistazo

Dónde gana la animación CSS

En la GPU es gratis si te quedas en transform y opacity

El navegador acelera por hardware cualquier transición o keyframe sobre transform y opacity, porque esas dos propiedades no disparan ni layout ni repaint. Corren en el hilo del compositor, así que la animación sigue fluida incluso mientras tu JavaScript está ocupado. El equipo de render de Chrome lo documenta sin rodeos: una animación compuesta se salta el hilo principal por completo. MDN da la misma indicación para todo lo que es mayormente estático y se anima poco.

Degrada con seguridad

Una animación CSS que el dispositivo no puede seguir simplemente no se mueve. Sin fallo, sin lienzo en blanco, sin código de fallback que escribir. La envuelves en @media (prefers-reduced-motion: reduce) y respeta el ajuste de accesibilidad del usuario en tres líneas, sin una sola línea de JavaScript. Es un ahorro real en accesibilidad y mantenimiento.

Su modo de fallar es fácil de ver

La animación CSS se tuerce cuando animas las propiedades caras: width, height, top, left, margin. Cada una obliga al navegador a recalcular el layout en cada frame, y la tasa de frames se cae. La solución casi siempre es reescribir el efecto con transform. Y no tapes el tirón poniendo will-change en todo: cada elemento promovido se vuelve una textura en la memoria de la GPU, y el abuso crea una presión de memoria que expulsa texturas y provoca tirones durante interacciones sin relación. CSS-Tricks trata will-change como último recurso, acotado al momento justo antes de la animación y retirado después. Nosotros hacemos lo mismo.

Dónde gana WebGL

Volúmenes que el DOM no aguanta

Anima 5.000 nodos del DOM y el navegador se derrumba. Un benchmark cross-device de sistemas de animación web de 2025 encontró que WebGL mantenía las tasas de frames más estables entre 5.000 y 10.000 objetos, donde el DOM y el SVG se hunden mucho antes. Una GPU moderna dibuja decenas de miles de polígonos a 60fps. Si tu efecto es un enjambre, un campo o una malla, WebGL no es la opción pesada: es la única que funciona.

Efectos que solo existen en shaders

Simulación de fluidos, displacement, iluminación por píxel, profundidad de campo, ruido procedural: viven en los fragment shaders y no tienen equivalente en CSS. No los aproximas con transform y opacity, por muchos keyframes que apiles. Cuando el diseño pide uno de estos, la decisión ya está tomada.

El coste que aceptas

WebGL no es gratis. Three.js añade unos 150KB antes de dibujar un solo triángulo; usar el WebGLRenderer en bruto en vez de la librería completa recorta ese peso de forma notable. En móvil el impuesto real es el calor: las GPU se frenan por throttling térmico bajo carga sostenida, así que una escena que corre a 60fps los primeros segundos puede caer a 20fps tras 30. Muchas experiencias 3D en móvil limitan a 30fps a propósito para ahorrar batería, como señala la hoja de ruta de Three.js sobre el consumo en móvil. Presupuesta una ruta reduced-motion y una imagen estática de reserva para los dispositivos que no deberían ejecutar esa escena.

El punto medio que todos olvidan: Canvas 2D y SVG

WebGL y CSS son los dos extremos. Entre ellos hay dos herramientas, y saltárselas es el error más común que vemos. Canvas 2D maneja cientos de partículas o un patrón generativo sin tocar 3D ni shaders. SVG anima unas decenas de formas vectoriales con escalado nítido y acceso completo al DOM, así que puedes estilar e inspeccionar cada nodo. Cuando el efecto es más de lo que el CSS puede cargar pero menos que una escena 3D, la respuesta suele ser una de estas dos, y pesa menos que meter un render de WebGL. Explicamos dónde encaja cada librería en nuestro repaso del stack web inmersivo.

Qué usamos, y por qué

En un proyecto SaaS típico, cerca del 95% del movimiento es CSS: transform y opacity, guiados por el estado, respetando prefers-reduced-motion. Para el movimiento ligado al scroll elegimos una librería ligera en vez de un lienzo. Añadimos WebGL solo cuando la escena 3D o el shader son aquello por lo que vino el usuario, y cada vez lo enviamos detrás de una comprobación de reduced-motion y un fallback estático. La regla que mantenemos: el recurso más pesado que carga una página debe responder a algo que el visitante quería, no a un adorno de fondo. Si basta un fundido, gana el fundido. Si el producto es la escena 3D, pagamos el impuesto de WebGL a propósito y lo mantenemos fuera del hilo principal y fuera de la ruta crítica. Para el lado de métricas de este intercambio, mira nuestra guía para llevar los Core Web Vitals a verde en Next.js.