Hosting de tours virtuales: servidores, almacenamiento y CDN

Alojar tours virtuales significa mantener el visor, los datos de la escena, los panoramas y los medios de apoyo disponibles en línea para que un visitante pueda explorarlos en un navegador. La experiencia visible puede sentirse como un espacio continuo, pero detrás hay solicitudes para muchos archivos separados y, a veces, respuestas de una aplicación.

Esta explicación separa las funciones de servidores, almacenamiento, ancho de banda y una red de entrega de contenido. También explica cómo SaaS y la entrega autohospedada dividen la responsabilidad. Para instrucciones de instalación en lugar de conceptos de infraestructura, use nuestra guía práctica sobre alojar sus propios tours virtuales.

¿Qué sucede cuando alguien abre un tour virtual?

La URL del tour dirige al navegador a un servicio web. El navegador carga el visor y la información del proyecto, luego solicita las imágenes y los medios necesarios para la escena actual. Según el visor, puede recuperar un panorama completo o mosaicos de imagen más pequeños en diferentes resoluciones a medida que el visitante mira alrededor y hace zoom.

1. El visor se inicia: HTML, scripts y recursos de presentación establecen la experiencia interactiva.
2. El proyecto se carga: Las conexiones entre escenas, las posiciones de los hotspots y la configuración indican al visor qué mostrar.
3. Los medios llegan: Archivos de panorama o mosaicos, planos, audio y video se entregan cuando se solicitan.
4. El navegador renderiza la escena: El dispositivo del visitante decodifica las imágenes y dibuja la vista inmersiva.

Estas etapas explican por qué la velocidad del hosting y el rendimiento del dispositivo son cosas distintas. Un servidor rápido no puede garantizar un renderizado fluido en un teléfono sobrecargado, y un teléfono potente no puede compensar una conexión lenta o descargas innecesariamente grandes.

Servidores: Ejecutar la aplicación y responder solicitudes

Un servidor recibe solicitudes y envía respuestas. Para un tour exportado de forma estática, puede simplemente entregar archivos web existentes. Una plataforma de autoría basada en navegador también puede necesitar un entorno de ejecución de la aplicación y una base de datos para gestionar proyectos, autenticar editores, guardar cambios o procesar cargas.

La carga de trabajo de publicación y la carga de trabajo de visualización son diferentes. Generar mosaicos de imagen o redimensionar panoramas grandes puede consumir CPU y memoria durante la preparación. Servir imágenes ya generadas es en gran medida una tarea de entrega. Añadir CPU puede ayudar en el procesamiento sin resolver el cuello de botella de descarga del visitante.

El origen es la fuente autorizada desde la cual se recuperan archivos o respuestas. Puede ser un servidor web, un servicio de aplicaciones o un servicio de almacenamiento de objetos. Una máquina física no tiene que desempeñar todos los roles, y alquilar infraestructura en la nube aún puede formar parte de una implementación autohospedada.

Almacenamiento: Cuánto contenido conservas

El almacenamiento es la capacidad ocupada por archivos y datos en reposo. Cuenta más que los panoramas fuente: los mosaicos generados, las imágenes de vista previa, los medios de hotspots, los registros de proyectos y las versiones retenidas también ocupan espacio. Las copias de seguridad y los originales de edición pueden vivir por separado, pero todavía necesitan su propio presupuesto de capacidad.

• Almacenamiento en servidor local: Los archivos residen en el almacenamiento conectado al servidor de la aplicación. El espacio disponible y la recuperación dependen de ese entorno de alojamiento.
• Almacenamiento de objetos: Los archivos se almacenan como objetos en un servicio separado. Puede separar el crecimiento de medios de los recursos de la aplicación, siempre que el software admita la disposición.
• Almacenamiento de respaldo: Copias recuperables protegen frente a borrados o fallos. Una segunda copia en vivo o una caché de CDN no son automáticamente una copia de seguridad utilizable.

Como cálculo ilustrativo, 40 proyectos publicados con un promedio de 250 MB cada uno ocupan alrededor de 10 GB usando unidades decimales. Eso excluye copias de seguridad, archivos fuente, la aplicación y versiones adicionales. Mida un proyecto publicado completo en lugar de multiplicar solo los tamaños originales de las fotos. Nuestra guía de formatos de archivo de tours virtuales explica por qué los originales de trabajo y los activos de entrega sirven para propósitos distintos.

