Tamanho do arquivo do modelo 3D: o que o celular carrega

Um tamanho de arquivo do modelo 3D de 5 MB já é demais para uma página de produto aberta no celular. O peso que sobrevive num Android intermediário e numa conexão móvel comum fica perto de 2 MB, e a razão é aritmética, não gosto: a 5 Mbps, cada megabyte custa 1,6 segundo antes de o visualizador desenhar o primeiro quadro.

Quando você aceita esse número, a conversa muda. Quase todo fornecedor trata o modelo como material de marketing e o tamanho do arquivo como problema do estúdio 3D. O comprador só vê a primeira coisa que baixa ao abrir a página. Aqui estão a tabela de orçamento, os quatro lugares onde os bytes somem e as seis verificações que valem antes de colar um link 3D num e-mail de cotação.

Tabela de tamanho de arquivo do modelo 3D: o que o celular baixa primeiro

O tempo de download é tamanho × 8 ÷ velocidade da conexão. Renderização, rotação e primeiro quadro não entram na conta. A tabela supõe conexão estável e ignora o handshake TLS e a latência de ida e volta, então um celular real sempre demora mais.

Leia a linha de 50 MB duas vezes. São 13 segundos até numa boa conexão de escritório e mais de quatro minutos no sinal fraco de um galpão, showroom ou hotel. Um modelo desse tamanho não é material de apresentação: é uma transferência de arquivo que o comprador não autorizou.

O modelo 3D é o único ativo de produto em que o comprador baixa o produto inteiro antes de ver qualquer parte dele. Uma foto pode aparecer de cima para baixo; um vídeo começa depois de alguns segundos de buffer; um GLB não.

Por que o modelo inteiro precisa chegar antes

A especificação glTF 2.0 diz explicitamente que o formato não é de streaming: os dados binários podem ser transmitidos em fluxo, mas o glTF não define nenhuma estrutura de streaming. Por isso o visualizador carrega o ativo, interpreta e só então renderiza. Não existe uma prévia parcial que pareça o produto.

O contêiner importa. Um GLB empacota a descrição JSON da cena e os buffers binários num arquivo sem expansão base64: eficiente em uma requisição, mas o comprador espera o pacote inteiro. Um .gltf separado com .bin e texturas permite ao visualizador buscar partes e começar antes, ao custo de mais requisições e mais pontos de falha. Para um cartão de produto de um único SKU, um GLB costuma ser a escolha certa; para uma linha de 60 SKUs, compartilhar arquivos divididos costuma pesar menos no total.

Nada disso aparece na seção de imagens dos relatórios de performance, e é por isso que passa batido. O elemento de Largest Contentful Paint numa página de produto costuma ser a imagem principal ou um bloco de texto, não um canvas WebGL. O limite do Google é 2,5 segundos ou menos no percentil 75. Se o JavaScript do visualizador e o download do modelo disputam banda com a imagem principal, a página perde esse limite enquanto o time 3D informa que "o modelo renderiza normal".

Quanto o resto da página já pesa

Os dados de 2024 do HTTP Archive no Web Almanac colocam a página mediana de desktop em 2.312 KB e a de celular em 2.037 KB. No celular, só as imagens ocupam cerca de 900 KB dessa página mediana.

Compare o modelo com esses números:

É assim que se define um orçamento. A visualização 3D é um elemento de uma página que também carrega galeria, tabela de especificações, avaliações, scripts de análise e template. Se só o modelo já passa da página mediana, o modelo vira a página, e o comprador paga em segundos.

Clima e Wi-Fi de feira pioram isso, e o aparelho também. Um celular intermediário de três anos atrás decodifica uma textura de 4096 pixels bem mais devagar que o notebook em que o arquivo foi aprovado. Teste no celular, não no monitor do estúdio.

Onde os bytes vão e qual compressão resolve cada parte

O tamanho do arquivo se concentra em três blocos, normalmente nesta ordem: texturas, geometria e todo o resto (animação, câmeras, nós sobrando). Surpreende que a geometria raramente seja o maior vilão. Um modelo derivado de fotos com uma única textura PNG de 4096 × 4096 pode pesar mais que a malha que ela envolve.

Duas extensões ratificadas pela Khronos fazem o trabalho de compressão e resolvem problemas diferentes. KHR_draco_mesh_compression transmite geometria comprimida em vez de dados de vértices crus. KHR_texture_basisu guarda texturas como KTX2 com supercompressão Basis Universal, o que reduz o tamanho de transmissão e a memória de GPU.

As duas são extensões, não glTF básico. O visualizador precisa suportá-las e o arquivo deve declará-las em extensionsRequired quando não houver fallback sem compressão. Antes de enviar, abra o arquivo exportado no visualizador exato que o comprador vai usar: seu cartão de produto, seu site ou o espaço 3D de um marketplace. Abrir no Blender não prova nada sobre um navegador de celular.

