Black Friday y Navidad: 7 puntos críticos de la tienda online

El Black Friday no tumba las tiendas online: las pone a prueba.

En esta guía repasamos los siete puntos técnicos donde hemos visto caer Prestashop y WooCommerce en plena campaña, del servidor al módulo de descuentos, y qué puedes revisar en las semanas que quedan hasta el 27 de noviembre.

Viernes de Black Friday, 10:14 de la mañana. La tienda lanza el email de campaña a 40.000 suscriptores. Once minutos después, el servidor devuelve errores 503 y empieza a sonar el teléfono de la agencia.

El envío no tiene la culpa. El problema llevaba meses ahí: una página de categoría que nadie había medido con tráfico real. En Javajan hemos visto esta escena, con variaciones, casi cada noviembre desde que desarrollamos tiendas online.

La presión es real y se puede medir. Según Adyen, en España las transacciones del Black Friday 2025 multiplicaron por más de cuatro las de un viernes normal. Ese mismo día Bizum batió su récord, con 5,3 millones de operaciones y una media de 61 por segundo.

Una tienda que funciona bien un martes de marzo puede no soportar cuatro veces su tráfico concentrado en pocas horas. Estos son los siete puntos donde, en nuestra experiencia, se rompe primero.

1. 1. Infraestructura: lo que cae antes de que nadie lo vea

Punto 1. Servidor y hosting: el límite que no aparece en el contrato:

Los planes de alojamiento anuncian «tráfico ilimitado«, pero lo que limita de verdad una tienda es el número de procesos PHP que pueden trabajar a la vez. En hostings compartidos con CloudLinux, el límite de entry proceses suele estar entre 20 y 40, siendo 20 el valor por defecto de CloudLinux y variando según el plan del proveedor.

Cuando se alcanza, las nuevas peticiones dinámicas suelen recibir un error 508 en lugar de ejecutarse; una página en blanco es más frecuentemente síntoma de agotamiento de memoria o del límite total de procesos.

Hagamos una cuenta rápida. Si cada ficha de producto sin caché tarda 600 ms en generarse y el servidor tiene 8 workers PHP, el techo teórico ronda las 13 páginas por segundo. Parece mucho hasta que sumas bots, comparadores de precios y las llamadas AJAX del carrito, que también ocupan workers.

El segundo cuello de botella es la base de datos. En WooCommerce, una tabla wp_options con el autoload inflado por plugins antiguos obliga a cada petición a cargar datos inútiles antes de pintar nada. En Prestashop, las tablas ps_connections, ps_guest i ps_cart crecen sin límite si nadie las limpia.

Qué hacer ahora:pide al proveedor los límites reales (workers PHP, conexiones MySQL, CPU e I/O) y compáralos con el pico del año pasado en Analytics multiplicado por cuatro. Si no cabe, aún hay tiempo para ampliar el plan de forma temporal. No lo dejes para la semana del 23.

Punto 2. Caché: cuándo protege y cuándo se apaga sola:

La caché de página es lo que permite a un servidor modesto atender miles de visitas: la página se genera una vez y se sirve muchas. El problema es que deja de funcionar justo con el cliente que más nos interesa.

En la mayoría de configuraciones, cuando alguien añade un producto al carrito, una cookie hace que todas las páginas que visite a partir de ese momento se salten la caché. Un día normal, la proporción de sesiones con carrito es pequeña. En Black Friday se dispara, y con ella el trabajo real del servidor.

Hay dos patrones que encontramos una y otra vez:

• Purga total a medianoche. Se cambian los precios de 2.000 productos a las 00:00, el plugin vacía toda la caché y la tienda arranca la campaña en frío, con el pico de tráfico encima.
• Fragmentos del carrito en WooCommerce. La llamada wc-ajax=get_refreshed_fragments se ejecuta en cada página y no se puede servir desde caché. Con un tema mal configurado, puede duplicar las peticiones PHP.

Qué hacer ahora: mide la tasa de aciertos de caché con usuarios que tienen carrito, no solo con visitantes anónimos. Precalienta la caché tras cada cambio masivo de precios y prográmalos por lotes. Si el hosting ofrece Redis o Memcached para la caché de objetos, actívalo y pruébalo ahora, no el día 27.

