Um site com WebGL é uma página comum que desenha uma cena 3D num canvas, usando a placa de vídeo. Por dentro, são poucos arquivos: modelos .glb, uma imagem de reserva, fontes, scripts e shaders. Abrimos a home da Brave Cross e mostramos cada um, com peso e função.
Como funciona um site com WebGL, em uma frase por camada?
O HTML chega primeiro e monta a página. O JavaScript chega depois, cria um elemento canvas e pede à placa de vídeo para desenhar nele. A biblioteca que faz essa ponte na home é o three.js, com React Three Fiber por cima.
A cena precisa de três coisas: geometria (a forma), material (como a luz bate) e câmera. A geometria vem de arquivos .glb. O material, nos efeitos próprios, vem de shaders: pequenos programas em GLSL que rodam na placa de vídeo, um para cada vértice e um para cada pixel.
Usamos o nosso próprio site de propósito. É o único caso em que podemos abrir tudo, publicar os números e não expor o trabalho de ninguém.
O que a aba Rede mostra quando você abre a home?
A aba Rede do Chrome DevTools lista cada arquivo que o navegador pede, com tipo, tamanho e ordem. Na medição de outubro de 2026, o primeiro carregamento no celular somou 404 KB em 24 requisições.
404 KB
tudo o que chega no primeiro carregamento, em 24 requisições
medição de laboratório Brave Cross, out/2026
30 ms
tempo total de bloqueio da thread principal
medição de laboratório Brave Cross, out/2026
0
deslocamento de layout acumulado (nada pula na tela)
medição de laboratório Brave Cross, out/2026
4,6 s
maior pintura de conteúdo, adiada pela cortina de abertura
medição de laboratório Brave Cross, out/2026
Repare no que NÃO está na lista: nenhum .glb. No celular, o 3D entra depois do primeiro quadro. Enquanto isso, o visitante vê um pôster do monólito em .webp de 9 KB. Os scripts de terceiros também esperam: só carregam após a primeira interação ou depois de 4 segundos.
Quando a página é baixada com o Extrator, que escuta a rede e rola a página sozinho, a pasta recebe também o que chega depois do primeiro quadro, como os modelos .glb. É a diferença entre guardar a foto do herói e guardar o herói funcionando, explicada em como baixar um site completo.
Que arquivos formam um herói 3D, e quanto cada um pesa?
| Tipo de arquivo | O que faz | Peso na home da Brave Cross |
|---|---|---|
| .glb (monólito) | Modelo 3D binário: forma, materiais e texturas num arquivo só | 36 KB |
| .glb (marca em 3D) | Modelo da marca, usado em outra cena do site | 347 KB |
| .webp (pôster) | Imagem do monólito exibida antes do 3D no celular | 9 KB |
| .woff2 (fontes) | Fontes do texto, servidas pelo próprio site | 124 KB em 3 arquivos |
| .js (scripts) | three.js, React, animação e a lógica da cena | 219 KB em 17 arquivos |
| Shaders GLSL | Programas que pintam vértices e pixels na placa de vídeo | vão como texto dentro dos .js, sem arquivo próprio |
| .hdr e .ktx2 | Iluminação de ambiente e texturas comprimidas para a GPU | não aparecem no primeiro carregamento medido |
Fonte: medição de laboratório da Brave Cross com Lighthouse 12.8.2 em 7 de outubro de 2026 (emulação de celular) e tamanhos dos arquivos no repositório na mesma data.
Dois formatos merecem explicação. O .glb é a versão binária do glTF, que a Khronos descreve como formato de entrega de 3D: uma cena inteira num arquivo só. O monólito tem 36 KB porque a forma é simples: peso de modelo acompanha a quantidade de detalhe.
O .hdr é uma imagem de alto alcance dinâmico, usada para iluminar a cena como se ela estivesse num ambiente real. O .ktx2 é um contêiner de texturas que, segundo a especificação KTX da Khronos, suporta compressão Basis Universal, pensada para ir direto à placa de vídeo. Muitos sites premiados usam os dois; você os encontra na aba Rede de qualquer herói mais pesado.
Por que o LCP de 4,6 s não é culpa do 3D?
O LCP mede quando o maior elemento visível aparece. O guia do web.dev considera bom um LCP de até 2,5 s, medido no percentil 75. O nosso, em laboratório, ficou em 4,6 s.
O elemento medido é o texto do herói, não o 3D. Ele entra desfocado por trás de uma cortina de abertura de cerca de 1,2 s. A cortina roda no compositor, pela Web Animations API, sem shader síncrono, e por isso não trava nada: o bloqueio total foi de 30 ms. Mas ela adia a pintura de propósito.
É uma troca consciente: velocidade medida por entrada encenada. Pode ser revista. O ponto honesto é que o 3D, sozinho, não explica o número. Quem quiser a conta completa de desempenho encontra em site 3D pesa?. O Lighthouse não mede quadros por segundo; a cena foi projetada para 60 fps, e isso exige animar só transform e opacity, que é o que as animações infinitas da home fazem.
O que acontece com quem pede menos movimento?
O sistema operacional permite pedir menos animação. O site lê esse pedido com a media query prefers-reduced-motion. A WCAG trata do tema no critério sobre animação disparada por interação, que pede que esse movimento possa ser desligado.
Na home, com "reduzir movimento" ligado, o conteúdo dissolve em vez de congelar. Congelar deixa elementos presos fora do lugar. Dissolver mantém a leitura e tira o deslocamento, que é o que causa enjoo.
Como fazer a mesma anatomia em outro site?
Baixe a página
Guarde o site com o Extrator, deixando ele rolar até o fim.
Abra a aba Rede
Recarregue com o cache desligado e filtre por tipo de arquivo.
Ache o 3D
Procure .glb, .gltf, .hdr e .ktx2 e anote o tamanho e o momento em que chegam.
Ache os shaders
Busque por gl_FragColor ou fragmentShader dentro dos arquivos .js.
Meça o primeiro quadro
Rode o Lighthouse em modo celular e veja qual elemento define o LCP.
O roteiro completo de engenharia reversa está em como estudar um site do Awwwards por dentro. Se a ferramenta antiga devolver uma página quebrada, o motivo está em por que o HTTrack não baixa sites modernos. E, para escolher o que estudar a seguir, há 20 sites para estudar em 2026. Estude, referencie e guarde o que é seu: layout e código de terceiros continuam sendo de quem fez.
Perguntas frequentes
Como funciona um site com WebGL?
O navegador carrega a página, o JavaScript cria um canvas e uma biblioteca como o three.js pede à placa de vídeo que desenhe a cena. Modelos chegam em .glb, os efeitos são shaders em GLSL. Na home da Brave Cross, nada disso entra no primeiro quadro do celular, segundo medição de laboratório de outubro de 2026.
Site com 3D é sempre pesado?
Não necessariamente. O primeiro carregamento da home da Brave Cross no celular somou 404 KB, com 30 ms de bloqueio e deslocamento de layout zero, segundo medição de laboratório em outubro de 2026. O que pesa é carregar o 3D antes da hora. Pôster leve primeiro, modelo depois, resolve boa parte.
O que é um arquivo .glb?
É a versão binária do glTF, formato aberto da Khronos para entregar cenas 3D. Um único .glb guarda geometria, materiais, texturas e animações. O monólito da home da Brave Cross tem 36 KB nesse formato; a marca em 3D, mais detalhada, tem 347 KB.
Onde ficam os shaders de um site?
Quase sempre dentro dos arquivos JavaScript, como texto em GLSL que o navegador envia para a placa de vídeo. Por isso eles não aparecem como arquivo separado na aba Rede. Para achá-los, busque por fragmentShader ou gl_FragColor nos .js da página baixada.
Dá para ter herói 3D e passar no Core Web Vitals?
Dá, desde que o 3D não segure o primeiro quadro. O ponto fraco da home da Brave Cross é o LCP de 4,6 s em laboratório, acima dos 2,5 s recomendados pelo web.dev, e a causa é a cortina de abertura, não o modelo 3D. O guia de site 3D explica as escolhas.
Quer um herói assim no seu site?
O que fica: um herói 3D bem feito é leve na rede, livre na thread principal e honesto com quem pede menos movimento. O custo que sobra é de escolha de direção, e escolha pode ser revista. Você pode ver o resultado ao vivo na home da Brave Cross, nos serviços de 3D Experiences e nos projetos. Se quiser aprender a montar sites assim, há o Método e a Brave Cross Education.
Se a sua marca pede uma primeira tela que se move, com o peso sob controle, fale com a Brave Cross.