Un tamaño de archivo del modelo 3D de 5 MB ya es demasiado para una página de producto que el comprador abre en el celular. El peso que sobrevive en un Android de gama media con una conexión móvil normal ronda los 2 MB, y la razón es aritmética, no de gusto: a 5 Mbps, cada megabyte cuesta 1,6 segundos antes de que el visor pueda dibujar el primer fotograma.
Cuando aceptas ese número, la conversación cambia. Casi todos los proveedores tratan el modelo como material de marketing y el tamaño del archivo como un problema del estudio 3D. El comprador solo ve lo primero que se descarga al abrir la página. Esto es la tabla de presupuesto, los cuatro lugares donde se van los bytes y las seis comprobaciones que conviene hacer antes de pegar un enlace 3D en un correo de cotización.
Tabla de tamaño de archivo del modelo 3D: qué descarga primero el celular
El tiempo de descarga es tamaño × 8 ÷ velocidad de la conexión. La fórmula no incluye renderizado, ni rotación, ni primer fotograma. La tabla supone una conexión estable y no cuenta el saludo TLS ni la latencia de ida y vuelta, así que un celular real siempre tarda más.
| Tamaño del modelo |
10 Mbps |
5 Mbps |
1.6 Mbps |
Qué hace el comprador mientras espera |
| 2 MB |
1,6 s |
3,2 s |
10 s |
Gira el modelo y lee una línea de especificaciones |
| 5 MB |
4 s |
8 s |
25 s |
Pasa de largo o toca la foto estática |
| 10 MB |
8 s |
16 s |
50 s |
Cree que la página está rota |
| 20 MB |
16 s |
32 s |
100 s |
Cierra la pestaña |
| 50 MB |
40 s |
80 s |
250 s |
Nunca llega al modelo |
Lee dos veces la fila de 50 MB. Son 13 segundos incluso con buena conexión de oficina y más de cuatro minutos en la señal débil de un almacén, un showroom o un hotel. Un modelo de ese tamaño no es material de presentación: es una transferencia de archivos que el comprador no aceptó.
El modelo 3D es el único activo de producto donde el comprador descarga el producto completo antes de ver una sola parte. Una foto puede aparecer de arriba hacia abajo; un video arranca tras unos segundos de búfer; un GLB no.
Por qué el modelo completo tiene que llegar antes
La especificación glTF 2.0 dice de forma explícita que no es un formato de streaming: los datos binarios pueden transmitirse en flujo, pero glTF no define ninguna estructura de streaming. Por eso el visor carga el activo, lo analiza y después renderiza. No existe una vista parcial que se parezca al producto.
El contenedor importa. Un GLB empaqueta la descripción JSON de la escena y los búferes binarios en un archivo sin expansión base64: eficiente en una sola petición, pero el comprador espera el paquete completo. Un .gltf separado con su .bin y sus texturas permite al visor pedir piezas por separado y empezar antes, a cambio de más solicitudes y más puntos de falla. Para una tarjeta de producto de un solo SKU, un GLB suele ser lo correcto; para una línea de 60 SKU, compartir archivos divididos suele pesar menos en total.
Nada de esto aparece en el apartado de imágenes de los informes de rendimiento, y por eso pasa desapercibido. El elemento de Largest Contentful Paint en una página de producto suele ser la imagen principal o un bloque de texto, no un lienzo WebGL. La guía de Google sitúa un LCP bueno en 2,5 segundos o menos en el percentil 75. Si el JavaScript del visor y la descarga del modelo compiten por ancho de banda con la imagen principal, la página falla ese umbral mientras el equipo 3D informa que "el modelo se ve bien".
Cuánto pesa ya el resto de la página
Los datos de HTTP Archive 2024 citados en el Web Almanac sitúan la página de escritorio mediana en 2.312 KB y la móvil en 2.037 KB. En móvil, solo las imágenes ocupan unos 900 KB de esa página mediana.
Compara el modelo con esas cifras:
| Activo |
Peso típico |
Frente a la página móvil mediana (2.037 KB) |
| Página móvil completa |
~2 MB |
1× |
| GLB de 2 MB |
2 MB |
Duplica la página |
| GLB de 5 MB |
5 MB |
2,5× la página entera |
| GLB de 20 MB |
20 MB |
10× la página entera |
Así se fija un presupuesto. La vista 3D es un elemento de una página que también carga galería, tabla de especificaciones, reseñas, scripts de analítica y plantilla. Si el modelo solo ya supera la página mediana, el modelo es la página, y el comprador lo paga en segundos.
El clima y el WiFi de una feria empeoran esto, y el dispositivo también. Un celular de gama media de hace tres años decodifica una textura de 4096 píxeles mucho más lento que el portátil con el que se aprobó el archivo. Prueba en el celular, no en el monitor del estudio.
Dónde se van los bytes y qué compresión arregla cada parte
El tamaño del archivo se concentra en tres bloques, normalmente en este orden: texturas, geometría y todo lo demás (animación, cámaras, nodos sobrantes). Sorprende que la geometría no suele ser lo más pesado. Un modelo derivado de fotos con una sola textura PNG de 4096 × 4096 puede pesar más que la malla que envuelve.
| Bloque |
Qué lo infla |
Qué lo reduce de verdad |
| Texturas |
Mapas PNG de 4096 px, normales y rugosidad sin usar, perfiles de color incrustados |
Mapas del tamaño al que el visor los muestra, JPEG o KTX2, eliminar los mapas que el material no usa |
| Geometría |
Mallas escaneadas o subdivididas con millones de triángulos, piezas duplicadas |
Decimación hasta el detalle visible, instancias de piezas repetidas, compresión Draco |
| Todo lo demás |
Clips de animación que nadie reproduce, nodos ocultos, cámaras, luces |
Borrar lo que el visor no necesita; un turntable de producto necesita una cámara |
Dos extensiones ratificadas por Khronos hacen el trabajo de compresión y resuelven problemas distintos. KHR_draco_mesh_compression transmite geometría comprimida en lugar de datos de vértices en bruto. KHR_texture_basisu guarda las texturas como KTX2 con supercompresión Basis Universal, lo que reduce el tamaño de transmisión y la memoria de GPU.
Ambas son extensiones, no parte del glTF básico. El visor tiene que soportarlas y el archivo debe declararlas en extensionsRequired cuando no hay respaldo sin comprimir. Antes de enviar nada, abre el archivo exportado en el visor exacto que usará el comprador: tu tarjeta de producto, tu sitio o el espacio 3D de un marketplace. Que abra en Blender no demuestra nada sobre un navegador de celular.
Seis comprobaciones antes de enviar un enlace de vista 3D
Hazlas en orden. Las dos primeras evitan la mayor parte del daño; las otras cuatro evitan los fallos que terminan en correos de soporte en vez de pedidos.
Comprobación 1: es una exportación web, no un archivo de trabajo
Un .blend o un .step es un documento de autoría: lleva historial, cámaras, materiales y a veces texturas que viven en una carpeta del portátil de alguien. El contenedor web es GLB y la escena debe tener un producto, una cámara y materiales que el visor pueda leer. Si el diálogo de exportación pregunta por "aplicar modificadores" o "incluir objetos ocultos", la respuesta es sí a lo primero y no a lo segundo.
Las fotos de origen importan tanto como la exportación. Un modelo construido con ángulos y luces mezclados muestra esas costuras cuando el comprador lo gira, por la misma razón por la que un set de fotos inconsistente arruina una ficha. Si el set todavía se está armando, empieza por fotos para una vista 3D del producto antes de tocar el exportador.
Comprobación 2: el peso corresponde a la conexión, no al estudio
Abre las propiedades del archivo exportado, lee el tamaño de archivo del modelo 3D en megabytes y compáralo con la tabla de arriba. Hazlo sobre el archivo exportado, nunca sobre el proyecto: un archivo de trabajo de 40 MB puede exportarse a 3 MB, y uno de 3 MB puede salir en 30 MB al empaquetar texturas.
Si se pasa del presupuesto, arregla primero el bloque más grande. Cambiar cuatro mapas PNG de 4096 píxeles por uno o dos JPEG de 1024 suele quitar más peso que cualquier cambio de geometría. Draco y KTX2 vienen después: hacen más pequeño un activo razonable, no convierten en aceptable uno irrazonable.
Comprobación 3: el primer fotograma es una imagen fija, no un lienzo vacío
Carga el visor de forma diferida y muestra una imagen estática, idealmente del mismo ángulo con el que abre el modelo, hasta que el comprador interactúe. Así el lienzo 3D sale de la ruta crítica y la página conserva un candidato real a LCP.
El siguiente fallo habitual es la respuesta al toque. El umbral de Interaction to Next Paint de Google es 200 milisegundos en el percentil 75; por encima de 500 ms es pobre. Un modelo pesado más un motor de física más una pasada de sombras puede empujar el toque-para-girar por encima de esa línea en un celular de gama media, aunque la página cargue rápido.
Comprobación 4: gira con un pulgar
Sostén el celular con una mano y gira el modelo con el pulgar. Si el gesto necesita dos dedos, si el modelo sigue girando al soltar o si el zoom desplaza el centro de rotación, el comprador peleará con el visor en vez de leer el producto.
Prueba también los bordes: arriba, abajo, la parte trasera. Un visor que limita la rotación a ±45 grados esconde justo las superficies que el comprador quiere inspeccionar, las que el estudio nunca fotografía.
Comprobación 5: la forma sigue coincidiendo con el producto
Gira el modelo contra la unidad real y el plano acotado. Mira la silueta, la herrajería, las líneas de unión y el grosor del canto de cada panel. Después mira lo que el comprador va a revisar: bisagras, patas, tiradores, el perfil de una moldura.
Convertir una foto en un activo 3D es un paso de presentación, no de medición. El modelo puede suavizar una curva; no puede inventar un tirador, borrar una junta ni cambiar una proporción que el plano declara. Si el modelo y el plano no coinciden, gana el plano y el modelo se rehace.
Aquí es donde los dos tipos de salida tienen que ser honestos entre sí. El modelo giratorio muestra la forma y cómo se unen las piezas; el diagrama acotado muestra los números. El software que fija las dimensiones medidas sobre la foto y genera el modelo giratorio desde la misma fuente evita que esas dos vistas se separen, y mantiene la cota en la anotación, donde el comprador puede leerla, en vez de dentro del render, donde nadie puede medirla.
Comprobación 6: hay un respaldo para quien no puede verlo
Los portátiles corporativos bloquean WebGL. Algunos navegadores lo desactivan por defecto. Los celulares viejos se quedan sin memoria con texturas grandes. En todos esos casos el comprador debería recibir igual la imagen fija, la tabla de especificaciones y el botón de contacto.
Escribe el respaldo en la página, no en el plan. Un visor que muestra un recuadro gris con un spinner cuando WebGL no está disponible es peor que no tener visor, porque el comprador concluye que tu página está rota.
Qué puede y qué no puede probar una vista 3D
La vista 3D es un activo de presentación: comunica forma, proporción y cómo se relacionan las piezas. No es un registro de medición. El tamaño aparente en pantalla depende de la cámara, el campo de visión y la pantalla del comprador, así que nadie puede leer una cota en ella ni el proveedor debería insinuar que sí.
Vale la pena escribir esa frase en la página. Una línea —"las dimensiones se miden sobre el producto; la vista 3D solo muestra la forma"— evita el malentendido más caro de este flujo: un comprador que cree que el modelo es un plano acotado y pide contra él.
| Pregunta del comprador |
Qué la responde |
Qué no |
| "¿Mide exactamente 1.200 mm de ancho?" |
Un diagrama de especificaciones con la cota sobre la foto |
Un render 3D, por detallado que sea |
| "¿Cómo es la parte trasera?" |
Vista 3D, o un set de fotos traseras |
Una galería solo frontal |
| "¿Entra por mi puerta?" |
El ancho de puerta más la dimensión de empaque más pequeña |
Un modelo que se puede escalar en pantalla |
| "¿Cómo se fija la base?" |
Diagrama de despiece, o una vista 3D con la base separada |
Un render de belleza |
Cuándo una vista 3D no vale su peso
El 3D no es la respuesta por defecto a toda pregunta del comprador, y una página que carga todos los formatos es más lenta que una que carga el correcto. Usa esta regla.
| La pregunta real del comprador |
Activo más liviano que la responde |
Usa 3D cuando |
| "¿Cómo se ve de lado?" |
Secuencia de 360 fotos o un set de cuatro ángulos |
El comprador necesita girar libremente, no pasar fotogramas |
| "¿Cuánto mide?" |
Diagrama acotado con dimensiones sobre la foto |
Nunca: el 3D no responde esto |
| "¿Cómo se desarma?" |
Diagrama de despiece con llamadas numeradas |
La secuencia de armado es el argumento de venta |
| "¿El acabado es el correcto?" |
Fotos macro con iluminación consistente |
Nunca: una textura no es prueba de color |
Si la pregunta es solo "qué formato envío", la decisión suele estar entre una vista 3D y una secuencia de fotos, no entre 3D y nada. El intercambio es peso del archivo, interacción y cuánto control necesita el comprador; visor 3D frente a fotos 360 cubre esa división con más detalle.
Cuando el 3D sí se gana su lugar, ponlo donde se vea: una vista 3D del producto que se abre junto a las medidas, en la misma tarjeta que el comprador reenvía a su equipo, rinde más que un visor enterrado tres clics dentro de un catálogo.
Preguntas frecuentes
¿Qué tamaño debería tener un modelo 3D de producto para una web?
Menos de 5 MB, y menos de 2 MB si es probable que el comprador abra la página en el celular. El techo viene de la aritmética, no de una preferencia: a 5 Mbps, un modelo de 5 MB tarda 8 segundos hasta el primer fotograma, y eso antes de que corra el JavaScript del visor. Revisa el GLB exportado, no el proyecto.
¿Los modelos 3D hacen más lenta una página de producto?
Sí, y normalmente en dos puntos. La descarga compite con la imagen principal por ancho de banda y empuja el Largest Contentful Paint más allá del umbral bueno de 2,5 segundos de Google. Después, el JavaScript del visor compite por el hilo principal y acerca la latencia de interacción al umbral de 200 ms de INP. Mide ambos en PageSpeed Insights con el modelo puesto, no con un marcador de posición.
¿Cuál es la diferencia entre GLB y glTF?
GLB es el contenedor binario; glTF es el formato. Un .gltf es un JSON que apunta a un .bin y a archivos de imagen separados. Un .glb empaqueta el JSON y el búfer binario en un archivo sin base64, así que es una sola petición y algo más pequeño que el JSON equivalente con datos incrustados. Ambos son glTF 2.0 y ambos cargan en un visor compatible.
¿Se puede reducir el tamaño de un modelo 3D sin perder la forma?
Sí, en tres movimientos: eliminar texturas y mapas que el material no usa, decimar la geometría hasta el detalle que el visor puede mostrar y aplicar Draco a la geometría y KTX2/Basis a las texturas. Vuelve a comprobar la silueta y el número de piezas tras cada paso. La ganancia barata casi siempre son las texturas; el error caro es decimar una superficie curva hasta que el perfil deja de coincidir con el plano.
¿Puede un comprador medir un producto desde una vista 3D?
No. Una vista 3D muestra forma y proporción; no puede certificar una cota, porque el tamaño aparente depende de la cámara, el campo de visión y la pantalla. Quien necesita un número debe leer un diagrama de especificaciones acotado o un plano, donde la dimensión está unida al producto en vez de inferida de un render.
Fuentes y referencias