Seis verificações antes de enviar um link de visualização 3D

Faça na ordem. As duas primeiras evitam a maior parte do prejuízo; as outras quatro evitam as falhas que terminam em e-mail de suporte em vez de pedido.

• O arquivo é um .glb único exportado para web, não um .blend, .step ou .obj com texturas soltas
• Esse .glb cabe no orçamento de peso da conexão que seus compradores realmente usam
• Uma imagem estática carrega primeiro e o visualizador só começa quando o comprador toca ou rola até ele
• Um dedo gira, o pinça dá zoom e o modelo não pula nem passa da borda
• A silhueta, a contagem de peças e a ferragem continuam batendo com o produto e com o desenho cotado
• Um comprador sem WebGL, ou com navegador corporativo bloqueado, ainda recebe as fotos e a tabela de especificações

Verificação 1: é exportação web, não arquivo de trabalho

.blend ou .step é documento de autoria: carrega histórico, câmeras, materiais e às vezes texturas que vivem numa pasta do notebook de alguém. O contêiner web é GLB, e a cena deve ter um produto, uma câmera e materiais que o visualizador consiga ler. Se o diálogo de exportação perguntar sobre "aplicar modificadores" ou "incluir objetos ocultos", a resposta é sim para o primeiro e não para o segundo.

As fotos de origem importam tanto quanto a exportação. Um modelo montado com ângulos e luzes misturados mostra essas emendas quando o comprador gira, pelo mesmo motivo que um conjunto de fotos inconsistente derruba a página. Se o conjunto ainda está sendo produzido, comece por fotos para uma visualização 3D do produto antes de mexer no exportador.

Verificação 2: o peso corresponde à conexão, não ao estúdio

Abra as propriedades do arquivo exportado, leia o tamanho de arquivo do modelo 3D em megabytes e compare com a tabela acima. Sempre no arquivo exportado, nunca no projeto: um arquivo de trabalho de 40 MB pode sair com 3 MB, e um de 3 MB pode sair com 30 MB ao empacotar texturas.

Se passar do orçamento, conserte o maior bloco primeiro. Trocar quatro mapas PNG de 4096 pixels por um ou dois JPEG de 1024 costuma tirar mais peso do que qualquer mudança de geometria. Draco e KTX2 vêm depois: tornam menor um ativo razoável, não transformam um ativo absurdo em aceitável.

Verificação 3: o primeiro quadro é uma imagem estática, não um canvas vazio

Carregue o visualizador de forma preguiçosa e mostre uma imagem fixa, de preferência do mesmo ângulo em que o modelo abre, até o comprador interagir. Isso tira o canvas 3D do caminho crítico e mantém na página um candidato real a LCP.

A falha seguinte mais comum é a resposta ao toque. O limite de Interaction to Next Paint do Google é 200 milissegundos no percentil 75; acima de 500 ms é ruim. Um modelo pesado mais motor de física mais passe de sombra empurra o toque-para-girar além dessa linha num celular intermediário, mesmo que a página carregue rápido.

Verificação 4: gira com um polegar

Segure o celular com uma mão e gire o modelo com o polegar. Se o gesto exigir dois dedos, se o modelo continuar girando ao soltar ou se o zoom deslocar o centro de rotação, o comprador vai brigar com o visualizador em vez de ler o produto.

Teste também as bordas: topo, base, parte de trás. Um visualizador que limita a rotação a ±45 graus esconde justamente as superfícies que o comprador quer inspecionar, as que o estúdio nunca fotografa.

Verificação 5: a forma continua batendo com o produto

Gire o modelo contra a unidade real e o desenho cotado. Olhe a silhueta, a ferragem, as linhas de junção e a espessura do canto de cada painel. Depois olhe o que o comprador vai checar: dobradiças, pés, puxadores, o perfil de uma moldura.

Converter foto em ativo 3D é etapa de apresentação, não de medição. O modelo pode suavizar uma curva; não pode inventar um puxador, apagar uma junta ou mudar uma proporção que o desenho declara. Se modelo e desenho discordam, o desenho manda e o modelo é refeito.

É aqui que os dois tipos de saída precisam ser honestos entre si. O modelo giratório mostra forma e como as peças se encontram; o diagrama cotado mostra os números. Um software que fixa as dimensões medidas sobre a foto e gera o modelo giratório a partir da mesma fonte evita que essas duas visões se separem, e mantém a cota na anotação, onde o comprador consegue ler, em vez de dentro do render, onde ninguém consegue medir.

Verificação 6: existe fallback para quem não consegue ver