Ancho de banda y transferencia: Cuánto contenido reciben los visitantes

Estríctamente, el ancho de banda es la capacidad de una conexión para mover datos a lo largo del tiempo, comúnmente expresada en megabits por segundo. Los planes de alojamiento a menudo usan la misma palabra para una asignación mensual de transferencia, medida en GB o TB. La capacidad afecta cuánto puede moverse a la vez; la transferencia mide cuánto se mueve realmente durante un periodo.

Un tour almacenado no consume la misma cantidad de transferencia en cada visita. Los visitantes pueden abrir una escena o explorar todo; los visores móviles pueden solicitar resoluciones más bajas; los recursos en caché pueden reutilizarse. El video en reproducción automática y la precarga pueden cambiar el total sustancialmente.

Transferencia mensual ilustrativa = visitas × datos promedio entregados por visita. Si 2.000 visitas reciben cada una 30 MB, la entrega a visitantes es aproximadamente 60 GB en unidades decimales. Los 30 MB son una medida supuesta, no un punto de referencia de tours virtuales. No está relacionado con el ejemplo anterior del tamaño total del proyecto almacenado.

Distingue también los totales mensuales de la demanda concurrente. Una campaña que atrae a muchos visitantes a la vez puede tensionar la entrega incluso cuando la transferencia mensual sigue siendo modesta. Verifica cómo un plan trata los límites de transferencia, el rendimiento, el conteo de solicitudes y el uso excedente en lugar de interpretar “ilimitado” como recursos ilimitados.

CDN: Entregar medios en caché más cerca de los visitantes

Una red de entrega de contenido distribuye copias en caché de los activos elegibles a través de ubicaciones de borde. Una solicitud puede ser respondida desde una caché de borde en lugar de recuperar repetidamente la misma imagen desde el origen. Esto puede reducir la latencia de entrega y el tráfico al origen, especialmente para audiencias geográficamente dispersas.

Un fallo de caché aún necesita una búsqueda upstream, por lo que una CDN no elimina la necesidad de un origen funcional. Tampoco hace un panorama pesado más pequeño por sí misma. La optimización de imágenes, las resoluciones apropiadas y un comportamiento de carga sensato siguen siendo partes separadas del rendimiento. Vea la explicación de Cloudflare sobre la entrega por CDN para el modelo subyacente.

Las reglas de caché deben coincidir con el contenido

Los mosaicos de panorama públicos a menudo pueden almacenarse en caché para su reutilización. Las sesiones de editor, las respuestas personalizadas y los tours restringidos requieren reglas que respeten los controles de acceso. Un enlace privado no es suficiente si los medios subyacentes siguen siendo recuperables públicamente. La referencia MDN sobre Cache-Control explica cómo se dirigen los navegadores y las cachés compartidas.

Las actualizaciones también necesitan una estrategia de frescura. Si se reemplaza un panorama mientras su dirección permanece igual, una copia antigua en caché puede seguir siendo visible hasta que caduque o se invalide. Las URL de activos versionadas pueden separar revisiones. La configuración de la CDN debe soportar el comportamiento de publicación de la aplicación en lugar de aplicar una regla única a cada respuesta.

El tráfico al origen y el tráfico de visitantes son independientes

Cuando una caché de borde sirve un archivo, el visitante todavía recibe sus bytes aunque el origen evite enviarlos de nuevo. Lea por separado la facturación del hosting de origen, el almacenamiento y la CDN: la caché puede reducir una línea de transferencia mientras que otro servicio aún cobra por la entrega o las solicitudes. Los ahorros dependen de los términos del proveedor y del comportamiento real de la caché.

SaaS y autohospedado: mismos componentes, diferentes operadores

Ambos enfoques necesitan cómputo, almacenamiento y entrega de red. La diferencia es quién selecciona, opera y paga los componentes, y cómo esos costos y controles se presentan al creador del tour.