2. Front: el peso que se añade en las dos últimas semanas

Punto 3. Imágenes pesadas y scripts de campaña:

El rendimiento de una tienda suele degradarse en las dos semanas previas a la campaña, y no por el código. Lo degrada el contenido que se sube con prisas.

El ejemplo más habitual es el banner de portada: un PNG de 4 o 5 MB exportado tal cual desde el programa de diseño y subido la víspera. Añádele una cuenta atrás, un pop-up de captación, un chat y dos píxeles de seguimiento nuevos. Cada elemento es pequeño; juntos pueden sumar más de un segundo al tiempo de carga en móvil.

El impacto en conversión está documentado: según 2025 Web Performance Index de Yottaa, el 63% de los compradores abandonan páginas que tardan 4 segundos o más en cargar. En campaña, la oferta de la competencia está a una pestaña de distancia.

Qué hacer ahora: fija un peso máximo para los banners (por ejemplo, 200 KB en WebP o AVIF) y comunícalo a quien los diseña. Pasa PageSpeed Insights en móvil a la portada, a una categoría y a una ficha de producto antes y después de subir los materiales de campaña. Si las imágenes salen del mismo servidor, una CDN libera recursos para lo que de verdad necesita PHP.

3. Checkout y pagos: donde se pierde la venta que ya era tuya

Punto 4. El checkout, la página que no se puede cachear:

El carrito y el checkout son, por definición, páginas dinámicas. Cada paso recalcula envíos, impuestos, stock y descuentos. Es donde el servidor más trabaja y donde un fallo sale más caro, porque el cliente ya había decidido comprar.

Un caso que hemos visto más de una vez: el módulo de transporte consulta en tiempo real la tarifa en la API del transportista. Un día normal responde en 300 ms. En Black Friday la API del transportista también va saturada, tarda 8 segundos y el checkout se queda colgado sin ningún mensaje de error.

Los módulos de checkout en una sola página tienen un riesgo parecido. Muchos lanzan una llamada AJAX con cada cambio de campo, y cada llamada recalcula el carrito entero. Con diez campos y cuatro reglas de descuento activas, una sola compra puede generar decenas de peticiones PHP.

Qué hacer ahora: haz cinco compras de prueba completas, cronometradas y con las herramientas de desarrollador abiertas, con cupón y sin él. Apunta qué llamadas externas hace el checkout (transporte, validación de direcciones, antifraude) y asegúrate de que cada una tiene un tiempo de espera corto y un plan B, como una tarifa plana de reserva si la API no responde.

Punto 5. Pasarelas de pago: lo que no depende de ti y lo que sí:

No puedes evitar que la pasarela se caiga. En noviembre de 2023, Redsys sufrió dos incidencias en una semana, la última la noche antes del Black Friday, que según la propia compañía afectaron a entre el 1,7% y el 2,5% de las operaciones. Lo que sí controlas es lo que pasa en tu lado.

El problema más caro que encontramos no es la caída de la pasarela, sino la notificación perdida. El cliente paga, el banco lo confirma y envía el aviso a la URL de notificación de la tienda. Si el servidor está saturado o un cortafuegos lo bloquea, el pedido se queda en «pendiente de pago«: no se descuenta stock, no sale el email y el cliente vuelve a comprar o llama.

Diversificar también cuenta. Bizum ya es el segundo medio de pago del ecommerce en España, con una cuota que bancos y comercios sitúan entre el 20% y el 30%. Ofrecer solo TPV virtual con tarjeta es tener un único punto de fallo el día que menos te lo puedes permitir.

Qué hacer ahora: comprueba que la URL de notificación responde rápido y que el WAF o el plugin de seguridad no limita las IP de la pasarela. Prepara un procedimiento para conciliar los pedidos pendientes con el panel del banco cada dos horas durante el fin de semana. Y revisa la caducidad del certificado SSL: parece obvio hasta que caduca en plena campaña.

4. La lógica de negocio: descuentos e integraciones

Punto 6. El módulo de descuentos que nadie ha probado con volumen:

