¿Su sitio web se cayó por un pico de tráfico? Haga esto primero

Su video se hizo viral, un medio de noticias lo mencionó, o la oferta que planeó durante semanas por fin llegó, y en el momento exacto en que apareció la mayor multitud, su sitio se volvió lentísimo o empezó a mostrar un error. Cada minuto que sigue caído se siente como ver a los clientes pasar frente a una puerta cerrada. Si su sitio web se cayó por un pico de tráfico, es posible que el pico todavía esté ocurriendo, lo que significa que aún puede salvar parte de ese momento. La primera hora no se trata de arreglar todo el sitio. Se trata de confirmar qué está fallando en realidad, poner a su proveedor de hosting a trabajar en el problema y mantener una página sencilla frente a las personas que van llegando. La corrección más profunda puede esperar hasta que la multitud disminuya. Puede empezar el primer paso en los próximos cinco minutos.

La primera hora se trata de mantener una página en pie

Mientras los visitantes siguen llegando, su tarea es estrecha: mantener cargando la página que intentan alcanzar, o un sustituto de ella. Todo lo demás, incluido qué causó la caída y si necesita un plan diferente, es una pregunta para mañana. Los cinco pasos siguientes se ejecutan en orden, y cada uno toma minutos, no horas. Tome notas mientras avanza, porque los horarios, los errores y las capturas de pantalla que recopile ahora son lo que su proveedor y cualquier desarrollador necesitarán después.

Confirme que en verdad es tráfico

Cargue la URL exacta de la campaña en su teléfono con el Wi-Fi apagado, o pídale a alguien en otro lugar que la intente. Anote la hora y el error que ve, como un 502, 503 o 504, un tiempo de espera agotado, o una página en blanco. Luego revise la página de estado de su proveedor y, si usa uno, la página de estado de su CDN, porque una caída generalizada del proveedor se ve idéntica a sus visitantes.

Una multitud no es lo único que puede tumbar un sitio en el peor momento posible. Si el navegador dice que el sitio no se puede encontrar en absoluto, revise que su dominio no haya vencido, y nuestra guía sobre qué hacer cuando un nombre de dominio ha expirado cubre ese camino. Si sus analíticas muestran miles de visitas desde lugares extraños sin referencia real, o el sitio muestra páginas que usted no creó, puede estar lidiando con bots o un ataque, y los pasos de las primeras 24 horas después de un hackeo van primero. Un pico repentino puede ser tráfico automatizado, así que revise de dónde vienen las visitas antes de tratar cada solicitud como un comprador.

Llame a su proveedor de hosting con la evidencia

Abra un ticket de soporte o un chat y déles la URL, cuándo empezó el problema, una captura del error, de dónde viene el tráfico y cuánto espera que dure. Luego haga preguntas directas: ¿mi cuenta está tocando un límite de recursos, están al máximo los procesos de PHP o las conexiones a la base de datos, me están limitando la velocidad, y hay un incidente de su lado? Un agente de soporte puede ver las gráficas de recursos de su cuenta. Usted por lo general no puede, y adivinar desperdicia los minutos que importan.

Pregunte una cosa más: ¿el plan tiene un aumento temporal de capacidad o una mejora el mismo día, y cuánto cuesta después? Algunos proveedores ofrecen exactamente eso, y para un pico corto puede ser todo lo que necesita.

Active la caché, y deje en paz una caché que funciona

Si todavía puede llegar al área de administración de su sitio o al panel de hosting, active la caché de página completa para las páginas públicas si está apagada. Caché significa que el servidor construye una página una vez y entrega la copia guardada a los siguientes mil visitantes en lugar de reconstruirla para cada uno. Si la caché ya está activada y las páginas están cargando para algunas personas, no la borre. Una caché borrada obliga al servidor a reconstruir cada página en el peor momento posible. La única razón para borrarla en medio del pico es si la copia guardada es en sí misma la página de error.

Revise qué le ofrece ya su proveedor antes de agregar algo. Las páginas de soporte de WordPress.com, por ejemplo, dicen que su caché de servidor integrada hace innecesario, y potencialmente dañino, un plugin de caché aparte ahí. La documentación de caché de WordPress explica las diferentes capas si no está seguro de cuál tiene.

Ponga en pie una página de espera sencilla

