Three.js e WebGL em 2026: guia prático de desenvolvimento 3D

O Three.js sobre WebGL continua sendo o caminho padrão para entregar 3D interativo na web em 2026, e agora mira o WebGPU pela mesma API quando o navegador suporta. Se você está escopando uma aplicação web 3D, a biblioteca de renderização raramente é a decisão difícil; o pipeline de assets, o orçamento de performance no mobile e a profundidade da interatividade são o que define custo e prazo. Este guia cobre as escolhas de tecnologia, o pipeline, as regras de performance e o que perguntar a um fornecedor antes de assinar.

WebGL vs WebGPU: onde as coisas estão em 2026

O WebGL 2 é o alvo seguro. Roda em todos os navegadores atuais, desktop e mobile, em GPUs integradas e dentro de webviews. Seus limites são conhecidos: uma API de máquina de estados herdada do OpenGL ES, sem compute shaders e com um overhead por draw call que depende do driver.

O WebGPU é o sucessor moderno. Expõe compute shaders, binding explícito de recursos e um custo de CPU menor por draw. Chrome e Edge lançaram primeiro, Firefox e Safari vieram depois, e o suporte hoje é amplo em hardware recente. O que ainda não é verdade em 2026 é disponibilidade universal: dispositivos Android antigos, alguns webviews embarcados e máquinas corporativas com drivers de GPU travados caem para WebGL ou para nada. Planeje o WebGPU como aprimoramento, não como base, a menos que você controle os dispositivos (quiosques, ferramentas internas, uma frota de tablets).

O Three.js resolve essa divisão para você. O WebGPURenderer usa WebGPU quando disponível e cai para WebGL 2 automaticamente, e o sistema de materiais baseado em nós (TSL, Three Shading Language) compila tanto para WGSL quanto para GLSL. Na prática, você escreve a cena uma vez. A contrapartida é que alguns add-ons antigos e código customizado de ShaderMaterial são só WebGL, então uma aplicação com muitos shaders customizados vai precisar de um plano de migração, não apenas de uma troca de renderer.

Regra prática para um projeto novo: construa em Three.js com WebGPURenderer, mantenha os shaders customizados em TSL e teste o caminho de fallback WebGL em um Android intermediário desde o primeiro dia. Se a carga de trabalho exige compute na GPU (sistemas de partículas com milhões de pontos, física, visualização de dados em grande volume), o WebGPU deixa de ser opcional e sua declaração de suporte a dispositivos encolhe na mesma proporção.

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

Essas são as quatro opções realistas para uma aplicação de negócio. Unity e Unreal exportam para a web, mas os bundles são grandes e o licenciamento foi feito para jogos; reserve-os para conteúdo que já existe nessas engines.

Critério	Three.js	Babylon.js	PlayCanvas	React Three Fiber
O que é	Biblioteca de renderização	Engine 3D completa	Engine + editor hospedado	Renderer React para Three.js
Licença	MIT	Apache 2.0	MIT (engine); o editor é serviço pago	MIT
WebGPU	Sim, com fallback WebGL	Sim, com fallback WebGL	Sim	Herda do Three.js
Tamanho do bundle (ordem de grandeza)	O menor dos quatro, tree-shakable	Core maior, pacotes modulares	Engine de porte médio	Three.js mais uma camada fina
Física, GUI e áudio embutidos	Via add-ons e terceiros	Embutidos	Embutidos	Via drei e ecossistema
Editor visual	Nenhum oficial	Inspector e sandbox	Produto principal	Nenhum (Leva, Triplex para props)
Ecossistema e contratação	Maior base de talentos	Grande, apoiado pela Microsoft	Menor	Grande entre times React
Melhor uso	Visualização de produto, configuradores, sites, data viz	Simulações, treinamento, apps tipo jogo	Jogos em equipe e apps de conteúdo	Apps React que precisam de 3D como UI