Notebooks corporativos bloqueiam WebGL. Alguns navegadores desativam por padrão. Celulares antigos ficam sem memória com texturas grandes. Em todos esses casos o comprador deveria receber a imagem estática, a tabela de especificações e o botão de contato.

Escreva o fallback na página, não no plano. Um visualizador que mostra um quadrado cinza com spinner quando o WebGL não está disponível é pior que não ter visualizador, porque o comprador conclui que sua página está quebrada.

O que uma visualização 3D pode e não pode provar

A visualização 3D é um ativo de apresentação: comunica forma, proporção e como as peças se relacionam. Não é registro de medição. O tamanho aparente na tela depende da câmera, do campo de visão e da tela do comprador, então ninguém consegue ler uma cota ali, e o fornecedor não deveria sugerir que sim.

Vale escrever essa frase na própria página. Uma linha — "as dimensões são medidas no produto; a visualização 3D mostra apenas a forma" — evita o mal-entendido mais caro deste fluxo: um comprador que acredita que o modelo é um desenho cotado e compra em cima dele.

Quando a visualização 3D não vale o peso

3D não é a resposta padrão para toda pergunta do comprador, e uma página que carrega todos os formatos é mais lenta do que uma que carrega o certo. Use esta regra.

Se a pergunta é só "qual formato envio", a decisão geralmente fica entre uma visualização 3D e uma sequência de fotos, não entre 3D e nada. A troca envolve peso do arquivo, interação e quanto controle o comprador precisa; visualizador 3D vs fotos 360 cobre essa divisão em detalhe.

Quando o 3D realmente ganha lugar, coloque onde pode ser visto: uma visualização 3D do produto aberta ao lado das medidas, no mesmo cartão que o comprador encaminha para o time dele, rende mais que um visualizador enterrado três cliques dentro de um catálogo.

Perguntas frequentes

Qual tamanho deve ter um modelo 3D de produto para um site?

Menos de 5 MB, e menos de 2 MB se o comprador provavelmente abrir a página no celular. O teto vem da aritmética, não de preferência: a 5 Mbps, um modelo de 5 MB leva 8 segundos até o primeiro quadro, e isso antes de o JavaScript do visualizador rodar. Confira o GLB exportado, não o projeto.

Modelos 3D deixam a página de produto mais lenta?

Sim, normalmente em dois pontos. O download disputa banda com a imagem principal e empurra o Largest Contentful Paint além do limite bom de 2,5 segundos do Google. Depois, o JavaScript do visualizador disputa a thread principal e aproxima a latência de interação do limite de 200 ms de INP. Meça os dois no PageSpeed Insights com o modelo no lugar, não com um placeholder.

Qual é a diferença entre GLB e glTF?

GLB é o contêiner binário; glTF é o formato. Um .gltf é um JSON que aponta para um .bin e arquivos de imagem separados. Um .glb empacota o JSON e o buffer binário num arquivo sem base64, então é uma requisição só e um pouco menor que o JSON equivalente com dados embutidos. Os dois são glTF 2.0 e carregam num visualizador compatível.

Dá para reduzir o tamanho do modelo 3D sem perder a forma?

Sim, em três movimentos: remover texturas e mapas que o material não usa, decimar a geometria até o detalhe que o visualizador consegue mostrar e aplicar Draco na geometria e KTX2/Basis nas texturas. Reconfira a silhueta e a contagem de peças depois de cada passo. O ganho barato quase sempre está nas texturas; o erro caro é decimar uma superfície curva até o perfil deixar de bater com o desenho.

O comprador consegue medir o produto a partir de uma visualização 3D?

Não. A visualização 3D mostra forma e proporção; não certifica uma cota, porque o tamanho aparente depende de câmera, campo de visão e tela. Quem precisa de número deve ler um diagrama de especificações cotado ou um desenho, onde a dimensão está presa ao produto em vez de inferida de um render.

Fontes e referências

• web.dev — Largest Contentful Paint (LCP): limite bom de 2,5 s, ruim acima de 4,0 s, medido no percentil 75
• web.dev — Interaction to Next Paint (INP): limite bom de 200 ms, ruim acima de 500 ms
• HTTP Archive Web Almanac 2024 — capítulo Page Weight: página móvel mediana 2.037 KB, desktop 2.312 KB, imagens móveis ~900 KB
• Khronos Group — especificação glTF 2.0: estrutura do contêiner GLB, buffers binários e a nota de que glTF não é formato de streaming
• Khronos Group — extensão KHR_draco_mesh_compression: geometria comprimida em vez de dados de vértice crus
• Khronos Group — extensão KHR_texture_basisu: texturas KTX2 com supercompressão Basis Universal