• Alojamiento SaaS: El operador de la plataforma gestiona la infraestructura y la aplicación. Su suscripción o plan de uso determina la capacidad disponible, las funciones, el soporte y las condiciones de publicación.
• Entrega autohospedada: Usted elige un entorno de alojamiento compatible y organiza la operación usted mismo o a través de un proveedor gestionado. Las facturas de infraestructura permanecen separadas de la licencia del software.
• Alojamiento gestionado: Un socio de hosting puede encargarse de tareas de servidor especificadas sin convertir el software del tour en SaaS. El acuerdo de servicio define si las actualizaciones de la aplicación, las copias de seguridad y la recuperación están incluidas.

Ninguna etiqueta garantiza velocidad, portabilidad o menor coste total. Un servicio SaaS puede usar una CDN, y una plataforma autohospedada puede ejecutarse en servidores en la nube alquilados. Compare el acceso a la exportación, el control del dominio, las reglas de capacidad y las responsabilidades asignadas. Nuestra comparación de autohospedado frente a cloud aborda la decisión empresarial más amplia.

Lea las especificaciones de hosting según el problema que resuelven

• Las cargas fallan o el procesamiento se detiene: Investigue los límites de carga, la configuración de tiempo de ejecución, la memoria disponible, la CPU y el almacenamiento libre.
• La primera escena se carga lentamente: Examine el tiempo de respuesta, el tamaño del activo inicial, la distancia de la red y la conexión del visitante.
• La navegación provoca largas esperas: Examine las cargas de escena, las solicitudes de mosaicos, la precarga y el comportamiento de caché.
• Un lanzamiento concurrido causa errores: Examine las solicitudes concurrentes, la capacidad de la aplicación, la carga del origen y los límites de entrega.
• Las imágenes antiguas permanecen después de una actualización: Examine las cachés del navegador y de la CDN, las versiones de los activos y la invalidación.

Comience con un tour representativo y observe las solicitudes de red del navegador junto con los informes de uso del hosting. Separe los bytes entregados, los retrasos de respuesta y los problemas de renderizado. Esa distinción hace que una especificación de hosting sea útil: conecta cada recurso a una parte observable de la experiencia del visitante.

Preguntas frecuentes

¿El hosting de tours virtuales es lo mismo que almacenar fotos 360?

No. El almacenamiento conserva los archivos, mientras que el hosting también pone el visor, la información del proyecto y los servicios requeridos a disposición de los visitantes. Una carpeta de panoramas por sí sola no proporciona escenas conectadas ni navegación interactiva.

¿Cada visita descarga todo el tour?

No. La cantidad depende de la estrategia de carga del visor, las escenas exploradas, las resoluciones solicitadas, la reproducción de medios y la caché. Use la entrega medida por visita en lugar del tamaño total del proyecto para estimar el tráfico.

¿Todo tour virtual necesita una CDN?

No. Un tour pequeño que sirva a una audiencia cercana puede funcionar adecuadamente desde su origen. Una CDN se vuelve útil cuando la distancia de la red, las solicitudes repetidas de activos o la distribución del tráfico lo justifican; confirme el beneficio con pruebas reales de carga.

¿Autohospedado significa que el servidor debe estar en mi oficina?

No. Describe el control del despliegue. El hosting alquilado, los servidores gestionados y las cuentas en la nube pueden soportar software autohospedado cuando cumplen sus requisitos técnicos.

¿Embebiendo un tour se traslada su alojamiento a mi sitio web?

No. Un visor embebido normalmente sigue cargando desde su servicio original, y sus medios continúan siendo entregados por los hosts configurados. Un embed cambia dónde aparece el tour, no automáticamente dónde viven su aplicación y sus activos.

Entienda la cadena de entrega antes de comparar planes

Un enfoque fiable para alojar tours virtuales comienza separando cuatro preguntas: qué ejecuta la aplicación, dónde se guardan los archivos, cuánto datos reciben los visitantes y dónde se entregan las copias reutilizables. SaaS agrupa esas decisiones en un servicio; el autohospedaje le permite organizarlas con sus propios proveedores. Ajuste los recursos a las cargas de trabajo reales en lugar de asumir que una cifra de almacenamiento principal describe toda la experiencia.

Simple Virtual Tour ofrece una forma autohospedada de crear, gestionar y publicar tours interactivos. Explore la demostración en vivo para ver la experiencia del visitante, o revise los paquetes disponibles al planear su propio despliegue.