Desarrollo web 3D con Three.js y WebGL en 2026: guía

Three.js sobre WebGL sigue siendo la forma estándar de entregar 3D interactivo en la web en 2026, y ahora apunta a WebGPU desde la misma API cuando el navegador lo soporta. Si estás dimensionando un proyecto de desarrollo web 3D, la biblioteca de renderizado rara vez es la decisión difícil; el pipeline de assets, el presupuesto de rendimiento en móvil y la profundidad de la interactividad son lo que fija el coste y el plazo. Esta guía cubre las elecciones de tecnología, el pipeline, las reglas de rendimiento y qué preguntar a los programadores web Three.js o al proveedor antes de firmar.

WebGL vs WebGPU: dónde están las cosas en 2026

WebGL 2 es el objetivo seguro. Funciona en todos los navegadores actuales, de escritorio y móviles, en GPUs integradas y dentro de webviews. Sus límites son conocidos: una API de máquina de estados heredada de OpenGL ES, sin compute shaders y con un overhead por draw call que depende del driver.

WebGPU es el sucesor moderno. Expone compute shaders, binding explícito de recursos y un coste de CPU menor por draw. Chrome y Edge lo lanzaron primero, Firefox y Safari siguieron, y el soporte ya es amplio en hardware reciente. Lo que todavía no es cierto en 2026 es la disponibilidad universal: dispositivos Android antiguos, algunos webviews embebidos y equipos corporativos con drivers de GPU bloqueados caen a WebGL o a nada. Planifica WebGPU como mejora, no como base, salvo que controles los dispositivos (quioscos, herramientas internas, una flota de tablets).

Three.js gestiona esa división por ti. El WebGPURenderer usa WebGPU cuando está disponible y cae a WebGL 2 automáticamente, y el sistema de materiales basado en nodos (TSL, Three Shading Language) compila tanto a WGSL como a GLSL. En la práctica, escribes la escena una sola vez. La contrapartida es que algunos add-ons antiguos y el código personalizado de ShaderMaterial son solo WebGL, así que una aplicación con muchos shaders personalizados necesitará un plan de migración, no solo un cambio de renderer.

Regla práctica para un proyecto nuevo: construye sobre Three.js con WebGPURenderer, mantén los shaders personalizados en TSL y prueba la ruta de fallback WebGL en un Android de gama media desde el primer día. Si la carga de trabajo necesita compute en GPU (sistemas de partículas con millones de puntos, física, visualización de datos a gran escala), WebGPU deja de ser opcional y tu declaración de soporte de dispositivos se estrecha en consecuencia.

Three.js vs Babylon.js vs PlayCanvas vs React Three Fiber

Estas son las cuatro opciones realistas para una aplicación de negocio. Unity y Unreal exportan a la web, pero sus bundles son grandes y su licenciamiento está pensado para juegos; resérvalos para contenido que ya existe en esos motores.

Criterio	Three.js	Babylon.js	PlayCanvas	React Three Fiber
Qué es	Biblioteca de renderizado	Motor 3D completo	Motor + editor alojado	Renderer React para Three.js
Licencia	MIT	Apache 2.0	MIT (motor); el editor es un servicio de pago	MIT
WebGPU	Sí, con fallback WebGL	Sí, con fallback WebGL	Sí	Hereda de Three.js
Tamaño del bundle (orden de magnitud)	El menor de los cuatro, tree-shakable	Core mayor, paquetes modulares	Motor de tamaño medio	Three.js más una capa fina
Física, GUI y audio integrados	Vía add-ons y terceros	Integrados	Integrados	Vía drei y ecosistema
Editor visual	Ninguno oficial	Inspector y sandbox	Producto principal	Ninguno (Leva, Triplex para props)
Ecosistema y contratación	Mayor bolsa de talento	Grande, respaldado por Microsoft	Menor	Grande entre equipos React
Mejor encaje	Visualización de producto, configuradores, sitios, data viz	Simulaciones, formación, apps tipo juego	Juegos en equipo y apps de contenido	Apps React que necesitan 3D como UI

Three.js gana en flexibilidad y en tamaño de comunidad, algo que importa al contratar. Babylon.js gana cuando quieres un motor que ya incluye física, GUI, grupos de animación y un inspector de depuración, y cuando la aplicación se parece más a un juego o simulador que a una página web. PlayCanvas es la elección cuando personas no desarrolladoras (artistas, diseñadores de niveles) necesitan montar escenas en un editor y publicarlas. React Three Fiber (R3F) no compite con los demás; es la forma en que un equipo React debería consumir Three.js, y se combina con bibliotecas de estado como Zustand igual que ya lo hace el resto de la app (ver gestión de estado en aplicaciones complejas).

