Un recorrido puede verse excelente en una computadora potente y resultar difícil de utilizar en un teléfono. Importan la descarga, la memoria gráfica, la pantalla y los controles táctiles. Un encargo móvil práctico define primero qué debe seguir siendo útil y después justifica y prueba el detalle visual adicional.
Define la tarea y los dispositivos de destino
Comienza con una tarea, antes de prometer cuadros por segundo. En un desarrollo conceptual, la persona podría abrir la vista general, elegir un edificio, revisar su entrada y solicitar una cotización. Estas acciones deben entenderse en una pantalla pequeña, aunque el interior detallado sea opcional. Identifica los dispositivos menos potentes que importan a tu audiencia, además de probar un teléfono reciente de gama alta.
Considera también la situación. Un posible cliente puede abrir el enlace con datos móviles entre reuniones y tener poca paciencia ante un lienzo vacío sin explicación. Mantén disponibles la descripción del servicio, el contacto y una vista estática mientras se prepara el visor. Una página útil comunica su propósito incluso cuando la persona decide no iniciar la escena interactiva.
Separa la primera vista de la exploración detallada
La pantalla inicial pocas veces necesita todos los objetos interiores y las texturas del proyecto. Empieza con la escena mínima que responda la pregunta general. Carga información adicional cuando la persona seleccione un edificio o entre en otra vista. Es un principio de planeación, no un tamaño universal de archivo: cada proyecto y audiencia justifican presupuestos distintos.
Khronos describe glTF como un formato de distribución pensado para transmitir y cargar contenido 3D eficientemente. Elegirlo ayuda al proceso, pero no vuelve ligero automáticamente un modelo grande. Hay que revisar geometría, texturas, materiales y dependencias. Pregunta qué se descarga al principio, qué se reserva para después y qué explicación visual permanece disponible si el recurso detallado tarda más de lo esperado.
Invierte detalle donde la cámara lo necesite
Una manija que ocupa dos píxeles en la vista de manzana no necesita el mismo tratamiento que una junta de material mostrada de cerca. Usa la distancia prevista de observación para decidir qué modelado aporta valor. Revisa objetos repetidos, geometría oculta y texturas sobredimensionadas. Conserva la fuente autorizada del diseño y prepara por separado el modelo destinado a presentación.
La resolución también tiene un costo. La guía de diseño adaptable de Three.js distingue el tamaño visible del lienzo de su resolución de renderizado y explica cómo ajustar las proporciones de la cámara. Una pantalla muy densa puede pedir mucho más trabajo gráfico del que su tamaño físico sugiere. Limitar deliberadamente la resolución u ofrecer menor detalle puede producir una experiencia más cómoda que intentar la máxima calidad en todos los equipos.
Planea el renderizado y las situaciones de fallo
Una escena estática no siempre necesita dibujarse continuamente. Three.js muestra cómo renderizar cuando cambian la cámara, los datos o la escena, evitando trabajo innecesario mientras el visor está quieto. Las animaciones, la suavización del movimiento y las cargas posteriores requieren actualizaciones cuidadosas. La estrategia adecuada depende de la experiencia, en vez de imponer que todas las escenas permanezcan animadas.
MDN recomienda presupuestar la memoria gráfica con prudencia, administrar recursos y atender la pérdida del contexto WebGL. Para la persona, esto significa tener una salida comprensible si los gráficos no están disponibles o fallan. Conserva una vista estática, una descripción y el enlace de consulta. Evita indicadores interminables que no permitan saber si la escena sigue cargando o conviene continuar de otra manera.
Utiliza una matriz de aceptación con tareas reales
La matriz siguiente describe un plan hipotético, no resultados medidos de una web específica. Elige dispositivos, navegadores y condiciones de red reales y registra qué ocurrió. Prueba tanto una visita nueva como una repetida: una segunda carga rápida puede ocultar problemas para quienes llegan por primera vez.
Pide completar la misma tarea arquitectónica en cada equipo. Observa controles superpuestos, claridad de orientación y posibilidad de desplazar la página normalmente. Prueba también que el visor no cargue. Una alternativa estática sirve cuando explica suficientemente el proyecto y permite continuar al contacto. Resuelve el fallo que más afecta a la persona antes de añadir otro efecto decorativo.
| Condición | Tarea | Evidencia que registrar |
|---|---|---|
| Teléfono medio con datos móviles | Abrir la vista y seleccionar el acceso | Tiempo hasta información útil; mensajes; precisión táctil |
| Tableta vertical y horizontal | Cambiar vistas y restablecer | Controles; orientación; proporciones del lienzo |
| Escritorio con teclado | Explorar vistas y abrir el formulario | Foco visible; nombres; acceso por teclado |
| Gráficos no disponibles | Entender la propuesta y continuar | Vista estática; descripción; acceso al contacto |
Entrega información útil antes del detalle opcional
- Página y vista legibles
- La persona decide explorar
- Carga la escena necesaria
- Ajusta el detalle al equipo
- Completa la tarea espacial
- Continúa al formulario
Mide por separado la página y el visor
Core Web Vitals ofrece medidas útiles de la página. Sus objetivos actuales de buena experiencia son Largest Contentful Paint dentro de 2.5 segundos, Interaction to Next Paint de 200 milisegundos o menos y Cumulative Layout Shift de 0.1 o menos, evaluados en el percentil 75. Describen carga, respuesta y estabilidad en visitas reales; una prueba local aislada no establece ese rendimiento de campo.
La experiencia 3D necesita observación específica. ¿Se selecciona el edificio correcto? ¿La cámara se detiene donde se espera? ¿Se comprende la alternativa estática? Guarda las notas junto con la versión publicada y repite las pruebas afectadas al incorporar recursos pesados o cambiar navegación. El rendimiento es una decisión continua de diseño: conserva una explicación arquitectónica clara antes de consumir más recursos del dispositivo en detalle adicional.
Ideas para llevarte de esta guía
- Define la tarea móvil esencial y los equipos previstos.
- Mantén una explicación legible y una vista estática.
- Separa los recursos iniciales de las escenas opcionales.
- Revisa geometría, texturas y resolución de renderizado.
- Prueba teclado, tacto, orientación y fallo gráfico.
- Registra resultados medidos en vez de prometer velocidad universal.
Un recorrido preparado para móvil explica la arquitectura en condiciones realistas. Carga, detalle, controles y alternativa estática forman una misma experiencia.
Fuentes y lecturas
- Khronos Group — glTF Runtime 3D Asset Delivery ↗
- Three.js — Responsive Design ↗
- Three.js — Rendering on Demand ↗
- Google web.dev — Web Vitals ↗
- MDN — WebGL best practices ↗
Guía editorial original con ejemplos hipotéticos. La documentación de los productos y los archivos aprobados del proyecto definen las capacidades y el alcance reales.
