WebGPU en 2026: cuándo vale la pena reescribir tu app 3D web (y cuándo WebGL sigue bastando)
WebGPU ya está en todos los navegadores principales. Como era previsible, la pregunta llegó a nuestra bandeja de entrada en una semana: "¿deberíamos pasar nuestro visor 3D a WebGPU?" Normalmente la respuesta es "todavía no, y aquí está la prueba." Una nueva API gráfica no es motivo para reescribir un producto que funciona.
Entregamos 3D en tiempo real en el navegador — configuradores, visitas virtuales, visualizaciones médicas — en Three.js y WebGL puro. Este es el árbol de decisión honesto que usamos en 2026.
Lo que WebGPU realmente aporta
- Compute shaders. El verdadero titular. Computación en la GPU dentro del navegador sin trucos — sistemas de partículas, física, simulación, inferencia de ML. WebGL nunca tuvo esto.
- Menos sobrecarga de CPU por draw call. WebGPU está diseñado en torno a las GPU modernas. Las escenas con miles de objetos distintos dejan de estar limitadas por la CPU.
- Mejor multithreading y estado de pipeline explícito. Predecible, explícito, menos adivinanza del driver.
Lo que no aporta
- Una imagen más bonita gratis. Un único producto en un plato giratorio se ve igual. WebGPU no es una mejora de calidad; es una mejora de throughput y de cómputo.
- Menos trabajo. La API es de más bajo nivel — más configuración, más cuerda para ahorcarte. Si estás en Three.js, el renderer abstrae la mayor parte de esto, que es precisamente el objetivo.
- Soporte universal en hardware antiguo. Es amplio ahora, pero todavía necesitas una ruta de fallback para dispositivos viejos y máquinas corporativas bloqueadas.
La prueba que aplicamos antes de reescribir
- ¿Estás limitado por la CPU en las draw calls? Haz profiling primero. Si tu cuello de botella es la memoria de texturas o el fill rate, WebGPU no te salva.
- ¿Necesitas cómputo en la GPU? Simulación de multitudes, tela, fluidos, grandes cantidades de partículas, ML en el navegador. Si es así, WebGPU es el único camino sensato.
- ¿La escena es genuinamente pesada? Miles de mallas únicas, instancing a escala. Un único coche de configurador no es pesado.
Si respondiste no a las tres, tu build en WebGL está bien. Ya hemos defendido que la mayoría de los sitios no necesita la herramienta pesada; la misma contención se aplica a las API gráficas.
El camino pragmático: WebGPURenderer de Three.js
Casi nunca se escribe WebGPU en crudo a mano para trabajo de producto. Three.js incluye un renderer WebGPU que hace fallback automático a WebGL. Escribes una vez, obtienes cómputo cuando el dispositivo lo soporta, y mantienes una imagen funcional en todo lo demás. Esa es la migración que realmente recomendamos: cambiar el renderer, no todo el código, y solo cuando el profiler lo diga.
Dónde importa para nosotros
Nuestras escenas de navegador más pesadas son entregables de captura 3D — nubes de puntos y splats con millones de puntos. Esa es exactamente la carga donde la ruta de cómputo de WebGPU se gana su sitio, y por eso nuestro razonamiento sobre Gaussian splatting vs fotogrametría ahora tiene en cuenta el renderer. ¿Para un configurador en plato giratorio? Seguimos en WebGL y sin pedir perdón.
La versión corta
WebGPU es un avance real para 3D intensivo en cómputo y en objetos. No es un mandato para reescribir. Haz profiling, encuentra el cuello de botella, cambia el renderer si el cuello son las draw calls o necesitas cómputo, y mantén un fallback WebGL en cualquier caso.
¿Tienes una app 3D web que se siente lenta y no sabes por qué? Envíanos la escena — le hacemos profiling antes de que nadie diga "reescribir".