Es un texto tranquilizador en un embudo de ventas, no una garantía técnica. Cuando un proveedor imprime "ilimitado" en la tarjeta del plan, no está prometiendo transferencia infinita a través de la física y los presupuestos; está prometiendo no medir un artículo específico en tu factura mientras controla todo lo demás que realmente determina si tu sitio permanece rápido y accesible. La verdad práctica es simple y un poco irritante: tu plan puede no medir la transferencia mensual, pero absolutamente te medirá de otras maneras en el momento en que tu uso parezca inusual, irregular o costoso de proporcionar.
He visto esto suceder suficientes veces como para identificar el patrón desde el primer hilo de soporte. El sitio comienza fuerte, los rankings suben, una campaña tiene éxito, y entonces el plan "ilimitado" desarrolla una personalidad. Las solicitudes tardan más. Los activos estáticos se arrastran. Los trabajadores se acumulan. Aparecen errores en áreas porque el proveedor comienza a proteger el entorno compartido, no tu éxito. Eso no es malicia; es una realidad económica. Los proveedores venden "ilimitado" para atraer a pequeños sitios cuyo uso real es pequeño y predecible. Las excepciones—video, descargas, APIs públicas, aplicaciones mal almacenadas en caché—se convierten en "abuso" en el momento en que los gráficos se mueven. Se activan los Términos de Servicio y los programadores de recursos. Si compraste "ilimitado" esperando que la pista de despegue escale, te sentirás sorprendido. Si lo tratas como no medido en papel pero muy medido en la práctica, tomarás decisiones de arquitectura más inteligentes y evitarás el correo electrónico de suspensión que siempre llega en el momento menos conveniente.
El ancho de banda, la transferencia, el rendimiento y la velocidad del puerto no son lo mismo
No me importa cuántas veces la industria difumine los términos; si vamos a ser honestos sobre lo que realmente puedes impulsar, necesitamos separar el vocabulario. El ancho de banda es el tamaño del tubo en un momento dado. El rendimiento es lo que realmente logras a través de ese tubo después de la sobrecarga, la contención y la limitación. La transferencia de datos es la cantidad total movida durante un período, generalmente un mes. La velocidad del puerto es el límite máximo del flujo instantáneo, típicamente expresado como 10 Mbps, 100 Mbps, 1 Gbps o más.
"Sin medir" es una promesa de facturación sobre la transferencia mensual, no sobre la tasa instantánea que obtienen tus paquetes al mediodía del lunes. "Ilimitado" es un toque de marketing que implica que no hay límite, pero lo que realmente tienes es un plan que no cuenta gigabytes por exceso mientras aplica límites a través de todo lo demás: participaciones de CPU, I/O, conteos de procesos, concurrencia de conexiones y, en última instancia, el puerto que deben atravesar tus paquetes. Un puerto de 1 Gbps puede, en teoría, mover una cantidad masiva en un mes, pero si el host ajusta tu puerto a 100 Mbps después de cinco minutos de rendimiento sostenido, o simplemente te da un carril "bursátil" que disminuye bajo carga, tu transferencia teórica se evapora en tiempo de espera real y solicitudes fallidas. El tubo que pensabas que compraste es el tubo que ocupas solo cuando estás en silencio.
Cuando reviso un plan, no pregunto "¿Es ilimitado el ancho de banda?" Hago una pregunta diferente, más fea: "¿Cuál es el peor rendimiento instantáneo garantizado cuando los vecinos y yo estamos ocupados?" Ese es el número que evita que tu proceso de pago se detenga, que tus imágenes se ralenticen y que tus trabajos en segundo plano construyan una pista de reintentos por la que pagarás más tarde.
Cómo el alojamiento compartido está diseñado para parecer ilimitado (hasta que no lo es)
El alojamiento compartido es un truco de carnaval basado en promedios. La mayoría de los sitios son pequeños. La mayor parte del tráfico es explosivo de formas amigables. La mayoría de las páginas se almacenan en caché después del primer rastreo. Así es como los hosts pueden sobre suscribir computación, memoria, almacenamiento de E/S y vías de red, mientras siguen sirviendo paneles de control alegres a miles de clientes. La maquinaria detrás de esta ilusión es un nido de planificadores de participación justa y sistemas de cuotas. Las participaciones de CPU evitan que una sola cuenta tome un núcleo completo durante mucho tiempo. La configuración de IOPS evita que los vecinos ruidosos hambrientos dejen sin recursos al SAN. Los límites de procesos de PHP-FPM y Node garantizan que solo un puñado de solicitudes puedan ejecutarse dinámicamente a la vez. Los techos de inodos limitan silenciosamente la cantidad de archivos que puedes mantener en el disco, estrangulando sitios con muchos medios antes de que la transferencia siquiera aparezca en un gráfico.
Lo crítico de notar es que ninguno de estos sistemas toca el elemento de "ancho de banda". Eso permanece sin medir, por lo que la afirmación sigue siendo técnicamente honesta. En el momento en que tu aplicación comienza a verse ocupada por más de un momento, las reglas de participación justa imponen el "uso típico" al estrangular las partes de tu pila que controlan. Verás las solicitudes dinámicas en cola mientras los activos estáticos se sienten bien. Luego, los activos estáticos se ralentizan porque el origen se convierte en el cuello de botella que un CDN no puede enmascarar completamente. El host aún no te está cobrando por la transferencia. Simplemente te están haciendo usar menos reduciendo la velocidad con la que puedes servirla.
No creo que los hosts compartidos sean villanos por esto. El modelo funciona para la gran mayoría de los sitios web, y ha mantenido la web económica para los pequeños editores. Pero la frase "ancho de banda ilimitado" da el modelo mental equivocado. Te invita a arquitectar como si tuvieras un carril dedicado, y no lo tienes. Tienes permiso para verter agua en un balde sin pagar por litro, pero aún compartes el grifo.
La letra pequeña que realmente gobierna tu uso
Si quieres la verdad, no leas la tabla de precios; lee la Política de Uso Aceptable. Encontrarás frases azucaradas como "sitios web típicos" y "uso justo", que se traducen como "si comienzas a parecer un nodo de intercambio de archivos, un sitio de transmisión, un espejo de medios, o un centro de descargas, nos reservamos el derecho de estrangular, migrar o suspenderte." Encontrarás prohibiciones sobre la transmisión de audio y video desde el origen, distribución de archivos a escala, archivos de respaldo almacenados en espacio web, colecciones ZIP accesibles públicamente, y scripts "intensivos en recursos" que se ejecutan durante más de unos pocos segundos cada uno. Encontrarás límites diarios de segundos de CPU, techos de consultas de base de datos, y conteo de conexiones que hacen que tu rastreador asíncrono favorito parezca un ataque.
Los límites de procesos de entrada son especialmente engañosos. En entornos estilo cPanel, un "proceso de entrada" a menudo significa "el número de solicitudes dinámicas concurrentes permitidas para comenzar." Alcanzar ese techo y el siguiente visitante no hace cola; reciben errores. Los límites de E/S y los números de IOPS hacen lo mismo con el disco. Los límites de inodos te cortan cuando tienes "demasiados archivos," lo que las bibliotecas de medios ambiciosas tropiezan antes de tocar el rendimiento. Ninguna de estas cosas viola "ancho de banda ilimitado." Solo aseguran que uses muy poco de él cuando tu sitio comienza a crecer.
He perdido la cuenta de los planes que afirman ser "ilimitados" mientras silenciosamente establecen la CPU en "100% de un núcleo por unos segundos", E/S en "unos pocos megabytes por segundo sostenidos," y procesos en "un puñado a la vez." Eso es un cinturón, tirantes y una cuerda. Si alcanzas los tres, no estás corriendo; estás arrastrándote.
Cómo se ve lo "ilimitado" en un lunes ocupado
Imagina un lunes normal después de que una mención el fin de semana te envía nueva atención. Tu HTML es razonablemente ligero, tus imágenes son decentes, te apoyas en un CDN para activos estáticos y tu origen maneja las partes dinámicas. El tráfico se incrementa por un factor de cinco. Al principio, todo está bien porque las cachés están calientes y el CDN consume la mayoría de las solicitudes de imágenes. Luego tus puntos finales dinámicos se atrasan. El límite de procesos del host mantiene solo un pequeño número de trabajadores concurrentes de PHP o Node activos. Comienza la espera en cola, y los tiempos de respuesta se alargan lo suficiente como para romper los tiempos de espera entre servicios. El CDN aún ayuda, pero los fallos de caché en el HTML comienzan a afectar. Tu base de datos se vuelve más habladora, y el planificador de I/O resta otra porción porque ahora eres "intensivo en recursos". Tus clientes, con un tiempo perfecto, hacen clic en imágenes que no estaban calientes en el CDN, sacando ráfagas del origen que chocan con el trabajo dinámico lento.
Lo que sucede a continuación depende del host. Algunos hosts te limitan progresivamente hasta que el rendimiento es tan malo que los visitantes se rinden y tu "promedio" vuelve a la normalidad. Otros activan reglas automáticas de abuso y mueven tu cuenta a un grupo de menor categoría o una VLAN en cuarentena. Algunos todavía lanzan la clásica respuesta 509, "Límite de ancho de banda excedido", aunque no estén contando bytes—509 es solo una señal de alto útil para ganar tiempo mientras revisan. El resultado se siente idéntico: la promesa de "ilimitado" se evapora exactamente cuando lo necesitas.
Un sitio que sirve principalmente HTML en caché y activos estáticos podría cojeando con visitantes frustrados. Una tienda con mucho carrito o una aplicación con mucha búsqueda lo recibirá de lleno. El dolor rara vez se presenta como una métrica única y ordenada. Es un mosaico de pequeñas desaceleraciones que se acumulan en compras fallidas y aumento de abandonos.
Antes de profundizar, quiero hacer algo concreto y reutilizable para que puedas ver el techo práctico incluso cuando un plan afirma que no existe.
Voy a entrar en números concretos por unos minutos. Esta es una Sección Premium enfocada directamente en las matemáticas que puedes hacer en una servilleta para traducir la velocidad de puerto en transferencia mensual y luego en vistas de página. Si alguna vez has luchado para mapear "1 Gbps sin medir" en "¿Cuántas visitas puedo realmente servir?" aquí es donde se aclara.
Premium content
Inicia sesión para continuar
Los asesinos silenciosos: limitación de CPU, modelado de IOPS y límites de procesos
Si alguna vez has sentido que un sitio se ralentiza mientras que los gráficos se ven "normales", has conocido a los asesinos silenciosos. La limitación de CPU es la más visible cuando sabes dónde mirar. Los hosts compartidos asignan una porción de un núcleo para ráfagas y luego te reducen bajo carga sostenida. Tu aplicación no se bloquea; se arrastra. Eso es suficiente para derribar los rankings de búsqueda y las tasas de conversión sin activar alarmas que involucrarían al soporte.
El modelado de IOPS es más sutil. Las bases de datos viven y mueren por la latencia de almacenamiento. Las aplicaciones pesadas en archivos también. Los hosts utilizan cgroups y QoS de almacenamiento para evitar que los grandes consumidores agoten el arreglo. No ves un error; ves un tiempo de espera de disco de veinte milisegundos convertirse en ochenta, lo que lleva los tiempos de solicitud a una nueva y más fea distribución. Combina eso con un límite de procesos de entrada bajo y has creado una caja de compresión perfecta. Las solicitudes tardan más, por lo que más solicitudes son concurrentes, lo que alcanza el límite más pronto, dejando caer a nuevos visitantes al suelo.
Los límites de procesos, finalmente, son la guillotina. Muchos planes limitan PHP-FPM o similar a un puñado de procesos hijo. Algunos añaden un límite al total de procesos concurrentes por usuario. Ambos permiten a un host sonreír y prometer "ancho de banda ilimitado" mientras se asegura de que no puedas, en la práctica, enviar mucho. Si alguna vez has perseguido un cuello de botella fantasma en el CDN o en el código de tu aplicación solo para descubrir que el host permite ocho trabajadores y lo llama un día, has sentido la trampa.
No pongo "ancho de banda ilimitado" en mi registro de riesgos como un problema a solucionar. Reduzco mi dependencia de ello. El modelo que funciona para la mayoría de los sitios pequeños y medianos es aburrido y efectivo. Almacena en caché HTML en el borde tanto tiempo como tu contenido lo permita. Envía imágenes, CSS y JS a un CDN que realmente valides en producción con una alta tasa de aciertos, no solo un logo. Descarga medios pesados a un almacenamiento de objetos y apunta tu CDN allí para que el origen nunca lo vea. Mantén el origen enfocado en lecturas y escrituras dinámicas que realmente necesiten computación, y hazlas lo más sin estado y rápidas posible.
Cuando haces eso, el plan de "ancho de banda ilimitado" se vuelve aceptable porque no le pides que lleve la carga que no puede llevar sin drama. Incluso si el host modela tu origen, el CDN absorbe la naturaleza aleatoria del tráfico. Tu p95 se estabiliza, y compras tiempo para elegir un movimiento cuando el crecimiento es real en lugar de reaccionar durante una interrupción. Toda la letra pequeña aún existe, pero no estás pisándola. Has construido un origen pequeño y ágil en lugar de un almacén.
Nunca pongo transmisión de video, descargas de archivos, espejos de software públicos o distribución de copias de seguridad en un plan que diga "ilimitado". Lo digo como alguien que ha intentado apretarlos y luego ha negociado con el lenguaje de los ToS después del hecho. Estos trabajos no son para lo que está construido el alojamiento compartido, y el host te cerrará en nombre de proteger a todos los demás. Incluso si te sales con la tuya brevemente, estás a una mención de distancia de páginas de correos electrónicos enojados y una migración a medianoche.
Los archivos ZIP pesados de activos de productos o materiales de aprendizaje activarán las mismas alarmas. Las API públicas que fomentan el sondeo por parte de los clientes también lo harán. Y cualquier cosa que fomente a los usuarios a recuperar el mismo archivo de varios megabytes repetidamente en conexiones nuevas impactará el modelado de puertos más rápido de lo que piensas. El hilo que conecta estos casos es simple: son trabajos de alta salida y bajo cómputo que atacan la factura de tránsito del host sin consumir la CPU o I/O que sus planificadores están afinados para medir. Esa disparidad es exactamente por qué "ancho de banda ilimitado" existe como frase. Es una promesa suave construida para ser revocada en el instante en que tu uso deja de parecerse a un pequeño blog.
Quiero darte una guía de traducción de abogado con puntos de referencia que puedas mantener. La próxima sección es una Sección Premium donde traduzco las cláusulas más comunes que usan los hosts en realidad operativa. Si no lees nada más, lee esto cuando estés revisando un plan a la 1 a.m. y te preguntes si "ilimitado" soportará tu próximo lanzamiento.
Premium content
Inicia sesión para continuar
Monitorear lo que importa para saber antes de que llegue el correo de suspensión
El panel de control que te da tu anfitrión no te advertirá sobre el fallo que se avecina. Informará promedios y totales mientras el dolor se esconde en la larga cola. Yo observo diferentes señales. La salida de origen frente a la salida de CDN me dice si mi caché está haciendo su trabajo. Si la salida de origen sube más rápido que las visitas, sé que algo se está omitiendo o purgando de manera demasiado agresiva. La concurrencia de conexiones es el canario para los límites de procesos; si las conexiones concurrentes se acercan a un techo plano, espero errores inmediatos para los nuevos visitantes. El ancho de banda del percentil 95 y el tiempo de solicitud importan más que los promedios porque predicen las partes del día donde el anfitrión te modelará y tus usuarios no completarán un recorrido.
El tiempo de robo de CPU es una prueba de olor de entorno compartido. Si veo que el robo sube durante mis horas tranquilas, sé que estoy compitiendo con vecinos y que mi ráfaga aterrizará en un nodo cansado. Las consultas lentas siempre valen el tiempo que crees que no tienes; arreglar un índice malo puede ser la diferencia entre sobrevivir a una mención y pasar un día disculpándote. Los presupuestos de errores—el número de errores que permites en una ventana antes de considerar que la experiencia del usuario se ha degradado—atan todo esto. Si tus errores aumentan antes que el tráfico, tienes fricción invisible, y "ilimitado" no amortiguará nada.
Sigue el dinero y la historia deja de ser misteriosa. El tránsito es caro si no puedes negociar un buen emparejamiento y si tus usuarios están lejos de tus POP. El alojamiento compartido amortiza ese costo entre miles de cuentas, la mayoría de las cuales apenas usan nada. "Ilimitado" es una herramienta de adquisición de clientes. Reduce la fricción y compara bien en una tabla donde el plan más barato "incluye" más. El anfitrión asume que serás pequeño, o que harás lo sensato y trasladarás tu tráfico pesado a un CDN y almacenamiento de objetos en cuanto crezcas, lo que cambia la salida a un proveedor que no hace nada más que salida.
Las nubes invierten el modelo. Miden la salida porque es su centro de ganancias y porque sus redes son costosas de operar a escala global. No prometen "ilimitado" porque el incentivo es diferente; quieren que arquitectes con cuidado y pagues por lo que usas. Los anfitriones compartidos quieren que traigas tu pequeño sitio y te quedes feliz hasta que no seas pequeño, momento en el que quieren que optimices o actualices. Nada de esto es cínico; así es como se pagan las cuentas. Pero explica por qué los Términos de Servicio están escritos en lenguaje aterciopelado y por qué los límites técnicos se aplican con un toque ligero hasta que no lo hacen.
Puntos de decisión: cuándo "ilimitado" está bien, cuándo es imprudente y cómo migrar
No descarto "ilimitado" de inmediato. Para un sitio de marketing pequeño con páginas principalmente estáticas y un blog modesto, está perfectamente bien si pones un CDN delante de él. Para una tienda con tráfico ligero y almacenamiento en caché sensato, puede funcionar mientras encuentras el ajuste de producto-mercado. Para una publicación que tiene picos impredecibles, es arriesgado a menos que caches y pre-renderices agresivamente. Para cualquier cosa que emita archivos grandes, es la herramienta equivocada desde el día de lanzamiento.
Mi árbol de decisión es contundente. Si tu tiempo de respuesta dinámico p95 es bajo y se mantiene bajo bajo estrés ligero, puedes usar un plan compartido más tiempo del que piensas. Si tu tasa de aciertos del CDN es genuinamente alta y tu salida de origen se mantiene plana cuando el tráfico se duplica, estás lo suficientemente seguro. Si alguna de esas condiciones falla, planea el cambio ahora. Un pequeño VPS con dos vCPUs y suficiente memoria para evitar el intercambio es aburrido y confiable. Te ofrece concurrencia predecible, mejor rendimiento de almacenamiento y un carril de red que realmente puedes entender. Todavía puedes usar la misma estrategia de CDN y almacenamiento de objetos. Cuando superes eso, lo sentirás de formas que puedes instrumentar y planificar, y darás el paso a clústeres dedicados o gestionados porque eliges hacerlo, no porque una cláusula de ToS te obligó.
La ruta de migración no necesita ser dramática. Mantén tu origen sin estado donde sea posible para que los cambios de DNS sean limpios. Almacena sesiones en un backend compartido al que puedas apuntar desde ambos orígenes, el antiguo y el nuevo, durante un breve solapamiento. Calienta las cachés antes de cambiar el interruptor para que el nuevo origen no reciba todo el impacto. El punto no es ser perfecto; es ser predecible. "Ilimitado" te falla de manera impredecible. Tu objetivo es dejar de sorprenderte.
Prometí escenarios prácticos y vividos porque así se hacen evidentes los límites de este tema. La siguiente sección es una Sección Premium con tres historias del mundo real, cada una comenzando en "ilimitado", cada una chocando contra un muro diferente, y los cambios exactos que las estabilizaron.
Premium content
Inicia sesión para continuar
Mi postura, sin rodeos: es sin medir, no ilimitado — trátalo de esa manera
No me importa "ancho de banda ilimitado" siempre que acordemos que significa "no contaremos bytes" y nada más. Es sin medir, no infinito. Los controles que dan forma a tu experiencia están en las cuotas de CPU, los límites de I/O, las restricciones de procesos, los techos de concurrencia y la configuración de puertos efímeros cuando te ocupas. Si diseñas como un adulto—CDN al frente, activos descargados, trabajo dinámico minimizado y rápido—puedes vivir felizmente en un plan que comercializa "ilimitado" porque rara vez necesitas probarlo. Si diseñas como si hubieras comprado un carril dedicado, aprenderás el significado de "uso justo" la primera vez que a alguien le importa tu sitio.
Así es como opero. Trato el origen como una pequeña API que merece respeto. Muevo bytes pesados a lugares diseñados para salida, y pago por esa salida porque es el costo de la escala. Vigilo p95, no promedios. Mantengo un ojo en la concurrencia y otro en la cola larga de tiempos de solicitud. Leo los Términos de Servicio como si fuera un documento técnico y traduzco cada eufemismo en un número. Acepto que el hosting compartido es un entorno sobresuscrito con una brillante propuesta de valor para sitios pequeños y un conjunto de límites estrictos para cualquier cosa ambiciosa. Cuando llega la ambición, me muevo porque elijo hacerlo, no porque una cláusula de terciopelo me diga que debo hacerlo.
Si has sido quemado por "ilimitado", no te castigues. La frase está diseñada para ser tranquilizadora, y funciona. Construye el pequeño y resiliente origen. Coloca un CDN al frente. Descarga lo pesado. Conoce tus números y tus puntos de estrangulamiento. Cuando llegue el día en que necesites un VPS o algo más grande, haz el movimiento con una caché caliente y una cabeza fría. Nunca volverás a ver "ancho de banda ilimitado" de la misma manera, y ese es el punto. No era una promesa. Era una invitación a hacer el trabajo correcto.
