¿El 3D te va a ralentizar la tienda? Los números, incluido el incómodo

La respuesta corta, con el número incómodo por delante

La objeción llega siempre igual: "el 3D me va a hundir la tienda". Van los números medidos, incluido el que no nos favorece. El modelo de nuestra demo, una mesa, pesa 257 KB en GLB (263.668 bytes), con 4.861 triángulos, 5.675 vértices, un material y cuatro texturas WebP. La versión USDZ para iOS ocupa 377 KB, validada con usdchecker en modo ARKit. Menos que la galería de fotos de una ficha de sofá normal.

Para seguir: Los pesos que permite Shopify y los que conviene servir.

El problema no es el modelo. Es la librería que lo pinta: el fichero model-viewer.min.js que servimos pesa 913 KB. Casi cuatro veces el modelo. Es el número que casi ningún proveedor de 3D enseña.

Qué mide Google y con qué umbrales

Antes de discutir si 913 KB son muchos, hay que saber contra qué se miden. Google no mide la media, sino la cola: para dar por bueno un umbral pide cumplirlo en al menos el 75 % de las visitas a la página. O sea que lo que cuenta es cómo lo vive el usuario con peor suerte de cada cuatro.

De INP, web.dev publica los tres tramos: bueno hasta 200 ms, "necesita mejorar" por encima de 200 y hasta 500, y malo por encima de 500. De LCP y CLS solo hemos verificado el umbral de "bueno", así que no inventamos los otros dos.

Sobre el SEO conviene bajar el volumen. Google dice que las Core Web Vitals se usan en sus sistemas de ranking, pero también que no hay una señal única y que Search muestra el contenido más relevante aunque la experiencia de página sea mediocre. Una ficha lenta no te borra, pero cuando hay diez igual de relevantes, resta.

Un script diferido no bloquea el pintado

web.dev define el recurso que bloquea el analizador de HTML como "un elemento script sin async ni defer". Ahí está toda la diferencia: los scripts con async se ejecutan en cuanto se descargan y los que llevan defer cuando termina el análisis del documento, así que ninguno frena el pintado.

Traducido a tu ficha: el visor no viaja con la página. El bloque muestra un póster (una imagen estática del producto) y no toca ni la librería ni el modelo hasta que hace falta. La documentación de model-viewer lo dice: el valor por defecto del atributo de carga equivale a "lazy", que carga el modelo cuando está cerca del viewport, y el póster sirve para "mostrar al usuario algo antes de que el modelo esté cargado y listo para renderizar".

Es el criterio que Google da para imágenes: carga diferida solo fuera del viewport inicial, nunca en la imagen que sea el LCP. Por eso la primera foto se carga a la brava y el 3D espera. Quien no toca el 3D no descarga ni los 913 KB ni los 257 KB, y en nuestro embudo se ve: hay un ar_page_view por cada ficha vista, pero solo hay ar_open cuando alguien abre el visor.

Dónde se paga de verdad: INP, no LCP

Que no bloquee el pintado no significa que sea gratis. Al ejecutarse ocupa el hilo principal. web.dev llama tarea larga a cualquiera que pase de 50 milisegundos, y recuerda que el navegador bloquea las interacciones mientras una tarea se ejecuta. Si el usuario toca "añadir al carrito" cuando arranca el motor 3D, esa espera se la come el INP.

Y hay una trampa que también hay que contar: web.dev advierte de que las imágenes se pintan en el hilo principal, así que cualquier cosa que lo bloquee puede alargar el renderizado del elemento LCP aunque no bloquee el analizador. Un visor que arranca en la carga inicial sí empeora el LCP de forma indirecta.

En laboratorio lo delata el TBT, que web.dev describe como un proxy razonable del INP pero no un sustituto, con un objetivo por debajo de 200 ms en hardware móvil medio.

Cómo lo compruebas tú, paso a paso

1. Elige dos URL públicas: una ficha con 3D y otra equivalente sin 3D, mismo tema y mismas fotos.
2. Abre pagespeed.web.dev, pega la primera y quédate en la pestaña de móvil.
3. Mira primero los datos de usuarios reales: PageSpeed Insights los saca del informe de experiencia de usuario de Chrome, en periodos de 28 días. Una ficha nueva no tendrá nada ahí.
4. Baja a los datos de laboratorio (Lighthouse) y apunta LCP, CLS y TBT. Lighthouse también está en el panel de Chrome DevTools y en línea de comandos.
5. Compara. Si la diferencia de TBT y LCP entre ambas es ruido, el visor está bien integrado.
6. Remata en DevTools, pestaña Red, filtro JS, caché vacía y sin tocar el visor. Si la librería aparece en la carga inicial, no está diferida: ahí tienes el problema.

Cuándo sí te va a doler

Todo lo anterior asume una integración decente. Cuando el 3D sí estropea los números:

• El script en el layout general. Si el visor se mete en theme.liquid, la home y las colecciones pagan la librería sin enseñar ni un modelo.
• Sin póster y sin carga diferida. Un visor que arranca solo descarga librería y modelo a todo el mundo, incluido el que no va a girar nada.
• Un bloque que no reserva altura. El visor aparece, empuja el botón de comprar hacia abajo y te llevas el CLS.
• Modelos sin optimizar. Un GLB de 40 MB exportado directo del software de producto no lo salva ninguna carga diferida.
• Un tema que ya va justo. Si arrastras seis apps con sus scripts y un INP en rojo, el 3D no es tu prioridad.

Si tu ficha ya está en rojo sin 3D, meter 3D no la va a arreglar, y encima te va a servir de excusa para no mirar la causa real.

El presupuesto de peso que nos ponemos

Que Shopify acepte 500 MB no significa que debas acercarte: la optimización automática solo entra por encima de 15 MB, así que un modelo de 12 MB pasa tal cual y se lo come el móvil de tu cliente.

Qué hacer con esto

La pregunta útil no es "cuánto pesa" sino "cuánto pesa para quien no lo usa". Con carga diferida, póster y altura reservada, cero. Para quien sí lo abre: 257 KB de modelo y una librería de 913 KB que se descarga una vez y se queda en caché.

Para seguir: la guía de realidad aumentada en ecommerce, cómo se añade 3D a Shopify y la lista de catálogos candidatos. Y antes de discutir milisegundos, la demo y el visor 3D.