PrestaShop lento e in 503: era la cache

Un PrestaShop lento, o che va in 503 proprio quando i bot lo martellano, significa carrelli persi in silenzio: nessun alert, nessuna mail, solo un backend che cede sotto carico. È lo scenario che ho trovato su un e-commerce B2B di utensileria professionale: 5.047 errori 503 in 24 ore su una sola categoria del catalogo. Il sospetto ovvio - “server sottodimensionato”, “serve aggiornare PrestaShop” - era sbagliato. Era la cache.

⚠️ PrestaShop lento e in 503: la fotografia dai log

Il catalogo (migliaia di prodotti, hosting LiteSpeed) rispondeva bene sulla home ma andava in errore sulle categorie sotto il carico dei crawler. La fotografia di 24 ore di access log, per codice di risposta, era netta:

200  115.413   ok
302   29.653   redirect
403   15.552   scanner bloccati (voluto)
503    5.801   backend sotto carico
404    1.882

Il dato chiave non è il volume di 503, è dove cadevano: solo la home veniva servita da cache, mentre categorie e prodotti rispondevano no-cache. Senza cache, ogni singolo hit di un bot fa rigenerare l’intera pagina in PHP. Sotto il martellamento degli scraper, la categoria più pesante cede per prima e restituisce 503.

La diagnosi: escludere, non indovinare

Prima di toccare qualsiasi cosa ho raccolto le prove: access log via SSH, header live con curl -I, config della cache dal database, debug del modulo LiteSpeed attivato solo sul mio IP e poi ripristinato. Il metodo è escludere i sospetti uno per uno, con una prova ciascuno.

• Non era il cookie di sessione: le pagine prodotto uscivano public (cachabili) anche quando settavano il PHPSESSID.
• Non era la versione di PrestaShop: il punto in cui il FrontController avvia la sessione è identico tra la 1.7 e la 8.1. Nessun aggiornamento del CMS avrebbe risolto il problema.
• Non era il modulo LiteSpeed: la logica che decide se una pagina è cachabile è la stessa tra le versioni installate.
• Non era l’.htaccess: il blocco LiteSpeed (lookup, vary, cache key) era corretto.

Aggiornare PrestaShop non avrebbe risolto niente: la stessa riga di codice che si sospettava era identica tra le versioni. Senza i log, si sarebbe speso un budget di migrazione su un problema di configurazione.

⚠️ La causa reale: config cache desincronizzata

La verità era più semplice e più insidiosa: lo stato della configurazione cache di PrestaShop era stale. A freddo, il catalogo si rigenerava no-cache invece che public. L’innesco probabile è un ciclo di deploy con purge ravvicinati, che aveva lasciato la config della cache disallineata rispetto al database. Il modulo era configurato bene, ma lo stato interno che consulta a runtime era vecchio.

✅ La soluzione: zero codice, zero rischio

Il fix non ha richiesto una riga di codice né un aggiornamento. È bastato ri-salvare la configurazione del modulo LiteSpeed (Configuration::updateValue(...)), che rigenera lo stato della cache dal database. Subito dopo, le pagine a freddo tornano public, max-age=604800 e la seconda visita è servita da cache (hit). La categoria che generava 5.047 errori 503 torna a rispondere da cache: il backend non viene più travolto.

Nessuna modifica di file, nessun override, nessun upgrade. Solo lo stato riportato in sincrono.

⚠️ Il secondo tempo: il problema si sposta, non sparisce

Con la cache attiva i 503 non svaniscono del tutto: si spostano sulle pagine con filtri e ordinamento (?q=..., ?order=...), non cachabili per definizione (le combinazioni sono infinite) e martellate dagli scraper. Googlebot, più educato, sulle stesse URL prende 200; le botnet con IP sparsi no.

Qui la tentazione è togliere il parametro dalla cache key. L’ho scartata: è pericolosa e avvelena la cache. Cambiare la chiave, senza cambiare ciò che PHP calcola, significa che un bot che arriva con ?q= può salvare la pagina filtrata sotto la chiave della categoria base.

La soluzione applicata è un redirect 301 dei soli full-page con ?q= / ?order= verso la URL pulita, escludendo le chiamate XHR dei filtri usati dagli utenti veri (riconosciute da un parametro dedicato). Il risultato:

• il bot riceve la categoria base cachata (hit, niente 503);
• PHP non genera mai un filtrato sotto la chiave base;
• Google consolida le varianti a faccette sulla pagina base (SEO pulito);
• i filtri per gli utenti reali restano intatti.

Meglio di un noindex secco sui faceted: quello direbbe a Google di non indicizzarle, ma il backend continuerebbe a generarle a ogni hit. Pulizie così pesano più di quanto sembri: scansione sana e faccette consolidate sono tra le prime voci della SEO tecnica che decide come esci da un core update.

Il risultato

• Tutto il catalogo è cacheable e servito da cache: home, categorie e prodotti in hit; carrello e backoffice restano no-cache, come deve essere.
• La categoria da 5.047 errori 503 in 24h risponde da cache: backend non più travolto.
• I faceted full-page passano da 503 a 301 verso la base cachata, mentre i filtri utente continuano a funzionare.

La lezione (e il runbook che la rende ripetibile)

La diagnosi dai log batte sempre le supposizioni: il colpevole non era il server né la versione, ma uno stato di configurazione. E per evitare che il problema si ripresenti dopo il prossimo deploy, il runbook è banale ma decisivo:

dopo ogni purge/deploy della cache:
[ ] curl -I su 2-3 categorie
[ ] la risposta deve essere `public` / `x-litespeed-cache: hit`
[ ] se esce `no-cache`, ri-salvare la config del modulo

Un problema silenzioso che colpisce il fatturato non si risolve una volta: si tiene monitorato. Lo stesso vale per l’altro punto critico di questi shop, il checkout che regge sotto ogni modulo di pagamento con LiteSpeed attivo: cache e checkout sono le due facce dello stesso tema.

Il tuo PrestaShop va in 503 o rallenta e l’hosting dice che è tutto ok?

Se il server “sta bene” ma le pagine vanno in errore proprio sotto i bot, spesso il problema è diagnosticabile senza interventi invasivi. Diagnostico dai log, escludo con prove e sistemo senza rischi inutili: fa parte del mio servizio di debug e assistenza PrestaShop. Scrivimi da uno dei canali qui sotto con la tua situazione, meglio se con i log degli ultimi giorni: ti dico se è risolvibile.