Una escena mínima en Three.js

Los conceptos básicos caben en treinta líneas: un renderer ligado a un canvas, un grafo de escena, una cámara, luces, un mesh y un bucle de renderizado. Todo lo demás son loaders, controles y optimización.

import * as THREE from 'three';
import { WebGPURenderer } from 'three/webgpu';
import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
import { OrbitControls } from 'three/addons/controls/OrbitControls.js';

const canvas = document.querySelector('canvas')!;
const renderer = new WebGPURenderer({ canvas, antialias: true });
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
renderer.setSize(canvas.clientWidth, canvas.clientHeight, false);
await renderer.init(); // elige WebGPU o cae a WebGL 2

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(45, canvas.clientWidth / canvas.clientHeight, 0.1, 100);
camera.position.set(2, 1.5, 3);

scene.add(new THREE.HemisphereLight(0xffffff, 0x444444, 1.5));
const sun = new THREE.DirectionalLight(0xffffff, 2);
sun.position.set(5, 10, 5);
scene.add(sun);

const { scene: model } = await new GLTFLoader().loadAsync('/models/product.glb');
scene.add(model);

const controls = new OrbitControls(camera, canvas);
controls.enableDamping = true;

renderer.setAnimationLoop(() => {
  controls.update();
  renderer.render(scene, camera);
});

Un detalle ya pesa en el rendimiento: limitar devicePixelRatio a 2 evita que un móvil 3x renderice nueve veces los píxeles de una pantalla 1x.

Pipeline de assets: glTF, compresión y presupuesto de texturas

La mayoría de los proyectos web 3D que fracasan lo hacen en el pipeline de assets, no en el JavaScript. Exportaciones de CAD con millones de triángulos y texturas 4K en cada pieza no se pueden "optimizar después" desde el equipo de frontend. Decide el pipeline antes de que empiece el modelado.

Formato. glTF 2.0, empaquetado como un único binario .glb, es el único formato de intercambio sensato para la web. Transporta materiales PBR, animaciones, skins y morph targets, y las extensiones Khronos cubren compresión y materiales avanzados (clearcoat, transmission, sheen).

Exportación desde Blender. Blender suele ser el último paso incluso cuando el origen es CAD: importar, limpiar, decimar, hacer bake y exportar a glTF con "Apply Modifiers" y Y-up. Hacer bake de la iluminación y la oclusión ambiental en las texturas en esta fase ahorra trabajo en tiempo de ejecución en todos los dispositivos.

Compresión de geometría. Usa Draco o Meshopt. Draco comprime más, pero necesita un decoder en WebAssembly y un paso de decodificación en la CPU antes de subir a la GPU. Meshopt (vía gltfpack o gltf-transform) decodifica más rápido y también soporta cuantización, que suele ser la mejor opción para móvil. En cualquier caso, espera que la geometría se reduzca a una fracción de su tamaño original.

# Pasada de optimización típica
npx @gltf-transform/cli optimize product.glb product.opt.glb \
  --compress meshopt --texture-compress ktx2 --texture-size 2048

Texturas. Las texturas, no la geometría, suelen ser la mayor descarga y el mayor consumidor de memoria de GPU. Conviértelas a KTX2 con Basis Universal (ETC1S para color, UASTC para normal maps y cualquier cosa con detalle fino) para que la GPU las mantenga comprimidas en memoria; un PNG o JPEG se descomprime a tamaño completo en la GPU y agota un móvil rápidamente. Fija un presupuesto de texturas por escena: recuento total de texels, resolución máxima por material y una regla de atlas para piezas pequeñas.

Validación en CI. Ejecuta el validador glTF de Khronos y una comprobación de tamaño en cada commit de assets. Trata los modelos como código: versionados, revisados y rechazados cuando superan el presupuesto. Sírvelos desde un CDN con cabeceras de caché inmutables, como se explica en estrategias de caché para rendimiento.

Rendimiento: draw calls, instancing, LOD y calor en móvil

Fija un objetivo de frame time y un suelo de dispositivo antes de escribir funcionalidades: 60 fps en un portátil actual y 30 fps estables en un Android de gama media de tres años es una base común y honesta. Luego protégela.