O Three.js vence em flexibilidade e no tamanho da comunidade, o que importa na hora de contratar. O Babylon.js vence quando você quer uma engine que já entrega física, GUI, grupos de animação e um inspector de debug, e quando a aplicação se parece mais com um jogo ou simulador do que com uma página web. O PlayCanvas é a escolha quando não desenvolvedores (artistas, level designers) precisam montar cenas em um editor e publicá-las. O React Three Fiber (R3F) não concorre com os outros; é a forma como um time React deveria consumir o Three.js, e combina com bibliotecas de estado como Zustand do mesmo jeito que o resto da aplicação já faz (veja gerenciamento de estado em aplicações complexas).

Uma cena mínima em Three.js

Os conceitos centrais cabem em trinta linhas: um renderer ligado a um canvas, um grafo de cena, uma câmera, luzes, um mesh e um loop de renderização. Todo o resto é loader, controle e otimização.

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(); // escolhe WebGPU ou cai para 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);
});

Um detalhe já pesa na performance: limitar o devicePixelRatio a 2 evita que um celular 3x renderize nove vezes os pixels de uma tela 1x.

Pipeline de assets: glTF, compressão e orçamento de texturas

A maioria dos projetos web 3D que fracassam fracassa no pipeline de assets, não no JavaScript. Exportações de CAD com milhões de triângulos e texturas 4K em cada peça não podem ser "otimizadas depois" pelo time de frontend. Decida o pipeline antes de a modelagem começar.

Formato. glTF 2.0, empacotado como um único binário .glb, é o único formato de intercâmbio sensato para a web. Carrega materiais PBR, animações, skins e morph targets, e as extensões Khronos cobrem compressão e materiais avançados (clearcoat, transmission, sheen).

Exportação no Blender. O Blender costuma ser a última etapa mesmo quando a origem é CAD: importar, limpar, decimar, fazer bake e exportar para glTF com "Apply Modifiers" e Y-up. Fazer bake de iluminação e oclusão de ambiente nas texturas nessa etapa economiza trabalho em tempo de execução em todos os dispositivos.

Compressão de geometria. Use Draco ou Meshopt. O Draco comprime mais, mas precisa de um decoder em WebAssembly e de uma etapa de decodificação na CPU antes do upload. O Meshopt (via gltfpack ou gltf-transform) decodifica mais rápido e também suporta quantização, que costuma ser a melhor troca para mobile. De qualquer forma, espere a geometria encolher para uma fração do tamanho bruto.

# Passe de otimização típico
npx @gltf-transform/cli optimize product.glb product.opt.glb \
  --compress meshopt --texture-compress ktx2 --texture-size 2048

Texturas. Texturas, e não geometria, costumam ser o maior download e o maior consumidor de memória da GPU. Converta para KTX2 com Basis Universal (ETC1S para cor, UASTC para normal maps e qualquer coisa com detalhe fino) para que a GPU as mantenha comprimidas na memória; um PNG ou JPEG descomprime para o tamanho cheio na GPU e esgota um celular rapidamente. Defina um orçamento de texturas por cena: contagem total de texels, resolução máxima por material e uma regra de atlas para peças pequenas.

Validação no CI. Rode o validador glTF da Khronos e uma verificação de tamanho a cada commit de asset. Trate modelos como código: versionados, revisados e rejeitados quando estouram o orçamento. Sirva-os de um CDN com headers de cache imutáveis, como descrito em estratégias de cache para performance.

Performance: draw calls, instancing, LOD e aquecimento no mobile

Defina uma meta de frame time e um piso de dispositivo antes de escrever funcionalidades: 60 fps em um laptop atual e 30 fps estáveis em um Android intermediário de três anos é uma base comum e honesta. Depois, proteja-a.

