El elemento model llegó a Safari 27: cuándo conviene embeber 3D en tu página

Safari 27 (17 de septiembre de 2026) trae el elemento <model> a iOS, iPadOS y macOS: por primera vez puedes incrustar un modelo 3D en una página con una etiqueta HTML, sin JavaScript, igual que pones un video. Pero ojo: solo funciona en Safari, la especificación sigue en borrador, y el 3D mal empaquetado rompe justo las métricas que te traen tráfico. La decisión correcta hoy no es "¿3D o no 3D?", sino "¿en qué capa de la página va el 3D y qué le pasa a los otros navegadores?".

Antes de esto, meter 3D en una página significaba cargar una librería (Three.js o el web component <model-viewer> de Google), montar un canvas, gestionar la escena a mano y rezar por el hilo principal. Apple lleva un año con el elemento en visionOS y ahora lo estira al resto de sus plataformas: se declara como <model src="silla.usdz">, o con <source> para USDZ y GLB, y el navegador se encarga del render, la iluminación y la interacción.

Qué cambia exactamente (y qué no)

El elemento model se une a img, video y audio como contenido reemplazado: ocupa un hueco en el layout, respeta el CSS y expone una API de JavaScript (await model.ready, reproducción de animaciones, stagemode="orbit" para el giro tipo carrusel). Safari 27 además permite aplicarle dynamic-range-limit para controlar el tone mapping HDR.

Lo que no cambia: la etiqueta ignora los navegadores sin soporte y muestra lo que haya dentro, el mismo patrón de fallback de <video>:

<model stagemode="orbit" alt="Silla de oficina en cuero marrón">
  <source src="silla.usdz" type="model/vnd.usdz+zip">
  <source src="silla.glb" type="model/gltf-binary">
  <img src="silla-preview.jpg" alt="Silla de oficina en cuero marrón">
</model>

Chrome y Firefox no lo implementan. La especificación vive en el W3C Immersive Web Community Group, sin estado Baseline. En la práctica: tus visitantes de Chrome ven la imagen de respaldo, tus visitantes de iPhone ven el 3D interactivo. Eso es mejora progresiva pura, y es también la trampa — porque la tentación es tratar el 3D como experiencia principal cuando hoy es una capa para una parte de tu tráfico.

El caso de negocio: los números que sí existen

El atractivo comercial no es nuevo. Los proveedores de pipelines 3D para comercio reportan que los listados de Amazon con 3D convierten alrededor de un 9% más que los mismos listados en 2D, que el tráfico orgánico de compras sube un 6% con contenido 3D, y que las fichas de producto con 3D interactivo ven mejoras de conversión del 5-15% según el verticales (datos de VNTANA; consíderalos datos de proveedor, no estudios auditados). Nosotros los hemos visto con la misma cautela en clientes: el 3D funciona cuando el producto se compra con la vista — muebles, indumentaria, equipos — y no mueve la aguja en productos donde la decisión es de precio o compatibilidad.

El impuesto de rendimiento: por qué el 3D mal empaquetado es caro

Aquí es donde casi todos se equivocan. Un GLB sin comprimir trae decenas de megabytes, texturas de 4096px y triángulos de sobra. Shopify recomienda menos de 4 MB por modelo y considera 15 MB el techo absoluto; el presupuesto práctico ronda los 100.000 triángulos y texturas de 2048px. Para ponerlo en perspectiva: en 4G real, 4 MB suponen cerca de 1-2 segundos de descarga antes de que el visor siquiera empiece a decodificar — y la decodificación y la subida de texturas a la GPU competen con el hilo principal justo cuando el usuario intenta hacer scroll.

El paralelismo con video es directo: en nuestro trabajo con video y LCP el patrón se repite — el medio pesado nunca puede estar en el camino crítico de carga. Lo mismo aplica aquí, y por la misma razón lo vemos en nuestras auditorías de datos de campo LCP/INP: lo que descargas antes de tiempo te cobra después.

El framework: tres capas, no una sola decisión

Después de revisar casos reales y el estado del ecosistema, esta es la matriz que usamos para decidir:

Tres reglas que no negociamos:

1. El 3D nunca bloquea el LCP. El GLB se carga bajo demanda (IntersectionObserver o loading="lazy" equivalente en la capa que elijas), después del primer render. El poster o la imagen van primero.
2. Presupuesto duro por activo. Si un modelo supera 4 MB o 100k triángulos, vuelve al artista antes de volver al código. El pipeline de optimización (Draco/Meshopt para geometría, KTX2 para texturas) es parte del entregable, no un extra.
3. Mide por capa. Saber que el 3D convierte un 9% más no te dice nada si el 92% de tu tráfico en Chrome nunca lo ve. Instrumenta la interacción con el visor por navegador antes de cantar victoria.

Por dónde empezar hoy

Si ya tienes assets 3D (CAD de producto, escaneos, modelos de Blender), el elemento <model> es la capa más barata que puedes añadir: una etiqueta, un fallback, cero JS. Si no los tienes, no empieces por aquí — el pipeline de producción de modelos es el trabajo real, y una ficha bien fotografiada con zoom supera a un 3D lento en la mayoría de catálogos.

Lo que sí haría hoy: preparar el markup con el patrón de fallback correcto. Cuando Chrome y Firefox se sumen — y la especificación ya está en borrador avanzado — el cambio será cambiar de capa, no reescribir la ficha. Ese es el verdadero ahorro de la etiqueta nativa: el día que el 3D sea Baseline, tu markup ya estará listo.

Para ver el 3D nativo en acción no hace falta esperar: abre cualquier página con <model> en un iPhone con Safari 27. Y si lo que te interesa es el lado de QA de esta misma versión de Safari, el servidor MCP de Safari para agentes de IA permite probar este tipo de rendering sin salir del editor.

FAQ

¿Reemplaza el elemento model a model-viewer? No todavía. model-viewer sigue siendo la única vía para 3D en Chrome y Firefox, y añade AR en Android. El elemento nativo es la capa superior del stack, no el reemplazo: la secuencia correcta es imagen primero, después model-viewer o model nativo según el navegador — nunca model como única vía.

¿Puede el 3D nativo perjudicar el SEO o las Core Web Vitals? Solo si lo pones en el camino de carga inicial. Un GLB de 10 MB descargado eagerly compite con LCP y con el hilo principal durante la decodificación. Cargado bajo demanda, fuera del primer render, no toca LCP, y la interacción tardía tampoco afecta a INP si la inicialización del visor se hace en idle.

¿Qué formatos acepta el elemento model? USDZ (model/vnd.usdz+zip), el formato de la ecosistema Apple de AR, y GLB (model/gltf-binary), el estándar de facto de glTF para la web. El patrón con múltiples <source> deja que el navegador elija, con <img> al final como contenido de respaldo universal.