• Draw calls. Cada mesh con su propio material es un draw call; cientos están bien, miles no lo están en WebGL. Fusiona geometría estática, comparte materiales y usa atlas de texturas. WebGPU sube el techo, pero no lo elimina.
• Instancing. Para objetos repetidos (sillas, tornillos, árboles, puntos de datos), InstancedMesh renderiza miles de copias en una sola llamada. Es la mayor ganancia individual en la mayoría de escenas de producto y data viz.
• Level of detail. Usa THREE.LOD o cambios manuales para mostrar meshes más simples a distancia, y carga las partes de alto detalle bajo demanda solo cuando la cámara se acerca. Exporta los niveles de LOD desde Blender en lugar de generarlos en tiempo de ejecución.
• Pixel ratio y escalado de resolución. Renderiza a una resolución interna menor en GPUs débiles y escala hacia arriba. La resolución dinámica ligada al frame time medido es barata de implementar y eficaz.
• Sombras y postprocesado. Sombras en tiempo real, efectos en screen space y antialiasing multisample son lo primero que se desactiva en un preset de calidad "baja". La iluminación con bake se ve mejor que una iluminación en tiempo real barata, de todos modos.
• Límites térmicos en móvil. Un móvil reduce su frecuencia tras uno o dos minutos de carga sostenida en la GPU; una escena que va a 60 fps en los primeros diez segundos y a 20 fps a los tres minutos le falla al usuario. Renderiza bajo demanda (solo cuando cambia la cámara o el estado) en lugar de un bucle continuo para escenas estáticas, y mide sesiones de cinco minutos, no de cinco segundos.
• Memoria. Libera geometrías, materiales y texturas cuando cambia una escena. Vigila renderer.info y los snapshots de heap; las fugas en single-page apps son habituales cuando se intercambian modelos en un configurador.

Instrumenta a usuarios reales: histogramas de frame time, tiempo hasta el primer frame renderizado y eventos de pérdida de contexto. Pertenecen al mismo dashboard que tus Core Web Vitals; un canvas sin carga diferida arrastra consigo LCP e INP.

Dónde compensan las aplicaciones web 3D

El caso de negocio es más fuerte cuando la tercera dimensión aporta información que el 2D no puede, y más débil cuando es decoración.

• Configuradores de producto. Muebles, vehículos, equipamiento industrial, ropa personalizada. El valor está en la entrega: el estado configurado debe mapearse a SKUs, precios y un carrito o CRM. Presupuesta más para la integración que para el renderizado.
• Gemelos digitales. Edificios, plantas, flotas y redes renderizados desde BIM o CAD y superpuestos con datos de sensores en vivo. Son problemas de escena grande: streaming, LOD y tiling.
• Visualización de datos. Nubes de puntos, datos volumétricos, grafos de red con cientos de miles de nodos. Aquí es donde el compute de WebGPU se gana su sitio, y donde el instancing es obligatorio.
• Formación y simulación. Operación de equipos, procedimientos de seguridad, formación médica. A menudo listos para WebXR, a veces con física; el lado Babylon.js de la tabla anterior gana atractivo aquí.
• Tours inmobiliarios y de espacios. Capturas por fotogrametría o Gaussian splatting de espacios, y modelos ligeros de viviendas con cambio de materiales. La disciplina en el tamaño de carga importa más que cualquier otra cosa, porque la audiencia está en el móvil.

Accesibilidad y fallbacks

Un canvas es opaco para las tecnologías de asistencia, así que la versión accesible de la experiencia vive en el DOM que lo rodea. Las reglas prácticas:

• Toda acción disponible arrastrando o haciendo clic en la escena debe existir también como botón, lista o control de formulario. El selector de material de un configurador es un conjunto de radio buttons; la vista 3D es una previsualización de ese estado, no la única forma de fijarlo.
• Anuncia los cambios de estado con una región ARIA live ("Color cambiado a nogal"), da al canvas un nombre accesible y una descripción en texto de lo que muestra, y mantén un orden de foco coherente.
• Respeta prefers-reduced-motion: desactiva la rotación automática, los fly-ins de cámara y el parallax cuando esté activo.
• Ofrece un fallback. Cuando WebGL no esté disponible o se pierda el contexto, muestra imágenes prerrenderizadas de los mismos estados. Los turntables prerrenderizados son también lo que verán los buscadores y las previsualizaciones sociales.
• No bloquees la página. Carga el bundle 3D después del contenido, al interactuar o al hacerse visible, para que los usuarios con redes lentas reciban primero los datos del producto.

