S’acosta el Black Friday. Prepararàs l’oferta, la landing, el mailing, els anuncis i potser fins i tot comprovaràs que el servidor tingui prou recursos per aguantar el pic de visites.
Però hi ha una comprovació molt senzilla que és fàcil passar per alt:
què passa amb la memòria cau quan algú entra a la web des d’un enllaç del mailing?
Una web que funciona perfectament cada dia es pot saturar pocs minuts després d’enviar una campanya de correu. I no necessàriament perquè hi hagin entrat milers de persones alhora.
El problema poden ser els paràmetres que l’eina de mailing afegeix als enllaços.
Segons com estigui configurada la memòria cau, una URL amb aquests paràmetres pot deixar de servir-se des de la memòria cau o generar una variant diferent. Si, a més, l’eina afegeix un identificador únic per a cada subscriptor, pots acabar convertint unes desenes de visites aparentment inofensives en unes desenes de peticions dinàmiques a WordPress.
I això, en un moment en què molta gent clica alhora, pot ser suficient per saturar un allotjament.
En un cas recent, només 22 clics per minut van ser suficients per provocar problemes a la web.
El problema pot ser invisible abans d’enviar
Aquesta és probablement la part més enganyosa.
Entres a la landing abans d’enviar el correu, comproves que tot funcioni, la pàgina carrega en una fracció de segon i dones el vistiplau.
Però estàs provant una URL neta:
https://exemple.cat/oferta-black-friday/Quan s’envia el mailing, el subscriptor pot arribar a una adreça com aquesta:
https://exemple.cat/oferta-black-friday/?utm_source=newsletter&utm_campaign=blackfriday&_mrSubscriber=123456I una altra persona pot arribar a:
https://exemple.cat/oferta-black-friday/?utm_source=newsletter&utm_campaign=blackfriday&_mrSubscriber=789012Per a una persona són exactament la mateixa pàgina.
Per a la memòria cau, depenent de la configuració, poden no ser-ho.
Cada subscriptor pot arribar amb una URL que la memòria cau no reconeix com la pàgina que ja tenia guardada.
Per què la memòria cau és tan important?
La majoria de webs WordPress utilitzen algun sistema de memòria cau o cache.
Quan una pàgina ja s’ha generat, el servidor pot guardar-ne una còpia estàtica. Quan arriba el següent visitant, en lloc d’executar WordPress, PHP i les consultes a la base de dades una altra vegada, pot retornar directament aquella còpia.
Simplificant molt:
Visitant
↓
Memòria cau
↓
HTML ja generatés molt més barat per al servidor que:
Visitant
↓
PHP
↓
WordPress
↓
Plugins
↓
Base de dades
↓
HTMLUna web modesta pot atendre moltes visites simultànies si la majoria surten de la memòria cau.
La mateixa web pot començar a patir amb molt menys trànsit si cada visita obliga a executar WordPress sencer.
Quins paràmetres afegeixen les eines de mailing?
Les eines de mailing acostumen a afegir paràmetres als enllaços per mesurar les campanyes.
Els més coneguts són els UTM de Google Analytics:
utm_source
utm_medium
utm_campaign
utm_content
utm_term
utm_idNormalment, aquests valors són iguals per a tots els destinataris d’una mateixa campanya.
El problema pot ser més gran quan la plataforma afegeix també un identificador únic per a cada subscriptor.
| Eina | Paràmetres propis | Pot ser únic per subscriptor |
|---|---|---|
| HubSpot | _hsenc, _hsmi | _hsenc |
| Mailchimp | mc_cid, mc_eid | mc_eid |
| Mailrelay | _mrMailingList, _mrSubscriber | _mrSubscriber |
| Klaviyo | _kx | _kx |
| ActiveCampaign | vgo_ee | vgo_ee |
| Brevo, MailerLite, Acumbamail | Sobretot utm_* | Normalment no |
Els noms poden canviar segons la plataforma, la versió o la configuració.
Per això no em refiaria mai només d’una llista trobada a Internet.
La prova més fiable és enviar-te un correu de prova, clicar l’enllaç i mirar la URL final.
Els UTM també poden donar problemes
Que els UTM siguin iguals per a tothom no significa que siguin sempre inofensius.
Si el sistema de memòria cau està configurat perquè qualsevol URL amb paràmetres quedi fora de la cache, això:
/oferta/pot sortir de la memòria cau, mentre que això:
/oferta/?utm_source=newsletterpot obligar el servidor a generar la pàgina de nou.
La diferència és que un identificador únic per subscriptor pot multiplicar encara més el problema, perquè cada persona arriba amb una URL diferent.
Un cas real: només 22 clics per minut
Fa poc ho vaig veure en una web que gestiono.
Després d’enviar un mailing, el trànsit va arribar a un pic de només 22 clics per minut.
No sembla una barbaritat.
Però els enllaços portaven un identificador diferent per a cada subscriptor i les visites no s’estaven resolent correctament des de la memòria cau.
Moltes peticions havien de passar per PHP i consultar la base de dades.
El resultat va ser que l’allotjament es va saturar i alguns visitants van començar a veure una pàgina d’error de la capa de CDN/Varnish.
El més desconcertant era que WordPress aparentment no tenia cap error greu.
Als registres de WordPress pot no haver-hi cap error fatal ni cap avís a debug.log.
WordPress no necessàriament «falla»: el servidor pot acabar esgotant els processos PHP disponibles —els workers— o altres recursos mentre genera repetidament la mateixa pàgina amb paràmetres diferents.
La reacció habitual és pensar que «el servidor no aguanta», quan el problema pot ser simplement com s’estan tractant aquests paràmetres a la memòria cau.
I això explica també per què el problema pot passar desapercebut durant anys: mentre l’allotjament absorbeix les peticions dinàmiques, aparentment tot funciona. El problema apareix el dia que coincideixen prou clics en prou poc temps.
Com comprovar-ho abans d’enviar
La prova és bastant senzilla i no cal instal·lar cap eina especial.
Windows 10 i Windows 11 ja incorporen curl.
Obre Símbol del sistema (CMD).
Primer comprova la pàgina sense paràmetres:
curl.exe -s -D - -o NUL "https://exemple.cat/oferta-black-friday/"Aquesta comanda fa una petició HTTP normal, descarta el contingut HTML i mostra només les capçaleres de resposta.
Repeteix exactament la mateixa comanda:
curl.exe -s -D - -o NUL "https://exemple.cat/oferta-black-friday/"La primera petició pot haver generat la pàgina.
La segona, si tot funciona correctament, ja podria sortir de la memòria cau.
Ara prova la URL que arriba des del mailing:
curl.exe -s -D - -o NUL "https://exemple.cat/oferta-black-friday/?utm_source=newsletter&utm_campaign=blackfriday&_mrSubscriber=123456"Torna-la a executar.
I finalment canvia només l’identificador del subscriptor:
curl.exe -s -D - -o NUL "https://exemple.cat/oferta-black-friday/?utm_source=newsletter&utm_campaign=blackfriday&_mrSubscriber=789012"Això simula un altre subscriptor que clica el mateix enllaç per primera vegada.
La pregunta és: quan canvia l’identificador del subscriptor, el servidor continua podent retornar la mateixa pàgina des de la memòria cau o WordPress l’ha de generar de nou?
macOS i Linux
La comanda és pràcticament igual. Només cal substituir:
-o NULper:
-o /dev/nullPer què no faig servir curl -I?
És molt habitual trobar exemples com aquest:
curl.exe -sI "https://exemple.cat/oferta-black-friday/"És més curt i en molts servidors funcionarà perfectament.
Però l’opció -I fa una petició HTTP HEAD.
Un visitant normal que entra a la pàgina fa una petició GET.
Alguns servidors, proxies, CDN o sistemes de memòria cau poden tractar HEAD i GET de manera diferent.
Per això, per comprovar el comportament real abans d’un enviament important, prefereixo:
curl.exe -s -D - -o NUL "URL"La petició és GET, però descartem el cos de la pàgina i només ens quedem amb les capçaleres.
Què has de mirar a les capçaleres?
Depèn del sistema de memòria cau.
LiteSpeed
x-litespeed-cache: missi després:
x-litespeed-cache: hitCloudflare
cf-cache-status: MISSo:
cf-cache-status: HITVarnish o CDN
Pots trobar una capçalera Age:
Age: 0i, en una resposta ja guardada:
Age: 125Però no tots els sistemes et regalen un HIT o un MISS tan fàcil d’interpretar.
El cas de W3 Total Cache amb Disk: Enhanced
Amb W3 Total Cache en mode Disk: Enhanced pots no trobar cap capçalera explícita que digui si la pàgina ha sortit de la memòria cau.
En aquest cas cal comparar altres senyals.
Una pàgina servida des de la memòria cau pot mostrar una capçalera com:
Last-Modified: Sat, 26 Sep 2026 12:02:47 GMTamb una hora anterior, i no mostrar:
X-Powered-By: PHP/...En canvi, quan la petició ha hagut de passar per PHP pot aparèixer:
X-Powered-By: PHP/8.3o la versió corresponent.
No és una regla universal per a qualsevol servidor, però sí una pista molt útil quan compares dues respostes de la mateixa web.
L’important no és buscar obsessivament la paraula HIT.
L’important és comparar què passa amb:
/pagina/i amb:
/pagina/?parametre=valorCompte: pots tenir dues memòries cau alhora
Aquest és un altre punt que pot portar a conclusions equivocades.
Una web pot tenir una arquitectura com aquesta:
Visitant
↓
CDN / Varnish
↓
W3 Total Cache
↓
PHP + WordPress
↓
Base de dadesLa CDN pot respondre sempre:
Age: 0o mostrar un MISS.
Però això no significa necessàriament que WordPress hagi hagut d’executar PHP.
Pot passar perfectament que la CDN no guardi l’HTML i que, en canvi, W3 Total Cache estigui retornant un fitxer estàtic.
Un MISS a la CDN no implica necessàriament un MISS a la memòria cau de WordPress.
Cal mirar les dues capes.
Per exemple, si tens Age: 0, però no apareix X-Powered-By: PHP i el Last-Modified correspon a una còpia anterior, és possible que la CDN no hagi servit la pàgina des de la seva memòria cau però W3 Total Cache sí.
La pregunta final sempre és la mateixa:
aquesta visita ha obligat WordPress a executar PHP o no?
Com arreglar-ho
La solució habitual és configurar el sistema de memòria cau perquè determinats paràmetres de seguiment no obliguin a generar la pàgina de nou.
És a dir, que:
/oferta-black-friday/i:
/oferta-black-friday/?utm_source=newsletter&_mrSubscriber=123456puguin aprofitar la mateixa còpia de la pàgina.
Els paràmetres continuen existint a la URL del navegador. Per tant, Google Analytics i les eines de mailing els poden continuar utilitzant.
El que fem és evitar que uns paràmetres que només serveixen per fer seguiment obliguin WordPress a generar de nou el mateix contingut.
| Sistema | On revisar-ho |
|---|---|
| W3 Total Cache | Performance → Page Cache → Advanced → Accepted query strings |
| LiteSpeed Cache | Cache → Advanced → Drop Query String |
| WP Rocket | Ignora molts paràmetres de tracking habituals per defecte; cal revisar els que no reconegui |
| Cloudflare | Revisar les regles de cache i la cache key |
| Varnish o CDN de l’allotjament | Comprovar amb el proveïdor com tracta els query strings |
Paràmetres que acostumo a revisar
utm_source
utm_medium
utm_campaign
utm_content
utm_term
utm_id
fbclid
gclid
msclkid
_hsenc
_hsmi
mc_cid
mc_eid
_mrSubscriber
_mrMailingList
_kx
vgo_eeNo copiaria aquesta llista a cegues.
El procediment correcte és:
- Enviar-te un correu de prova.
- Clicar l’enllaç.
- Copiar la URL completa.
- Identificar quins paràmetres hi ha.
- Comprovar quins modifiquen contingut i quins només serveixen per fer tracking.
- Configurar només aquests últims perquè no afectin la memòria cau.
No ignoris tots els paràmetres
Pot semblar temptador dir a la memòria cau: «ignora qualsevol cosa que hi hagi després del ?».
No ho facis sense saber com funciona la web.
Hi ha pàgines que depenen precisament dels paràmetres.
Per exemple, la cerca de WordPress utilitza:
?s=paraulaUna botiga pot utilitzar paràmetres per filtrar productes.
Una galeria pot utilitzar-los per a la paginació.
Un cercador, configurador o comparador pot necessitar-los per mostrar contingut diferent.
Si ignores tots els paràmetres indiscriminadament, pots acabar servint el mateix contingut a URL que haurien de mostrar resultats diferents.
Ignora només els paràmetres que saps que són de seguiment i que no modifiquen el contingut de la pàgina.
Vigila també amb els UTM duplicats
Durant aquesta revisió és habitual descobrir un altre problema.
Algunes plataformes de mailing poden afegir automàticament els UTM de Google Analytics.
Si tu ja els havies afegit manualment, pots acabar amb una URL com:
?utm_source=newsletter&utm_campaign=blackfriday&utm_source=mailing&utm_campaign=campanya123Això no acostuma a provocar el mateix problema de rendiment que una memòria cau mal configurada.
Però sí que pot embrutar les dades d’Analytics i fragmentar una mateixa campanya sota noms diferents.
Per tant, comprova sempre qui afegeix els UTM:
o tu o l’eina de mailing, però preferiblement no tots dos.
Abans de prémer «Enviar»
- He enviat un correu de prova des de la plataforma real.
- He clicat un dels enllaços.
- He mirat la URL final completa.
- Sé quins paràmetres hi afegeix la plataforma.
- He comprovat la pàgina sense paràmetres amb
curl. - He repetit la prova amb els paràmetres del mailing.
- He canviat l’identificador del subscriptor per simular una nova visita.
- He comprovat si hi ha una o més capes de memòria cau.
- He verificat que els paràmetres de tracking no obliguin WordPress a executar PHP de nou.
- No he configurat la memòria cau perquè ignori indiscriminadament tots els paràmetres.
- He comprovat que els UTM no estiguin duplicats.
- Després dels últims canvis he buidat la memòria cau.
- He tornat a obrir les pàgines de destinació perquè tornin a quedar preparades a la memòria cau.
- He repetit la prova final.
Una web pot aguantar moltes visites quan serveix pàgines des de la memòria cau i començar a patir amb unes poques desenes quan totes obliguen WordPress a executar PHP.
Per això, abans d’un Black Friday, unes rebaixes, una venda d’entrades, l’obertura d’inscripcions o qualsevol mailing que pugui concentrar moltes visites en pocs minuts, val la pena dedicar cinc minuts a comprovar-ho.
Pot evitar que la web falli precisament en el moment en què més visites t’interessa rebre.
Si estàs preparant una campanya important i no tens clar com respondrà WordPress quan hi arribin moltes visites alhora, aquesta és una de les comprovacions que val la pena fer abans de prémer «Enviar».
