Black Friday 2026: que su tienda online aguante la carga

El Black Friday cae el día después de Thanksgiving, que la ley federal de Estados Unidos fija en el cuarto jueves de noviembre. En 2026 eso da el jueves 26 de noviembre para Thanksgiving, el viernes 27 de noviembre para el Black Friday y el lunes 30 de noviembre para el Cyber Monday. Estas fechas se calculan a partir de esa regla: contrástelas con el calendario comercial de su mercado, que puede adelantar o alargar sus propias campañas.

Quedan cuatro semanas en la fecha de este artículo. Es suficiente para congelar, medir y corregir, no para reconstruirlo todo. El objetivo no es tener el servidor más grande posible, sino conocer el límite del suyo antes de que el tráfico lo encuentre por usted, y decidir de antemano qué hará si se alcanza.

La congelación es la medida más barata y eficaz: mientras el código y la configuración no se muevan, lo que midió sigue siendo cierto. Elija una fecha de corte, por ejemplo el viernes 20 de noviembre, una semana antes del pico. Después, ninguna actualización del CMS, ninguna extensión nueva, ningún cambio de tema. Solo pasan las correcciones de errores críticos, probadas en la copia y anotadas en un registro.

La congelación no cubre las actualizaciones automáticas: desactívelas durante el periodo. La tabla siguiente se repite cada año desplazando las fechas.

Haga una copia de seguridad completa justo antes de la congelación (archivos, base de datos, configuración del servidor) y restáurela una vez en la copia cronometrando la operación: esa duración es un dato del plan de contingencia. La diferencia entre instantánea y copia de seguridad se explica en snapshot o copia de seguridad de un VPS.

Un tiempo de respuesta medio oculta lo que vive el comprador con mala suerte. Lea el percentil 95, o el 99 para los casos más lentos, y la tasa de errores. Una tienda cuyo promedio sigue siendo correcto pero donde uno de cada veinte compradores espera varios segundos pierde carritos sin que el promedio lo indique.

Mire también la forma de la curva. Un tiempo estable seguido de una caída brusca indica un límite duro, como un número máximo de conexiones a la base de datos o de procesos PHP. Esta prueba no dice cuántos visitantes reales recibirá: dice a qué ritmo de llegadas su copia, en las condiciones de la prueba, empieza a degradarse.

Aquí no se publica ningún resultado numérico, y es deliberado: una cifra medida en una máquina de pruebas no dice nada de la suya, y el script anterior solo se ejecutó contra un destino ficticio para validar su sintaxis, lo que no demuestra ninguna capacidad. La única medición que cuenta es la que tome sobre su propia copia.

La documentación de WooCommerce es clara: las páginas de carrito, de pedido y de cuenta deben seguir siendo dinámicas, porque muestran información propia del cliente. Exclúyalas de toda caché, en el plugin, en el servidor y en la red de distribución, y compruebe las cookies de sesión y de carrito que usa su versión de WooCommerce. Una página de carrito cacheada por error muestra el carrito de otro comprador, algo peor que una caída.

Para el resto, haga la lista de lo que puede servirse tal cual: portada, categorías, fichas de producto para visitantes sin cookies. El detalle de las rutas que excluir en la red de distribución se trata en nuestra guía sobre Cloudflare y la caché de un sitio cliente. En PrestaShop, la documentación para desarrolladores recomienda activar la caché Smarty en la página de Rendimiento y no activar la sección Caché cuando MySQL o MariaDB se ejecuta en la misma máquina. Compruebe estos ajustes en el back office de su versión y repita la prueba tras cada cambio.

Active el registro de consultas lentas de MariaDB antes de la prueba: SET GLOBAL slow_query_log=1; y luego SET GLOBAL long_query_time=1; para un umbral de un segundo, valor que debe ajustar. Estos ajustes en caliente desaparecen al reiniciar; para conservarlos, póngalos en la configuración. A partir de MariaDB 10.11, las variables se renombran con el prefijo log_slow_, así que compruebe el nombre de su versión.

Una caché de objetos como Redis alivia la base de datos al guardar en memoria los resultados repetidos. Póngale un límite con maxmemory y elija la política de expulsión con maxmemory-policy: la documentación de Redis indica que allkeys-lru es una buena opción por defecto cuando una parte de las claves se lee mucho más que el resto, mientras que noeviction devuelve un error cuando la memoria está llena. Vigile keyspace_hits y keyspace_misses en INFO stats durante la prueba: una tasa de aciertos baja indica una caché que no sirve de nada.

Si la prueba revela que la copia se satura demasiado pronto, hay dos vías: corregir el software o cambiar de plan. Si la máquina sigue siendo el factor limitante, aumente la memoria o los núcleos por escalones y repita la misma prueba tras cada uno, hasta que la curva aguante con un margen que considere suficiente.

Una recomendación de recursos leída en una web, incluida esta, sigue siendo una hipótesis: solo cuenta su medición sobre su tienda. El método para leer el consumo está detallado en dimensionar un VPS para el sitio de un cliente. Cuando una máquina ya no basta, HAProxy en un VPS reparte la carga, a costa de una arquitectura más compleja.

Muchos comerciantes confían la tienda a una agencia o a un proveedor de alojamiento. La prueba sigue siendo necesaria: hay que pedirla. Exija tres cosas por escrito antes de la fecha de congelación: el resultado fechado de una prueba de carga sobre una copia, con el escenario y el tiempo de respuesta en el percentil 95 leído en el pico; la lista de cambios previstos y la fecha de congelación acordada; un plan de contingencia firmado, que nombre a la persona autorizada a desactivar funciones o a restaurar la copia de seguridad. Un informe que solo cita el promedio, o un «todo está listo» sin resultado, no responde a la petición.

Decida también con ellos quién zanja el día D: el plan de contingencia cuesta funciones, es decir ventas, y esa decisión corresponde al negocio, no solo al proveedor técnico.

Conserve el script, el comando, los resultados y el registro de cambios en una carpeta fechada. El año próximo repetirá la misma prueba sobre la nueva versión de la tienda, y la comparación mostrará si las extensiones añadidas durante el año han encarecido el recorrido.

Para seguir la disponibilidad de las tiendas durante el periodo, consulte el informe de disponibilidad de los sitios cliente.