case history
Case #04 · Performance Debug

Debug performance e-commerce: il colpevole non era il sito del cliente

Rallentamenti e problemi al checkout su un e-commerce WordPress. Diagnosi: il problema viene da un sito corporate adiacente sullo stesso server condiviso. Load medio: 67.

PiattaformaWordPress + WooCommerce
HostingServer condiviso
Diagnosi~35 minuti
FixImmediato

La segnalazione

Il responsabile e-commerce di un'azienda di arredamento segnala via email: il sito è lento, il checkout a volte non risponde, i clienti si lamentano.

Prima reazione ovvia: il sito e-commerce ha qualcosa che non va. Plugin non aggiornati, query lente, cache mal configurata, Facebook Pixel che blocca il rendering.

Diagnosi: dove guardare per primo

Prima di toccare qualsiasi plugin o configurazione, si controlla il carico del server:

# SSH sul server
uptime
# Output: load average: 67.23, 45.18, 38.91

top -bn1 | head -20
Load average rilevato
67
Load normale atteso
<2

Un load di 67 su un server condiviso significa che decine di processi sono in attesa di CPU. Il sito e-commerce non può rispondere normalmente — non è un problema del codice, è un problema di risorse.

Il vero colpevole

Analizzando i processi attivi, emerge che il grosso del carico non viene dall'e-commerce ma da un altro sito sullo stesso server: il sito corporate dell'azienda, non gestito dallo stesso tecnico e non ottimizzato.

Quel sito corporate aveva due problemi combinati:

Risultato: il sito corporate consumava tutte le risorse del server, e l'e-commerce ne pagava le conseguenze pur essendo tecnicamente a posto.

Azioni immediate

  1. Disattivazione del plugin Facebook Pixel (PixelYourSite) sull'e-commerce — non era la causa principale ma aggiungeva latenza lato client
  2. Aggiunta Crawl-delay nel robots.txt del sito corporate
  3. Segnalazione al team responsabile del sito corporate per ottimizzazione WPML/ACF
  4. Monitoraggio load nei giorni successivi per confermare il miglioramento

Su hosting condiviso, il colpevole di un sito lento è spesso un vicino. Prima di cercare bug nel codice, controlla sempre il load del server. Se è alto, trova quale processo lo genera — non dare per scontato che sia il sito che stai guardando.

Pattern diagnostico generalizzato

Checklist per problemi di performance su WordPress in hosting condiviso:

  1. uptime — load > 5? Il problema è sistemico, non del sito
  2. top / htop — chi consuma CPU e RAM?
  3. mysqladmin processlist — query MySQL lente o bloccate?
  4. tail -f /var/log/apache2/access.log — bot aggressivi?
  5. Solo a questo punto: analisi plugin, query WordPress, cache

Sul Facebook Pixel

La disattivazione del pixel era una misura aggiuntiva: il pixel di Facebook blocca il rendering della pagina se il dominio meta.com non risponde rapidamente. Su connessioni lente o in caso di timeout Meta, il checkout poteva sembrare bloccato anche se il server stava rispondendo correttamente.

Fix: caricare il pixel in modo asincrono o via Google Tag Manager con strategia defer.

WordPress WooCommerce performance server debug hosting condiviso Facebook Pixel