WPsec.itSicurezza WordPress
Tutti gli articoli
Performance6 min di letturaTeam WPsec.it

WordPress non è lento: la diagnosi che quasi nessuno fa nell'ordine giusto

Cambiare hosting, installare cache, ottimizzare le immagini: la maggior parte degli interventi di velocizzazione parte dal punto sbagliato. L'ordine corretto di diagnosi delle performance WordPress che evita spese inutili.

Condividi
WordPress non è lento: la diagnosi che quasi nessuno fa nell'ordine giusto

Esiste una liturgia nota a chiunque gestisca siti WordPress: il cliente si lamenta della lentezza, l'agenzia installa un plugin di cache, comprime le immagini, magari cambia hosting. A volte funziona. Spesso no. E quando non funziona, si è speso tempo e denaro senza capire perché.

Il motivo è semplice: la lentezza non è una malattia, è un sintomo. Può nascere in almeno quattro livelli diversi, e ogni livello ha cure completamente diverse. Curare il livello sbagliato non solo è inutile: maschera il problema reale mentre il sito continua a perdere conversioni.

I quattro livelli della lentezza

LivelloCosa misuraStrumento gratuitoRimedio tipico
1. Rete e server (TTFB)Tempo prima del primo bytecurl, WebPageTestHosting, caching server-side, CDN
2. Backend applicativoTempo PHP + query databaseQuery Monitor, New RelicPlugin lenti, database, object cache
3. TrasferimentoPeso pagina, numero richiesteDevTools NetworkImmagini, script, font
4. Rendering clientLCP, INP, CLSPageSpeed Insights, LighthouseJavaScript, layout, priorità risorse

La regola d'oro: si interviene sempre partendo dal livello più alto della tabella dove il problema è confermato dai numeri. Un TTFB di 2 secondi rende ridicolo qualsiasi lavoro sul JavaScript: puoi ottimizzare quanto vuoi il rendering, che il visitatore aspetta comunque due secondi prima che la pagina esista.

Livello 1: il TTFB, la misurazione che quasi nessuno fa

Il Time To First Byte dice quanto tempo passa dalla richiesta al primo byte di risposta. È il dato che discrimina tutto il resto:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://iltuosito.it/

Interpretazione pratica:

  • sotto 300 ms: il server va bene, il problema è altrove
  • da 300 ms a 800 ms: margine di miglioramento, probabilmente manca caching server-side
  • oltre 1 secondo: qui c'è il problema principale, fermati a indagare prima di toccare altro

Se il TTFB è alto, le cause tipiche sono tre, in ordine di probabilità: assenza totale di cache a livello server (ogni visita rigenera la pagina via PHP), plugin pesanti eseguiti su ogni richiesta, database sottodimensionato o affamato di risorse sul piano hosting.

Il test della pagina interna

Un confronto utile e gratuito: misura il TTFB della homepage e di una pagina interna qualsiasi. Se entrambe sono lente, il problema è sistemico (hosting, cache, database). Se solo alcune pagine sono lente, il problema è contenutistico: uno shortcode dispendioso, un page builder che carica 30 moduli, un widget che chiama API esterne.

Livello 2: trovare il colpevole nel backend

Se il TTFB è alto anche con la cache attiva, il sospetto diventa il codice. Due strumenti bastano:

Query Monitor (plugin gratuito) mostra per ogni richiesta: tempo PHP, tempo database, numero di query, e soprattutto le query più lunghe con la funzione chiamante. Nella maggior parte dei casi che analizziamo emerge uno di questi pattern:

  • un plugin che fa decine di query per pagina (spesso widget social o related posts)
  • opzioni giganti caricate su ogni richiesta (autoloading di wp_options fuori controllo)
  • chiamate HTTP esterne sincrone verso API lente (font Google verificati male, feed social, licenze di temi)

L'autoloading di wp_options merita un accenno specifico perché è invisibile e frequente: se qualche plugin ha scritto opzioni da megabyte con flag autoload, ogni singola richiesta le ricarica. Una query diagnostica basta per verificarlo.

Livello 3 e 4: solo dopo aver chiuso i primi due

