WebGPU em 2026: quando vale a pena reescrever a sua app 3D na web (e quando o WebGL ainda chega)
O WebGPU está agora em todos os principais browsers. Como era previsível, a pergunta chegou à nossa caixa de entrada numa semana: "devíamos passar o nosso visualizador 3D para WebGPU?" Normalmente a resposta é "ainda não, e eis o teste." Uma nova API gráfica não é motivo para reescrever um produto que funciona.
Entregamos 3D em tempo real no browser — configuradores, visitas virtuais, visualizações médicas — em Three.js e WebGL puro. Eis a árvore de decisão honesta que usamos em 2026.
O que o WebGPU realmente traz
- Compute shaders. O verdadeiro destaque. Computação no GPU dentro do browser sem truques — sistemas de partículas, física, simulação, inferência de ML. O WebGL nunca teve isto.
- Menos sobrecarga de CPU por draw call. O WebGPU foi desenhado em torno dos GPUs modernos. Cenas com milhares de objetos distintos deixam de ser limitadas pelo CPU.
- Melhor multithreading e estado de pipeline explícito. Previsível, explícito, menos adivinhação do driver.
O que não traz
- Uma imagem mais bonita de graça. Um único produto num prato giratório fica igual. O WebGPU não é uma melhoria de qualidade; é uma melhoria de throughput e de computação.
- Menos trabalho. A API é de mais baixo nível — mais configuração, mais corda para se enforcar. Se está em Three.js, o renderer abstrai a maior parte disto, que é precisamente o objetivo.
- Suporte universal em hardware antigo. É amplo agora, mas continua a precisar de um caminho de fallback para dispositivos antigos e máquinas empresariais bloqueadas.
O teste que aplicamos antes de reescrever
- Está limitado pelo CPU nas draw calls? Faça profiling primeiro. Se o gargalo é memória de texturas ou fill rate, o WebGPU não o salva.
- Precisa de computação no GPU? Simulação de multidões, tecido, fluidos, grandes contagens de partículas, ML no browser. Se sim, o WebGPU é o único caminho sensato.
- A cena é genuinamente pesada? Milhares de malhas únicas, instancing à escala. Um único carro de configurador não é pesado.
Se respondeu não às três, a sua build em WebGL está bem. Já defendemos que a maioria dos sites não precisa da ferramenta pesada; a mesma contenção aplica-se às APIs gráficas.
O caminho pragmático: WebGPURenderer do Three.js
Quase nunca se escreve WebGPU em bruto à mão para trabalho de produto. O Three.js inclui um renderer WebGPU que faz fallback automático para WebGL. Escreve uma vez, obtém computação quando o dispositivo suporta, e mantém uma imagem funcional em tudo o resto. É essa a migração que realmente recomendamos: trocar o renderer, não o código todo, e só quando o profiler o disser.
Onde isto importa para nós
As nossas cenas de browser mais pesadas são entregáveis de captura 3D — nuvens de pontos e splats com milhões de pontos. É exatamente essa a carga em que o caminho de computação do WebGPU compensa, e é por isso que o nosso raciocínio sobre Gaussian splatting vs fotogrametria passou a considerar o renderer. Para um configurador num prato giratório? Continuamos em WebGL e sem pedir desculpa.
A versão curta
O WebGPU é um avanço real para 3D pesado em computação e em objetos. Não é uma ordem para reescrever. Faça profiling, encontre o gargalo, troque o renderer se o gargalo forem as draw calls ou se precisar de computação, e mantenha um fallback WebGL em qualquer dos casos.
Tem uma app 3D na web que parece lenta e não sabe porquê? Envie-nos a cena — fazemos profiling antes de alguém dizer "reescrever".