• Draw calls. Cada mesh com material próprio é um draw call; centenas são aceitáveis, milhares não são no WebGL. Mescle geometria estática, compartilhe materiais e use atlas de texturas. O WebGPU eleva o teto, mas não o elimina.
• Instancing. Para objetos repetidos (cadeiras, parafusos, árvores, pontos de dados), o InstancedMesh renderiza milhares de cópias em uma única chamada. É o maior ganho isolado na maioria das cenas de produto e data viz.
• Level of detail. Use THREE.LOD ou trocas manuais para mostrar meshes mais simples à distância, e carregue partes de alto detalhe sob demanda apenas quando a câmera se aproxima. Exporte os níveis de LOD do Blender em vez de gerá-los em tempo de execução.
• Pixel ratio e escala de resolução. Renderize em resolução interna menor em GPUs fracas e faça upscale. Resolução dinâmica atrelada ao frame time medido é barata de implementar e eficaz.
• Sombras e pós-processamento. Sombras em tempo real, efeitos em screen space e antialiasing multi-sample são as primeiras coisas a desligar em um preset de qualidade "baixa". Iluminação com bake fica melhor do que iluminação em tempo real barata, de qualquer forma.
• Limites térmicos no mobile. Um celular reduz a frequência depois de um ou dois minutos de carga sustentada na GPU; uma cena que roda a 60 fps nos primeiros dez segundos e a 20 fps depois de três minutos falha com o usuário. Renderize sob demanda (só quando a câmera ou o estado muda) em vez de um loop contínuo para cenas estáticas, e meça sessões de cinco minutos, não de cinco segundos.
• Memória. Descarte geometrias, materiais e texturas quando a cena muda. Acompanhe renderer.info e snapshots de heap; vazamentos em single-page apps são comuns quando modelos são trocados em um configurador.

Instrumente usuários reais: histogramas de frame time, tempo até o primeiro frame renderizado e eventos de perda de contexto. Eles pertencem ao mesmo dashboard dos seus Core Web Vitals; um canvas sem carregamento adiado arrasta LCP e INP para baixo junto com ele.

Onde aplicações web 3D compensam

O caso de negócio é mais forte quando a terceira dimensão carrega informação que o 2D não consegue, e mais fraco quando é decoração.

• Configuradores de produto. Móveis, veículos, equipamentos industriais, vestuário personalizado. O valor está na entrega: o estado configurado precisa mapear para SKUs, preços e um carrinho ou CRM. Reserve mais orçamento para a integração do que para a renderização.
• Gêmeos digitais. Prédios, plantas, frotas e redes renderizados a partir de BIM ou CAD e sobrepostos com dados de sensores ao vivo. São problemas de cena grande: streaming, LOD e tiling.
• Visualização de dados. Nuvens de pontos, dados volumétricos, grafos de rede com centenas de milhares de nós. É aqui que o compute do WebGPU se justifica, e onde instancing é obrigatório.
• Treinamento e simulação. Operação de equipamentos, procedimentos de segurança, treinamento médico. Frequentemente prontos para WebXR, às vezes com física; o lado Babylon.js da tabela acima fica mais atraente aqui.
• Tours imobiliários e de espaços. Capturas por fotogrametria ou Gaussian splatting de ambientes, e modelos leves de apartamentos com troca de materiais. Disciplina no tamanho do carregamento importa mais do que qualquer outra coisa, porque o público está no celular.

Acessibilidade e fallbacks

Um canvas é opaco para tecnologias assistivas, então a versão acessível da experiência vive no DOM ao redor dele. As regras práticas:

• Toda ação disponível por arrastar ou clicar na cena também precisa existir como botão, lista ou controle de formulário. O seletor de material de um configurador é um conjunto de radio buttons; a visão 3D é um preview desse estado, não a única forma de defini-lo.
• Anuncie mudanças de estado com uma região ARIA live ("Cor alterada para nogueira"), dê ao canvas um nome acessível e uma descrição em texto do que ele mostra, e mantenha a ordem de foco coerente.
• Respeite prefers-reduced-motion: desative rotação automática, fly-ins de câmera e parallax quando estiver ativo.
• Ofereça um fallback. Quando o WebGL não estiver disponível ou o contexto for perdido, mostre imagens pré-renderizadas dos mesmos estados. Turntables pré-renderizados também são o que os mecanismos de busca e os previews sociais vão ver.
• Não trave a página. Carregue o bundle 3D depois do conteúdo, na interação ou na visibilidade, para que usuários em redes lentas recebam os dados do produto primeiro.