Una página de espera es una sola página plana: su oferta, una línea que diga que el sitio completo está poniéndose al día, y una forma de contactarlo, como un formulario corto de registro o contacto alojado en algún lugar que siga funcionando. Constrúyala como una página estática, es decir, HTML plano sin base de datos detrás, en un hosting estático aparte o en un CDN que ya tenga configurado. Una página así casi no tiene nada que pueda fallar.

Este es el paso que convierte a los visitantes perdidos en personas a las que puede contactar después. Alguien que deja un correo electrónico en una página plana vale mucho más que alguien que miró una rueda girando y se rindió.

Apunte el enlace viral a la página ligera

Si la página original no puede volver rápido, envíe la URL de la campaña a la página de espera con una redirección temporal, no permanente. La guía de Google sobre redirecciones y la Búsqueda de Google dice que una redirección temporal mantiene la URL original en sus resultados, que es lo que quiere cuando la página va a volver. Un 301 permanente le dice a los motores de búsqueda que el cambio es definitivo.

Si usted controla el enlace en su anuncio, biografía o publicación y puede cambiarlo y probarlo en unos minutos, apúntelo directamente a la página ligera. Si no puede verificar el cambio rápido, deje el enlace en paz y confíe en la redirección.

Su sitio se quedó sin procesos, no sin ancho de banda

Una vez que la página se sostiene, la pregunta es por qué falló. La respuesta corta es que una multitud repentina agotó la capacidad de procesamiento limitada de su cuenta de hosting, y eso es distinto de quedarse sin datos mensuales.

Cada plan de hosting viene con una cantidad fija de CPU, memoria, actividad de disco, conexiones a la base de datos y procesos de trabajo. La guía de Hostinger sobre métricas de rendimiento del servidor trata esto como algo separado del tráfico, y los planes compartidos limitan cada cuenta para que un sitio ocupado no ralentice a sus vecinos, como describe SiteGround en su política de uso justo. Un plan de «ancho de banda ilimitado» todavía puede quedarse sin la capacidad para construir páginas para una multitud de visitantes al mismo tiempo.

El multiplicador son las páginas sin caché. En un sitio que construye cada página por solicitud, cada visita ejecuta código, carga el tema y los plugins, y consulta la base de datos. La documentación de hilos de PHP de Kinsta explica que un hilo maneja una solicitud a la vez, y una vez que cada hilo está ocupado, las nuevas solicitudes esperan. Los plugins lentos y las consultas pesadas a la base de datos hacen que cada solicitud retenga su hilo más tiempo, como plantea la página de Kinsta sobre rendimiento de PHP. Suficiente espera termina en tiempos de espera agotados y errores 503 o 504, que a menudo es exactamente lo que vieron sus visitantes.

Por eso tampoco existe un número confiable de «mi sitio aguanta X visitantes». La capacidad depende de cuántos visitantes llegan al mismo tiempo, cuánto trabajo requiere cada página y cuánto de eso absorbe la caché. Los conteos mensuales de visitantes y las vistas de página son sustitutos pobres de eso, y una puntuación de velocidad de página tampoco muestra la limitación de la cuenta ni una fila de solicitudes en espera.

Las soluciones baratas van antes que un nuevo hosting

Nosotros vendemos hosting, y un nuevo proveedor a menudo no es lo que necesita después de un pico. Si la página que importa puede servirse como contenido público, una página estática de respaldo, la caché que ya tiene, una configuración de caché compatible y la mejora temporal de su propio proveedor pueden bastar para este evento. Pruebe eso primero.

Una mejora tiene sentido cuando la evidencia muestra que está tocando los límites de su plan, o cuando las partes de su sitio que no se pueden almacenar en caché, como el pago, necesitan más capacidad. Una mejora por sí sola no arreglará una consulta lenta a la base de datos, un plugin roto, una avalancha de bots ni un servicio de terceros que se cayó. Por eso un sitio puede pasarse a un plan más grande y aun así caerse en el próximo pico. Vea qué falló antes de pagar por más de lo mismo.

La tabla de abajo ordena las causas usuales por lo que las corrige y qué tan grande tiende a ser la tarea. Es un orden de diagnóstico, no un ranking de qué tan seguido ocurre cada una; no existen datos entre proveedores para clasificarlas, y cualquier sitio puede tener cualquiera de estas primero.

