Black Friday i Nadal: 7 punts crítics de la botiga online

El Black Friday no fa caure les botigues online: les posa a prova.

En aquesta guia repassem els set punts tècnics on hem vist rebentar Prestashop i WooCommerce en plena campanya, del servidor al mòdul de descomptes, i què pots revisar en les setmanes que queden abans del 27 de novembre.

Divendres de Black Friday, 10:14 del matí. La botiga envia el correu de la campanya a 40.000 subscriptors. Onze minuts després, el servidor torna errors 503 i el telèfon de l’agència comença a sonar.

L’enviament no n’és el culpable. El problema hi era des de feia mesos: una pàgina de categoria que ningú havia mesurat amb trànsit real. A Javajan hem vist aquesta escena, amb variacions, gairebé cada novembre des que fem botigues online.

La pressió és real i mesurable. Segons Adyen, a Espanya les transaccions del Black Friday 2025 van multiplicar per més de quatre les d’un divendres normal. Bizum va batre aquell mateix dia el seu rècord, amb 5,3 milions d’operacions i una mitjana de 61 per segon.

Una botiga que va fina un dimarts de març pot no aguantar quatre vegades el seu trànsit concentrat en poques hores. Aquests són els set punts on, segons la nostra experiència, es trenca primer.

1. Infraestructura: el que cau abans que ningú ho vegi

Punt 1. Servidor i hosting: el límit que no surt al contracte:

Els plans d’allotjament anuncien «trànsit il·limitat«, però el que limita de veritat una botiga és el nombre de processos PHP que poden treballar alhora. En hostings compartits amb CloudLinux, el límit d’entry processes sol estar entre 20 i 40, sent 20 el valor per defecte de CloudLinux i variant segons el pla del proveïdor.

Quan s’assoleix, les noves peticions dinàmiques solen rebre un error 508 en lloc d’executar-se; una pàgina en blanc és més freqüentment símptoma d’esgotament de memòria o del límit total de processos.

Fem un compte ràpid. Si cada fitxa de producte sense cache triga 600 ms a generar-se i el servidor té 8 workers PHP, el sostre teòric és d’unes 13 pàgines per segon. Sembla molt fins que hi sumes bots, comparadors de preus i les crides AJAX del carret, que també ocupen workers.

El segon coll d’ampolla és la base de dades. A WooCommerce, una taula wp_options amb l’autoload inflat per plugins antics fa que cada petició arrossegui dades inútils abans de pintar res. A Prestashop, les taules ps_connections, ps_guest i ps_cart creixen sense parar si ningú les neteja.

Què fer ara: demana al proveïdor els límits reals (workers PHP, connexions MySQL, CPU i I/O) i compara’ls amb el pic de l’any passat a Analytics multiplicat per quatre. Si no hi cap, encara hi ha temps per escalar el pla temporalment. No ho deixis per a la setmana del 23.

Punt 2. Cache: quan protegeix i quan s’apaga sola:

La cache de pàgina és el que permet que un servidor modest serveixi milers de visites: la pàgina es genera una vegada i es reparteix moltes. El problema és que deixa de funcionar just amb el client que més ens interessa.

En la majoria de configuracions, quan algú afegeix un producte a la cistella, una galeta fa que totes les pàgines que visiti a partir d’aquell moment se saltin la cache. Un dia normal, la proporció de sessions amb cistella és petita. El Black Friday es dispara, i amb ella la feina real del servidor.

Hi ha dos patrons que hem trobat repetidament:

• Purga total a mitjanit. Es canvien els preus de 2.000 productes a les 00:00, el plugin buida tota la cache i la botiga arrenca la campanya en fred, amb el pic de trànsit a sobre.
• Fragments del carret a WooCommerce. La crida «wc-ajax=get_refreshed_fragments» s’executa a cada pàgina i no es pot servir des de cache. Amb un tema mal configurat, pot doblar les peticions PHP.

Què fer ara: mesura la ràtio d’encerts de cache amb usuaris que tenen cistella, no només amb visitants anònims. Pre-escalfa la cache després de cada canvi massiu de preus i programa’ls per lots. Si el hosting ofereix Redis o Memcached per a la cache d’objectes, activa’l i prova’l ara, no el dia 27.