Los descuentos son lógica de negocio, y la lógica de negocio falla con datos reales, no con datos de prueba. En Prestashop, cada vez que se recalcula un carrito, el sistema evalúa las reglas de carrito activas. Si la campaña ha generado miles de códigos únicos, esa evaluación puede pasar de milisegundos a segundos.

El otro riesgo es la combinación. Dos reglas pensadas por separado, un 20% de campaña y un 15% para suscriptores, acaban sumándose. O se cuela el envío gratuito que solo tocaba a partir de 50 €. No es un fallo de servidor, pero puede costar más que una hora de caída.

En WooCommerce, los precios rebajados programados dependen de WP-Cron, que solo se ejecuta cuando entra una visita. Hemos visto ofertas que debían empezar a las 00:00 y no se activaban hasta las 00:40. Y plugins de precios dinámicos que recalculan cada producto de cada listado y ralentizan las categorías.

Qué hacer ahora: reproduce en el entorno de pruebas la misma estructura de descuentos que tendrás en producción, con el volumen real de códigos, y prueba las combinaciones cruzadas. Sustituye WP-Cron por un cron real del servidor. Y deja por escrito qué reglas son acumulables antes de que nadie las configure.

Punto 7. Integraciones con ERP, stock y email:

La tienda rara vez vive sola. Sincroniza stock con un ERP, pasa pedidos al almacén o a la herramienta de facturación y envía emails de confirmación. Cada integración es un proceso que, el día de más ventas, también trabaja más.

El patrón más común es la sincronización completa de stock cada pocos minutos. Con 10.000 referencias y un proceso que reescribe todo el catálogo, las tablas de productos quedan bloqueadas justo cuando más consultas reciben. Si la sincronización se retrasa, la tienda vende unidades que ya no tiene.

El email transaccional es el segundo sospechoso. Muchos hostings limitan los envíos por hora. Un día de 600 pedidos, con email de confirmación, de envío y aviso interno, ese límite puede quedarse corto, y los correos se pierden sin que nadie lo note hasta que llaman los clientes.

Qué hacer ahora: pasa las sincronizaciones a incrementales (solo lo que ha cambiado) o espácialas en las horas punta. Envía el email transaccional por un servicio SMTP dedicado, con SPF, DKIM y DMARC bien configurados. Y haz asíncronas las llamadas externas al crear el pedido: el pedido debe guardarse aunque el CRM no responda.

5. Dieciséis días: un plan realista antes del 27 de noviembre

Con dos semanas y media de margen, no todo es viable. Migrar de plataforma, cambiar de tema o reescribir el checkout son decisiones para enero, no para noviembre. Lo que sí se puede hacer es reducir el riesgo de los siete puntos por orden de impacto.

La prueba de carga merece una advertencia. Herramientas como k6 o JMeter simulan cientos de usuarios navegando y comprando, pero ninguna prueba reproduce del todo el tráfico real: bots, comparadores y la avalancha tras un email tienen patrones propios. Sirve para encontrar el primer cuello de botella, no para garantizar que no habrá ninguno.

La congelación de código es la medida más barata de todas. Del 24 de noviembre al 1 de diciembre, ninguna actualización de plugins, módulos ni tema. Una actualización automática de WooCommerce el jueves por la noche es un riesgo que ninguna mejora compensa.

Y el plan de contingencia, por escrito: quién recibe la alerta si la tienda cae el viernes a las 23:00, cuál es el teléfono del hosting, dónde está la copia de seguridad de las 20:00 y qué mensaje se publica si hay que poner la tienda en mantenimiento.

Antes del 27, una mirada externa

Si la campaña acaba demostrando que la plataforma no da más de sí, esa es una conversación para enero, con los datos de estos días en la mano. La tratamos a fondo en el artículo sobre cómo elegir entre WordPress, Laravel o Prestashop.

Hasta entonces, lo que cuenta es llegar al 27 con los siete puntos revisados. En Javajan hacemos auditorías técnicas precampaña: revisamos estos siete puntos sobre tu tienda real y te entregamos una lista priorizada de lo que conviene tocar antes del Black Friday y lo que puede esperar. Si quieres que le echemos un vistazo, solicita la auditoría técnica precampaña mientras todavía hay margen para actuar.