As regras mais amplas estão no nosso guia WCAG para desenvolvimento web; o canvas não isenta a página delas.

Escopo e estimativa de um projeto web 3D

Compradores pedem "um visualizador 3D" e recebem propostas que diferem em uma ordem de grandeza. A diferença está nas premissas abaixo; fixe-as por escrito antes de comparar fornecedores.

O que define o custo

Fator	Extremo baixo	Extremo alto
Pipeline de assets	Modelos glTF limpos já existem	CAD ou scans que precisam ser limpos, retopologizados, com bake e comprimidos; dezenas de SKUs
Interatividade	Orbitar, zoom, algumas trocas de material	Montagens com restrições, animações, medições, anotações, física
Orçamento de performance	Desktop primeiro, "roda em celulares recentes"	30 fps estáveis em Android intermediário de três anos, uptime de quiosque, testes térmicos
Suporte a dispositivos e navegadores	Chrome, Safari, Firefox atuais	Webviews antigos, navegadores embarcados, headsets WebXR, PWA offline
Integrações	Configuração estática	Preço ao vivo, estoque, CRM, geração de PDF/orçamento, exportação para AR
Ciclo de vida do conteúdo	Entrega única	Atualizações contínuas de catálogo, pipeline administrativo para novos modelos

O pipeline e o orçamento de performance são onde as estimativas mais erram. Um fornecedor que não pergunta de onde vêm os modelos e em qual celular você vai testar não estimou o projeto. Se você precisa de desenvolvedores Three.js que comecem pelo pipeline e pelo teste em dispositivo real, é exatamente assim que estruturamos nossos projetos 3D. A lógica de custo, no mais, é a mesma de qualquer desenvolvimento sob medida; veja quanto custa desenvolver software personalizado na Europa.

O que perguntar a um fornecedor

1. Qual renderer e versão, e qual é a estratégia de fallback WebGPU/WebGL?
2. Mostre um projeto 3D já entregue em um celular intermediário, agora, e deixe-nos observar o frame rate por cinco minutos.
3. Quem é dono da preparação de assets, e qual é o processo e o prazo por modelo?
4. Qual é o orçamento de tamanho por cena e como ele é aplicado no CI?
5. Como o estado da cena é exposto ao DOM para acessibilidade, analytics e deep links?
6. O que acontece quando o WebGL não está disponível ou o contexto é perdido?
7. Como novos produtos serão adicionados depois do lançamento sem um desenvolvedor?
8. Qual é a estratégia de testes: screenshots de regressão visual, laboratório de dispositivos, monitoramento de usuários reais?

Checklist de decisão

• Escolha Three.js (com R3F se sua aplicação é React) para visualização de produto, configuradores, marketing, dashboards e a maior parte de data viz.
• Escolha Babylon.js para simuladores, treinamento, interação tipo jogo, ou quando quiser física, GUI e inspector prontos.
• Escolha PlayCanvas quando artistas precisam de um editor e você aceita uma toolchain hospedada.
• Escolha WebGPU-first só quando controla os dispositivos ou precisa de compute na GPU; caso contrário, base em WebGL 2 com WebGPU como aprimoramento.
• Escolha imagens ou vídeo pré-renderizados em vez de 3D em tempo real quando o usuário não precisa mudar nada, porque são mais baratos, mais rápidos e acessíveis por padrão.

Recomendação

Construa em Three.js com o renderer WebGPU e fallback automático para WebGL 2, use React Three Fiber se a aplicação ao redor é React, e reserve o Babylon.js para trabalho pesado de simulação. Dedique as primeiras semanas ao pipeline de assets e a um harness de performance em um celular intermediário real; esses dois decidem se o resto é viável. Coloque o piso de dispositivo, o orçamento de tamanho por cena e o fallback de acessibilidade no contrato, e peça a todo fornecedor que mostre uma cena entregue em um celular antes de comparar preços. Na Arvucore, costumamos recomendar um spike de viabilidade de duas semanas com um modelo real no dispositivo-alvo antes de fechar uma estimativa completa.