2. Front: el pes que s’afegeix les últimes dues setmanes

Punt 3. Imatges pesants i scripts de campanya:

El rendiment d’una botiga sovint es degrada en les dues setmanes prèvies a la campanya, i no pel codi. El degrada el contingut que s’hi puja amb presses.

L’exemple més habitual és el bàner de portada: un PNG de 4 o 5 MB exportat directament del programa de disseny i pujat la vigília. Afegeix-hi un compte enrere, un pop-up de captació, un xat i dos píxels de seguiment nous. Cada element és petit; junts poden sumar més d’un segon al temps de càrrega en mòbil.

L’impacte en conversió està documentat: segons el 2025 Web Performance Index de Yottaa, el 63% dels compradors abandonen pàgines que triguen 4 segons o més a carregar. En campanya, l’oferta de la competència és a una pestanya de distància.

Què fer ara: fixa un pes màxim per als bàners (per exemple, 200 KB en WebP o AVIF) i comunica’l a qui els dissenya. Passa PageSpeed Insights en mòbil a la portada, a una categoria i a una fitxa de producte abans i després de pujar els materials de campanya. Si les imatges surten del mateix servidor, una CDN allibera recursos per al que realment necessita PHP.

3. Checkout i pagaments: on es perd la venda que ja era teva

Punt 4. El checkout, la pàgina que no es pot cachejar:

La cistella i el checkout són, per definició, pàgines dinàmiques. Cada pas recalcula enviaments, impostos, estoc i descomptes. És on el servidor treballa més i on un error costa més car, perquè el client ja havia decidit comprar.

Un cas que hem vist més d’una vegada: el mòdul de transport consulta en temps real la tarifa a l’API del transportista. Un dia normal respon en 300 ms. El Black Friday, l’API del transportista també va saturada, triga 8 segons i el checkout es queda penjat sense cap missatge d’error.

Els mòduls de checkout en una sola pàgina tenen un risc semblant. Molts llancen una crida AJAX a cada canvi de camp, i cada crida recalcula la cistella sencera. Amb deu camps i quatre regles de descompte actives, una sola compra pot generar desenes de peticions PHP.

Què fer ara: fes cinc compres de prova completes, cronometrades i amb les eines de desenvolupador obertes, amb cupó i sense. Llista quines crides externes fa el checkout (transport, validació d’adreces, antifrau) i assegura’t que cadascuna té un temps d’espera curt i un pla B, com una tarifa plana de reserva si l’API no respon.

Punt 5. Passarel·les de pagament: el que no depèn de tu i el que sí:

No pots evitar que la passarel·la caigui. El novembre del 2023, Redsys va patir dues incidències en una setmana, l’última la nit abans del Black Friday, que segons la mateixa companyia van afectar entre l’1,7% i el 2,5% de les operacions. El que sí pots controlar és què passa a la teva banda.

El problema més car que trobem no és la caiguda de la passarel·la, sinó la notificació perduda. El client paga, el banc ho confirma i envia l’avís a la URL de notificació de la botiga. Si el servidor està saturat o un tallafoc el bloqueja, la comanda queda «pendent de pagament«: no es descompta l’estoc, no surt el correu i el client torna a comprar o truca.

Diversificar també compta. Bizum ja és el segon mitjà de pagament de l’ecommerce a Espanya, amb una quota que bancs i comerços situen entre el 20% i el 30%. Oferir només TPV virtual amb targeta és tenir un únic punt de fallada el dia que menys t’ho pots permetre.

Què fer ara: comprova que la URL de notificació respon ràpid i que el WAF o el plugin de seguretat no limita les IP de la passarel·la. Prepara un procediment per conciliar les comandes pendents amb el panell del banc cada dues hores durant el cap de setmana. I revisa la data de caducitat del certificat SSL: sembla obvi fins que caduca en plena campanya.

4. La lògica de negoci: descomptes i integracions

Punt 6. El mòdul de descomptes que ningú ha provat amb volum:

