Cuántas visitas soporta un hosting compartido y cómo calcularlo

Por qué el total del mes engaña

Treinta mil visitas por mes suenan a mucho, pero repartidas en treinta días son mil por día y unas cuarenta por hora. Un servidor genera una página en una fracción de segundo, así que el promedio casi nunca es el problema.

El problema es que el tráfico no llega parejo. El sitio de una empresa recibe casi todo en horario de oficina; una tienda, a la noche y los domingos; cualquier sitio, en los minutos que siguen a un envío masivo o a una publicación que se comparte. La cuenta útil se hace con la peor hora, no con el mes.

La cuenta en cuatro pasos

Es la ley de Little aplicada a un sitio: los pedidos en curso son iguales a los pedidos por segundo multiplicados por lo que tarda cada uno.

1. Buscá tus páginas vistas en la hora de más tráfico de un día fuerte. En Google Analytics las ves por hora con una exploración; en las estadísticas del panel, en el resumen por horas.
2. Dividí ese número por 3.600 para pasar a páginas por segundo.
3. Medí cuánto tarda el servidor en generar una página, sin contar imágenes ni estilos (más abajo está cómo).
4. Multiplicá las páginas por segundo por ese tiempo. El resultado es cuántas páginas se están armando a la vez, en promedio, en tu peor hora.

Cuatro sitios, cuatro resultados

Mientras el resultado quede muy por debajo de 1, el servidor pasa desocupado la mayor parte del tiempo y los picos se absorben sin que nadie lo note. Cuando se acerca a 1, tu sitio usa el equivalente a un núcleo entero de procesador solo para armar páginas, y en un servidor compartido, donde los recursos se reparten entre muchos sitios aislados entre sí, eso ya es mucho. Por encima, las visitas empiezan a hacer cola.

Son promedios de la hora. Dentro de esa hora hay minutos peores: después de un envío masivo, el pico real puede ser de tres a cinco veces el promedio.

Cómo medir el tiempo que tarda tu servidor

El dato que importa es el tiempo hasta el primer byte: desde que se pide la página hasta que el servidor empieza a mandarla. Desde una terminal de Linux o macOS, corré esto varias veces seguidas:

curl -o /dev/null -s -w "primer byte: %{time_starttransfer} s\n" https://tudominio.com.ar/

• La primera medición puede salir alta porque la caché estaba fría. Mirá las siguientes.
• Para ver cuánto tarda sin la caché de página, agregá algo al final de la dirección, como ?prueba=123: muchos plugins de caché no guardan las direcciones con parámetros.
• Desde el navegador: herramientas para desarrolladores (F12), pestaña Red, recargá y abrí el primer pedido. En la sección de tiempos, la espera de la respuesta del servidor es el mismo dato.
• Con caché, lo esperable es bastante menos de 0,2 s. Si una página sin caché pasa de 1 s, hay algo para arreglar en el sitio antes de pensar en otro plan.

La otra cuenta: cuántos datos salen por día

Los planes de hosting de InHosting no cobran por tráfico y están pensados para un uso de hasta 1 GB de transferencia por día. Para un sitio institucional o un blog alcanza de sobra, pero depende de cuánto pesa cada página, y ahí las imágenes mandan (cómo achicarlas sin que se note).

La primera página que ve alguien baja todo: HTML, estilos, fuentes, scripts e imágenes. Las siguientes pesan mucho menos, porque el navegador ya guardó casi todo. Con esa diferencia se puede estimar:

• Portada de 1 MB y páginas internas de 200 KB: 500 visitantes por día que ven tres páginas cada uno son 500 × (1 + 2 × 0,2) = 700 MB.
• La misma gente con una portada de 4 MB y páginas internas de 500 KB, por fotos subidas tal como salen de la cámara: 500 × (4 + 2 × 0,5) = 2,5 GB. Más del triple, con el mismo contenido.
• Los robots de buscadores y de asistentes de IA también bajan páginas, y en sitios con muchas direcciones pueden sumar una parte importante.

Qué hacer antes de pensar en otro plan

1. Activá una caché de página completa. En WordPress es un plugin; convierte cada visita en la entrega de un archivo ya armado y es, por lejos, lo que más capacidad agrega.
2. Achicá las imágenes al tamaño en que se muestran y pasalas a WebP o AVIF. Baja la transferencia y el tiempo de carga a la vez.
3. Revisá los plugins: cada uno activo corre en cada página que no sale de la caché. Los que no usás, afuera.
4. Reemplazá el cron interno de WordPress, que se dispara con las visitas, por una tarea programada real cada 15 minutos (cómo hacerlo en DirectAdmin).
5. Mirá en las estadísticas qué robots te visitan más. Si alguno que no te trae nada baja miles de páginas por día, frenalo desde robots.txt.
6. En una tienda, dejá sin caché solo lo que tiene que ser dinámico: carrito, pago y cuenta del cliente. El catálogo se puede cachear.

Cuándo el compartido deja de ser el lugar

Hay sitios que, bien optimizados, igual necesitan más: una tienda con muchas compras simultáneas, donde el carrito no se puede cachear; un tiempo de servidor que sigue alto con caché y sin plugins de más; una transferencia que supera lo previsto todos los días y no por un pico; o una aplicación con procesos que corren todo el tiempo, como colas o tareas de fondo.

Ahí el paso es a recursos propios. Las diferencias concretas entre los dos modelos están en hosting compartido o VPS.

Los precios se leen de la tienda. Ver el detalle de cada plan.