Las reglas generales están en nuestra guía WCAG para desarrollo web; el canvas no exime a una página de cumplirlas.

Dimensionar y estimar un proyecto web 3D

Los compradores piden "un visor 3D" y reciben presupuestos que difieren en un orden de magnitud. La diferencia está en los supuestos de abajo; fíjalos por escrito antes de comparar proveedores.

Qué determina el coste

Factor	Extremo bajo	Extremo alto
Pipeline de assets	Ya existen modelos glTF limpios	CAD o escaneos que hay que limpiar, retopologizar, hacer bake y comprimir; decenas de SKUs
Interactividad	Orbitar, zoom, algunos cambios de material	Ensamblajes con restricciones, animaciones, mediciones, anotaciones, física
Presupuesto de rendimiento	Escritorio primero, "funciona en móviles recientes"	30 fps estables en Android de gama media de tres años, uptime de quiosco, pruebas térmicas
Soporte de dispositivos y navegadores	Chrome, Safari, Firefox actuales	Webviews antiguos, navegadores embebidos, visores WebXR, PWA offline
Integraciones	Configuración estática	Precios en vivo, inventario, CRM, generación de PDF/presupuesto, exportación a AR
Ciclo de vida del contenido	Entrega única	Actualizaciones continuas de catálogo, pipeline de administración para nuevos modelos

El pipeline y el presupuesto de rendimiento son donde más fallan las estimaciones. Un proveedor que no pregunta de dónde vienen los modelos ni en qué móvil vas a probar no ha estimado el proyecto. Si buscas programadores Three.js que empiecen por el pipeline y por la prueba en un dispositivo real, así es exactamente como estructuramos nuestros proyectos 3D. Por lo demás, la lógica de coste es la misma que la de cualquier desarrollo a medida; ver cuánto cuesta desarrollar software personalizado en Europa.

Qué preguntar a un proveedor

1. ¿Qué renderer y versión, y cuál es la estrategia de fallback WebGPU/WebGL?
2. Muéstranos un proyecto 3D ya entregado en un móvil de gama media, ahora mismo, y déjanos observar el frame rate durante cinco minutos.
3. ¿Quién se encarga de la preparación de assets, y cuál es el proceso y el plazo por modelo?
4. ¿Cuál es el presupuesto de tamaño por escena y cómo se aplica en CI?
5. ¿Cómo se expone el estado de la escena al DOM para accesibilidad, analítica y deep links?
6. ¿Qué ocurre cuando WebGL no está disponible o se pierde el contexto?
7. ¿Cómo se añadirán nuevos productos tras el lanzamiento sin un desarrollador?
8. ¿Cuál es la estrategia de pruebas: capturas de regresión visual, laboratorio de dispositivos, monitorización de usuarios reales?

Checklist de decisión

• Elige Three.js (con R3F si tu app es React) para visualización de producto, configuradores, marketing, dashboards y la mayoría de data viz.
• Elige Babylon.js para simuladores, formación, interacción tipo juego, o cuando quieras física, GUI e inspector listos para usar.
• Elige PlayCanvas cuando los artistas necesiten un editor y aceptes una toolchain alojada.
• Elige WebGPU-first solo cuando controles los dispositivos o necesites compute en GPU; en caso contrario, base WebGL 2 con WebGPU como mejora.
• Elige imágenes o vídeo prerrenderizados en lugar de 3D en tiempo real cuando el usuario no necesite cambiar nada, porque son más baratos, más rápidos y accesibles por defecto.

Recomendación

Construye sobre Three.js con el renderer WebGPU y fallback automático a WebGL 2, usa React Three Fiber si la aplicación que lo rodea es React, y reserva Babylon.js para trabajo intensivo de simulación. Dedica las primeras semanas al pipeline de assets y a un harness de rendimiento en un móvil de gama media real; esas dos cosas deciden si el resto es viable. Deja por escrito en el contrato el suelo de dispositivo, el presupuesto de tamaño por escena y el fallback de accesibilidad, y pide a cada proveedor que muestre una escena entregada en un móvil antes de comparar precios. En Arvucore solemos recomendar un spike de viabilidad de dos semanas con un modelo real en el dispositivo objetivo antes de comprometer una estimación completa.