Un CDN ayuda a las páginas públicas y deja el pago en su servidor

Un CDN, o red de entrega de contenido, guarda copias de sus archivos en servidores alrededor del mundo. Cuando un visitante pide algo que el CDN ya guardó, entrega la copia y su propio servidor nunca se entera. La guía de inicio para caché de Cloudflare explica la configuración básica.

El detalle está en qué se guarda. La página de Cloudflare sobre comportamiento de caché por defecto dice que las imágenes, los scripts y los archivos de estilo se almacenan en caché por defecto, pero las páginas HTML no, a menos que agregue reglas de caché para ellas. Si sus páginas se construyen por solicitud, un CDN con la configuración por defecto todavía puede dejarle a su servidor la parte difícil. Las páginas ligadas a un visitante, como un carrito, una cuenta o un pago, deben omitir la caché a propósito. Las reglas sobre cuándo puede reutilizarse una copia guardada están en el estándar de caché HTTP, RFC 9111 del IETF, publicado en junio de 2022.

Un sitio estático va más lejos: cada página está preconstruida, así que no hay servidor de construcción de páginas ni consulta a la base de datos para esas páginas en absoluto. AWS describe esta configuración en su guía para alojar un sitio web estático en CloudFront, donde los archivos en caché vienen de servidores de borde y el origen solo se consulta cuando falta una copia.

Ni un CDN ni el hosting estático hacen que un sitio sea imposible de tumbar. Los fallos de caché, los inicios de sesión, el pago, los formularios, la publicación y los errores de DNS todavía dependen de que algo detrás funcione. El costo de empezar es bajo. La página de planes de Cloudflare enumera un plan gratuito y un plan Pro a $20 al mes con facturación anual o $25 mes a mes, y las preguntas frecuentes de CloudFront enumeran un nivel gratuito de 1 TB de transferencia de datos y 10 millones de solicitudes al mes, sujeto a los términos de AWS.

El próximo pico se gana la semana antes de que llegue

Una promoción planeada, el lanzamiento de un producto o una aparición en televisión le dan tiempo para prepararse, y unas horas de preparación pueden cambiar cómo va el próximo pico. Los pasos de abajo cubren el proveedor, la caché, el respaldo y las pruebas. Ninguno promete tiempo de actividad perfecto; mantienen su oferta y una forma de contactarlo disponibles mientras se arregla todo lo demás.

Sepa qué páginas van a recibir el golpe

Elija la una o dos URL a las que la promoción va a enviar a la gente. Para cada una, separe lo que ocurre en ella entre contenido público que se puede almacenar en caché y acciones que no, como agregar al carrito, iniciar sesión o pagar.

Pídale a su proveedor los límites reales

Pida los límites que el plan realmente aplica, no el nombre del plan: CPU, memoria, procesos de PHP o procesos concurrentes, conexiones a la base de datos, actividad de disco, transferencia de datos, qué pasa cuando se excede, cómo conseguir una mejora temporal, cómo contactar soporte rápido y qué monitoreo puede ver. El artículo de Hostinger sobre preparar un sitio para el tráfico del Black Friday es una lista útil para comparar.

Pruebe la caché, el respaldo y la redirección

Active la caché de página o de borde para las páginas públicas y confirme que los carritos, las cuentas y los pagos están excluidos. Construya la página estática de respaldo y configure la redirección temporal antes del día del lanzamiento, y luego pruebe ambas. Las pruebas de carga solo valen la pena con el permiso de su proveedor y un aumento gradual. La guía de pruebas de carga de AWS para CloudFront advierte que una prueba desde una sola dirección IP da resultados engañosos y puede forzar a un pequeño grupo de servidores de borde.

Escriba el plan, pruébelo y manténgalo actualizado. La guía de planificación de contingencias, SP 800-34 Rev. 1, del NIST fue escrita para sistemas federales y no para hosting de pequeñas empresas, pero su hábito de documentar y ensayar un respaldo también aplica a una promoción de una sola página. Sepa quién tiene las credenciales de su dominio, hosting, CDN y analíticas, porque buscar una contraseña en medio de un pico cuesta los mismos minutos que el pico.