Els descomptes són lògica de negoci, i la lògica de negoci falla amb dades reals, no amb dades de prova. A Prestashop, cada cop que es recalcula una cistella, el sistema avalua les regles de cistella actives. Si la campanya ha generat milers de codis únics, aquesta avaluació pot passar de mil·lisegons a segons.

L’altre risc és la combinació. Dues regles pensades per separat, un 20% de campanya i un 15% per a subscriptors, acaben acumulant-se. O s’hi afegeix l’enviament gratuït que només tocava a partir de 50 €. No és un error de servidor, però pot costar més que una hora de caiguda.

A WooCommerce, els preus rebaixats programats depenen de WP-Cron, que només s’executa quan entra una visita. Hem vist ofertes que havien de començar a les 00:00 i no s’activaven fins a les 00:40. I plugins de preus dinàmics que recalculen cada producte de cada llistat i alenteixen les categories.

Què fer ara:

reprodueix a l’entorn de proves la mateixa estructura de descomptes que tindràs en producció, amb el volum real de codis, i prova les combinacions creuades. Substitueix WP-Cron per un cron real del servidor. I deixa per escrit quines regles són acumulables abans que les configuri ningú.

Punt 7. Integracions amb ERP, estoc i correu:

La botiga rarament viu sola. Sincronitza l’estoc amb un ERP, passa comandes al magatzem o a l’eina de facturació i envia correus de confirmació. Cada integració és un procés que, el dia de més vendes, també treballa més.

El patró més comú és la sincronització completa d’estoc cada pocs minuts. Amb 10.000 referències i un procés que reescriu tot el catàleg, les taules de productes queden bloquejades just quan reben més consultes. Si la sincronització s’endarrereix, la botiga ven unitats que ja no té.

El correu transaccional és el segon sospitós. Molts hostings limiten els enviaments per hora. Un dia de 600 comandes, amb correu de confirmació, d’enviament i d’avís intern, aquest límit pot quedar curt, i els correus es perden sense que ningú se n’adoni fins que truquen els clients.

Què fer ara: passa les sincronitzacions a incrementals (només el que ha canviat) o espaia-les durant les hores punta. Envia el correu transaccional per un servei SMTP dedicat, amb SPF, DKIM i DMARC ben configurats. I fes asíncrones les crides externes en crear la comanda: la comanda s’ha de desar encara que el CRM no respongui.

5. Setze dies: un pla realista abans del 27 de novembre

Amb dues setmanes i mitja de marge, no tot és viable. Migrar de plataforma, canviar de tema o reescriure el checkout són decisions per al gener, no per al novembre. El que sí es pot fer és reduir el risc dels set punts per ordre d’impacte.

La prova de càrrega mereix un avís. Eines com k6 o JMeter simulen centenars d’usuaris navegant i comprant, però cap prova reprodueix del tot el trànsit real: bots, comparadors i l’allau posterior a un correu tenen patrons propis. Serveix per trobar el primer coll d’ampolla, no per garantir que no n’hi haurà cap.

La congelació de codi és la mesura més barata de totes. Del 24 de novembre a l’1 de desembre, cap actualització de plugins, mòduls ni tema. Una actualització automàtica de WooCommerce el dijous a la nit és un risc que cap millora compensa.

I el pla de contingència, per escrit: qui rep l’alerta si la botiga cau el divendres a les 23:00, quin és el telèfon del hosting, on és la còpia de seguretat de les 20:00 i quin missatge es publica si cal posar la botiga en manteniment.

Abans del 27, una mirada externa

Si la campanya acaba demostrant que la plataforma no dóna més de si, aquesta és una conversa per al gener, amb les dades d’aquests dies a la mà. En parlem a fons a l’article sobre com triar entre WordPress, Laravel o Prestashop.

Fins aleshores, el que compta és arribar al 27 amb els set punts revisats. A Javajan fem auditories tècniques pre-campanya: revisem aquests set punts sobre la teva botiga real i et lliurem una llista prioritzada del que cal tocar abans del Black Friday i del que pot esperar. Si vols que hi donem un cop d’ull, sol·licita l’auditoria tècnica pre-campanya mentre encara hi ha marge per actuar.