A questo punto, e solo a questo punto, ha senso il lavoro classico di front-end: immagini in formati moderni e dimensionate, lazy loading, riduzione e rinvio del JavaScript, font locali con font-display corretto, rimozione di CSS inutilizzato. Funziona, ed è spesso la parte visibilmente più gratificante. Ma farla su un sito con TTFB di 2 secondi significa dipingere la carrozzeria di un'auto senza benzina.

Il caso tipico del cambio hosting inutile

Ricreiamo lo scenario più comune. Sito lento, TTFB 1,8 secondi. L'intervento fatto: migrazione su hosting premium. Risultato: TTFB 1,6 secondi. Delusione giustificata: il collo di bottiglia era un plugin di prenotazioni che eseguiva 400 query per pagina. L'hosting nuovo esegue quelle stesse 400 query leggermente più in fretta, ma il costo strutturale resta.

Al contrario, il caso opposto: TTFB 900ms su hosting economico condiviso, sito aziendale con traffico stabile. Qui la migrazione su un piano con cache server-side nativa può portare il TTFB sotto i 200ms senza toccare una riga di codice. Stesso intervento, esiti opposti: la differenza la fa la diagnosi preliminare, non lo strumento.

Che cosa fare lunedì mattina

Se il tuo sito è lento e vuoi muoverti in autonomia, questa sequenza costa zero euro e mezza giornata:

  1. Misura il TTFB di homepage e di tre pagine interne, in tre momenti diversi della giornata
  2. Installa Query Monitor su staging (o in produzione in orario di basso traffico) e guarda tempo PHP vs tempo DB vs query esterne
  3. Verifica la dimensione dell'autoloading di wp_options
  4. Solo se i numeri indicano il front-end, apri PageSpeed Insights e lavora su LCP e INP
  5. Rimisura tutto dopo ogni modifica, e annota i numeri

Per approfondire il metodo c'è la nostra guida sulla diagnosi TTFB di WordPress, i Core Web Vitals misurati sui dati reali e gli errori comuni di caching. La pagina di servizio dedicata è velocizzare WordPress, mentre i costi trasparenti dei vari interventi sono nella pagina prezzi. Se il tuo WordPress è lento e hai dubbi di sicurezza, parti dalla panoramica sulla sicurezza e performance WordPress: a volte i due problemi condividono la stessa radice.

Quanto deve essere il TTFB ideale?

Sotto 200 millisecondi per contenuti statici o ben cachati, fino a 500 ms per pagine dinamiche complesse. Oltre 800 ms c'è quasi sempre un problema strutturale: cache assente, plugin pesante o hosting sottodimensionato.

Un plugin di cache può peggiorare le cose?

Sì, in tre casi: configurato male su hosting già con cache server-side (cache doppie che si invalidano a vicenda), su siti WooCommerce con paginazione personalizzata (pagine dinamiche cachate per errore), o su shared hosting con risorse minime dove il plugin stesso consuma memoria.

PageSpeed Insights mi dà punteggio basso ma il sito mi sembra veloce. Chi credo?

Entrambi possono avere ragione: il punteggio Lighthouse misura condizioni simulate con dispositivi mobili mediocri, la tua percezione nasce dal tuo dispositivo e connessione. Guarda i dati sul campo di Chrome UX Report (CrUX) dentro PageSpeed: quelli riflettono i visitatori veri.

Quanto incide davvero la velocità sulle vendite?

Le evidenze pubbliche convergono su un ordine di grandezza: ogni secondo aggiuntivo di caricamento riduce le conversioni in percentuali a doppia cifra sugli e-commerce. Ma il dato più affidabile resta il tuo: misura le conversioni prima e dopo gli interventi, sul tuo traffico reale.

Pubblicato il

Condividi

Scritto dal team WPsec.it

Team WPsec.it

Bonifica malware, hardening, performance e manutenzione WordPress.

Prevenzione e gestione

Dopo l'emergenza, o per non arrivarci: le guide sulla gestione.

Sicurezza, velocità e manutenzione di WordPress sono lo stesso lavoro visto da tre lati. Queste pagine spiegano cosa controllare, con quale priorità e quanto costa farlo fare.

Continua a leggere

Articoli correlati.