Una revisión de diez minutos le muestra dónde está parado

Puede hacer esto hoy, antes de que nada esté ardiendo. No le dirá su capacidad exacta, pero le mostrará quién controla qué y si su caché está haciendo su trabajo.

1. Encuentre su proveedor, su plataforma de sitio y su CDN: Revise sus correos de facturación, su panel de DNS o su panel de control de hosting.
2. Lea los límites reales de su plan: Abra la página del plan y el panel de recursos, y anote los límites de CPU, memoria, procesos, base de datos y transferencia, el uso actual, cualquier advertencia y si existe una mejora temporal.
3. Verifique que la caché esté activada: Cargue una página pública en una ventana privada del navegador y busque en los encabezados de respuesta o en el panel de su proveedor un estado de caché, sin borrar una caché que funciona.
4. Pruebe desde afuera: Abra las páginas de estado de su proveedor y de su CDN, cargue su URL principal desde otra conexión, y anote el código de estado y la hora.

Omita probar las páginas de pago, cuenta o formulario como si debieran estar en caché; esas están hechas para llegar a su servidor cada vez. Si termina las cuatro revisiones y todavía no puede decir quién administra su DNS o si la caché está funcionando, esa es la brecha que debe cerrar antes de la próxima promoción, no durante ella.

Preguntas frecuentes sobre el sitio web caído por un pico de tráfico

¿Puede demasiado tráfico tumbar un sitio web?

Sí. Una multitud repentina puede agotar los recursos del servidor, de los procesos, de la base de datos o de la cuenta de su plan, especialmente en páginas que se construyen de nuevo para cada visitante en lugar de servirse desde una caché.

Mi sitio web se cayó después de una publicación viral. ¿Qué hago primero?

Revise el sitio desde fuera de su propia red, vea la página de estado de su proveedor, contacte a su proveedor con la URL, la hora y el error, y envíe a los visitantes a una página sencilla en caché o estática usando una redirección temporal.

¿Un CDN evitará que mi sitio web se caiga?

Puede quitarle mucha carga a su servidor en las páginas que almacena en caché. Cloudflare no almacena páginas HTML en caché por defecto, y los fallos de caché, los inicios de sesión y el pago todavía dependen de su propio servidor.

¿Debo mejorar mi hosting después de un pico de tráfico?

Solo después de confirmar que en verdad tocó los límites de su plan. Un plugin lento, una consulta pesada a la base de datos o tráfico de bots seguirán causando problemas en un plan más grande.

¿Debo usar una redirección 301 mientras mi sitio está caído?

No. Use una redirección temporal para una caída temporal. Google dice que una redirección temporal mantiene la URL original en sus resultados.

¿Cómo manejo un pico de tráfico antes de una promoción planeada?

Pídale a su proveedor los límites reales de su plan, active la caché para las páginas públicas, construya y pruebe un respaldo estático y una redirección, y haga pruebas de carga solo con el permiso de su proveedor.

En resumen

Cuando un pico tumba su sitio, la primera hora se trata de una página, no de todo el sitio. Confirme que en verdad es tráfico y no un dominio vencido ni un ataque, ponga a su proveedor a revisar su cuenta, active la caché sin borrar una que funciona, y apunte el enlace de la campaña a una página sencilla con una redirección temporal. La razón por la que ocurrió suele ser una fila de visitantes esperando un número limitado de procesos del servidor, no una escasez de ancho de banda.

Después de que pase la multitud, compare la ventana del incidente con sus gráficas de recursos, sus registros de error y sus fuentes de tráfico antes de comprar nada. La próxima promoción va distinto cuando conoce sus límites reales, sus páginas públicas están en caché, y una página de respaldo probada está lista.

Si quiere que alguien revise esa evidencia con usted, Web Leveling puede leer sus registros de recursos y de error, configurar la caché y un respaldo estático, y decirle si su plan actual es suficiente antes de que nadie sugiera un cambio. Nuestro trabajo de hosting web empieza con la solución menos disruptiva, y si la mejora de su propio proveedor o la caché que ya tiene resuelve el problema, se lo diremos. Trabajamos con pequeñas y medianas empresas de todo el país y del extranjero. Cuéntenos qué pasó durante su pico, y le ayudaremos a prepararse para el próximo.

Términos