Un sito WordPress lento non ha un solo colpevole. Ne ha sei, e non costano tutti uguale: alcuni si portano via secondi interi, altri qualche decimo. La differenza tra chi sistema il sito in un'ora e chi ci perde tre giorni sta nell'ordine in cui si controllano le cose.
Risposta breve. Prima si misura il TTFB, il tempo che il server impiega a rispondere. Se è alto, il problema è a monte: hosting, database, chiamate esterne, plugin. Se è basso e la pagina pesa, il problema sono le immagini e i file che il browser deve scaricare. I sei colli di bottiglia, in ordine di quanto possono costare, sono: risposta del server, database, chiamate esterne, plugin, peso della pagina, cache che non copre tutti. Nessuno dei sei si risolve comprando un plugin: si risolvono misurando.
Questa guida li mette in fila, spiega quanto può costare ognuno, come si verifica in pochi minuti e quanto lavoro richiede la correzione. I numeri non sono stimati: sono casi reali, con la fonte accanto.
Come si misura dove va il tempo (due minuti, senza strumenti a pagamento)
Prima di toccare qualsiasi cosa serve un numero. Il numero più utile è il Time To First Byte (TTFB). È il tempo che passa tra la richiesta del browser e il primo byte di risposta che arriva dal server (la definizione di web.dev). Dice una cosa sola, ma decisiva: se il ritardo è prima dei file o dentro i file.
Come si misura il TTFB?
Si misura dal terminale, con una riga, ripetuta tre volte perché la prima chiamata paga anche la connessione. Niente -L: seguendo i redirect il tempo includerebbe anche il primo salto. E ricorda che una misura dal tuo computer contiene anche la tua rete: se il numero sembra strano, ripetila da un altro punto.
curl -s -o /dev/null -w "TTFB %{time_starttransfer}s — totale %{time_total}s\n" https://tuosito.it/
Il secondo numero è il peso della pagina. Nel browser, con gli strumenti per sviluppatori aperti sulla scheda Network, si ricarica la pagina: in basso compare il totale dei byte trasferiti. Su un articolo di testo ben fatto sta sotto il megabyte; su un sito lento spesso supera i 3 MB, e quasi sempre per colpa delle immagini.
Il terzo numero riguarda solo WordPress: quante query fa il database e quali sono lente. Lo dice un plugin di diagnostica, Query Monitor, che va attivato, letto e disattivato: mostra i suoi dati soltanto a chi è loggato come amministratore, quindi non pesa sui visitatori.
Cosa misuriComeValore accettabileTempo di risposta del servercurl con time_starttransfersotto 0,8 s (la soglia di web.dev)Peso della paginastrumenti del browser, scheda Networksotto 1 MB per un articoloQuery del databaseplugin Query Monitor, scheda Queriespoche decine, nessuna sopra 0,05 sPeso delle immaginiNetwork, ordina per dimensionesotto 150 KB ciascuna
Un esempio misurato su un articolo di questo sito, il 29 settembre 2026. TTFB tra 0,38 e 0,52 secondi su tre prove. 37 KB di HTML trasferiti. Sette immagini, la più pesante da 78 KB. Con questi tre numeri si sa già dove guardare.
1. La risposta del server: il collo di bottiglia che costa di più
È il primo della lista perché è quello che può costare più secondi in assoluto, e perché finché non è escluso tutte le altre misure sono inquinate. Se il server impiega cinque secondi a rispondere, nessuna ottimizzazione di immagini lo salverà.
Su un hosting condiviso il tempo di risposta dipende da quanto lavoro fanno PHP e il database insieme ad altri siti sullo stesso processore. Quando il piano è saturo, il sito rallenta anche senza che sia cambiato niente nel codice. Un post su LinkedIn racconta un caso preciso: «risposta del server a 891 ms, ben oltre gli 800 ms raccomandati, anche con un plugin di cache attivo (LiteSpeed Cache, che però fa page caching solo su server OpenLiteSpeed o LiteSpeed Enterprise: su Apache puro non copre la pagina)». La cache c'era. Non poteva però coprire il tempo che il server impiegava a elaborare la pagina.
Il secondo sospettato è il traffico che non è una persona. In un thread su r/Wordpress un utente con WooCommerce su hosting condiviso aveva CPU e processi «costantemente vicini al 100%» e un TTFB lunghissimo. Dopo le verifiche ha scoperto che il sito era martellato da un crawler. Il carico era traffico, non codice.
«Cloudflare aiuta solo dopo che il tuo server risponde. Se l'origine è lenta o sovraccarica, Cloudflare non può salvarla.»
commento nel thread «New WordPress site is slow», r/Wordpress, dicembre 2025
Perché una CDN non risolve un server lento?
È la frase che vale più di ogni classifica di CDN — con un'eccezione che va detta: il full page caching ai nodi di rete (Cloudflare APO e servizi simili) può servire l'HTML direttamente dalla rete, senza toccare il server d'origine, e lì la CDN copre anche la risposta. Un piano gratuito di CDN, invece, di solito si ferma ai file statici: è il caso descritto qui. Quando gli strumenti di test online non completano nemmeno la misura e rispondono con un timeout, il problema è la risposta del server. Va risolto lì.
Come si verifica
- TTFB sopra 0,6 s su tutte e tre le prove: il problema è a monte, non nelle immagini.
- TTFB basso dal tuo computer e alto da un servizio esterno di test: il problema è il percorso di rete o il piano.
- TTFB che peggiora a orari precisi: qualcun altro sul server sta usando le risorse, oppure arriva un crawler.
2. Il database: la tabella che cresce in silenzio
WordPress costruisce ogni pagina con delle query. Finché il database è piccolo rispondono in millisecondi; quando una tabella cresce a dismisura, le stesse query diventano lente e il TTFB sale. Il segno tipico è un sito che rallenta nel tempo, senza un intervento preciso che lo spieghi.
Le tre tabelle da guardare sono sempre le stesse. wp_options contiene le impostazioni, comprese quelle che WordPress carica automaticamente a ogni pagina (autoload): più opzioni entrano in quel gruppo, più lavoro si fa a ogni visita. wp_postmeta cresce con revisioni e metadati, e su Stack Exchange la query più lenta segnalata in un log reale è un aggiornamento della riga _edit_lock, banale e ripetuto. La terza è la tabella che il plugin scrive.
Su r/Wordpress c'è chi lo dice chiaramente: «i plugin che scrivono log nel database sono tra i peggiori, se non svuoti la tabella arriva a milioni di righe».
Non è solo una questione di quantità di dati. Sulla sezione WordPress di Stack Exchange una domanda con 16 voti riguarda un sito con oltre 10.000 articoli che rallentava solo in scrittura. La tabella era MyISAM, il motore senza transazioni. Il passaggio a InnoDB cambiava il comportamento. Un'altra, con 65 voti, misura l'ambiente. «A ogni pagina vengono allocati circa 20 MB di RAM solo per preparare l'ambiente in cui girano i plugin» (Refactoring WordPress to improve memory performance). Non è il contenuto a pesare, è la struttura che lo serve.
Come si verifica
- Query Monitor attivo sull'articolo più lento: le query totali e quelle sopra 0,05 s.
- Revisioni e transients accumulati: si vedono dal database, o da un plugin di pulizia, prima di cancellarli.
- Tabelle di log dei plugin: se crescono e nessuno le pota, sono un costo fisso a ogni pagina.
3. Le chiamate esterne fatte dal server: il ritardo che non vedi
Questo è il collo di bottiglia più difficile da immaginare, perché non compare in nessun grafico e non dipende né dal tuo codice né dal tuo hosting. È il tempo che WordPress passa aspettando un altro sito.
Un tema che va a prendere il font dal sito del produttore. Un plugin che verifica la licenza all'avvio. Un controllo di aggiornamento. In tutti e tre i casi la richiesta parte dal tuo server, non dal browser del visitatore. Se il sito dall'altra parte è lento o irraggiungibile, la tua pagina aspetta.
In un thread su r/Wordpress, «Admin console is slow, but site works fine», la causa trovata è esattamente questa. WordPress interroga api.wordpress.org per gli aggiornamenti quando si apre il pannello di amministrazione. Nello stesso thread, un altro utente ha misurato il caso estremo su un server con firewall: con la riga define('WP_HTTP_BLOCK_EXTERNAL', true); in wp-config.php ha tagliato 20 secondi di attesa.
La documentazione ufficiale di WordPress descrive la costante nella pagina su wp-config.php. Va usata con criterio: blocca tutte le chiamate in uscita, quindi anche quelle che servono (aggiornamenti, newsletter, pagamenti).
Come si verifica
- Il pannello di amministrazione è lento ma il sito pubblico è veloce: qui si guarda per primo.
- Un tema o un plugin che contatta un servizio esterno all'apertura di una pagina.
- Blocco temporaneo delle chiamate esterne e nuova misura: se il TTFB crolla, hai trovato il colpevole.
4. I plugin: non conta quanti, conta quanto lavorano a ogni pagina
Quanti plugin sono troppi?
La frase «hai troppi plugin» è il modo più rapido per chiudere una discussione sulla lentezza. Spesso è una scorciatoia. Ci sono siti con più di ottanta plugin che vanno veloci. E ci sono siti con due plugin che impiegano venti secondi. È documentato in entrambe le direzioni nello stesso thread di Reddit. Un utente racconta «un sito con 80-100 plugin» senza problemi. Un altro risponde: «384, di cui 320 scritti da me: è veloce».
Il caso opposto è più istruttivo: «My Site is slow despite only 2 plugins», con Elementor e Blocksy e una pagina che si apriva in 19-20 secondi. Quando il numero di plugin è basso, l'ipotesi «sono troppi» non si può nemmeno formulare: si guarda cosa fa ognuno.
Quello che conta è il lavoro che un plugin aggiunge a ogni pagina. In un thread del 2023 un amministratore ha misurato il proprio caso. «Ogni plugin che aggiungo aumenta il tempo di caricamento del pannello di circa un quarto o mezzo secondo», racconta, «e non importa quanto sia grande o piccolo il plugin». È una misura sul pannello, non sul sito pubblico, ma spiega bene perché il backend di certi siti sia inutilizzabile.
Due dettagli chiudono il capitolo. Il primo: i plugin disattivati non rallentano niente. Su Stack Exchange è una domanda con 60 voti, e la risposta è che il loro codice non viene eseguito. Restano un problema di ordine e di sicurezza, non di velocità. Il secondo: la dimensione conta più del numero. In un thread con ticket di assistenza reali si legge «All (85) | Active (74) | Inactive (11)» come diagnosi. C'è però un criterio opposto, che va preso per quello che è: «se la cartella dei plugin supera i 60 MB, il problema è lì». Non è una misura di prestazioni — una cartella grande dice che c'è roba da guardare, non che quella roba rallenta: è un indizio di ordine.
«Il numero di plugin installati contribuisce direttamente al TTFB. Ma quello che i singoli plugin fanno rallenta il sito ancora di più.»
thread «Do hosting companies use "too many plugins" as an excuse?», r/Wordpress
Come si verifica
- Query Monitor, vista Query by component: dice quale plugin o tema consuma il tempo della pagina.
- Disattivazione a gruppi e misura dopo ogni gruppo — non «disattivo tutto e vedo».
- Peso della cartella
wp-content/plugins: è un indizio grezzo ma immediato.
5. Le immagini e i file che scarica il browser
Perché le immagini pesano più di tutto?
Quando il TTFB è buono e la pagina resta lenta, il tempo si sposta nel browser del lettore: sta scaricando. Qui il colpevole numero uno sono le immagini non ottimizzate. La differenza si misura in fattori, non in percentuali.
Il caso più documentato arriva da r/webdev. Un sito «che a volte impiegava 7-8 secondi» per caricare una pagina, con immagini pesanti, un tema gonfio, nessuna cache e più di dodici plugin non necessari. Dopo compressione delle immagini, tema leggero e cache, la stessa pagina si apriva in 1,9 secondi. Un altro utente, con lo stesso percorso, dichiara 1,6. La chiusura di quel post è la parte da portarsi a casa: «non incolpare sempre l'hosting per primo».
Sul nostro sito la conversione delle immagini da PNG a WebP ha portato una copertina da 595 KB a 22 KB. La versione servita ai telefoni è passata da 346 KB a 16 KB. È lo stesso ordine di grandezza dei «600 KB → 40 KB» che si vedono nelle guide, e si ottiene senza cambiare hosting, senza cambiare tema e senza comprare niente. I dettagli operativi stanno nella guida su come migliorare le prestazioni di WordPress.
Accanto alle immagini ci sono i file che il tema carica. Fogli di stile e script di plugin che non servono su quella pagina. Font presi da un servizio esterno. Librerie intere per usare una funzione sola. Sono le stesse risorse che pesano sul tempo di risposta quando vengono chieste dal server, e pesano di nuovo qui, quando le scarica il lettore.
Come si verifica
- Network, ordinate per peso: le prime tre voci spiegano da sole metà della pagina.
- Formato e dimensioni reali delle immagini: un file da 4000 pixel mostrato a 800 è peso regalato.
- Font e script di terze parti: quante connessioni esterne apre la pagina.
6. La cache che non copre chi è loggato
Il sesto collo di bottiglia è il più insidioso, perché convive con un sito che sembra a posto. La cache serve una copia già pronta della pagina, ma solo a chi non è riconosciuto come utente collegato. Tu sei l'eccezione: quando entri, la pagina viene ricostruita ogni volta.
Perché il sito è lento solo quando sono loggato?
Se ti sembra che il sito sia veloce per tutti tranne che per te, la spiegazione è qui. Da qui nascono due sintomi che confondono chiunque. Il primo: «il sito è veloce, è lento solo il pannello». Nel thread già citato l'utente misura oltre 5 secondi nel pannello contro 1-2 secondi sul sito pubblico — e, una volta loggato, anche il sito pubblico gli sembrava lento. Il secondo: la sensazione di aver perso tempo con la cache, perché «anche con la cache attiva» resta il ritardo visto prima.
C'è anche un errore tecnico frequente: la cache configurata male. Le regole generali stanno nella documentazione di WordPress sulla cache. Nel caso raccontato su LinkedIn, il plugin di cache LiteSpeed girava su un server Apache. Le pagine di amministrazione finivano in cache insieme a quelle pubbliche. L'ordine delle regole di .htaccess lasciava partire PHP prima della cache. Il plugin funzionava: era la configurazione a non servire a niente.
Come si verifica
- Misura la stessa pagina da anonimo e da collegato: la differenza è quanto la cache ti sta nascondendo.
- Controlla che la cache dell'HTML sia attiva, non solo quella dei file statici.
- Verifica che il pannello di amministrazione non finisca in cache.
La classifica: quanto costa ogni collo di bottiglia
Messi in fila, i sei colli di bottiglia si distinguono per due cose: quanto possono costare in secondi e quanto lavoro serve per sistemarli. La tabella seguente riassume i casi reali citati in questa guida.
Collo di bottigliaCosto osservatoLavoro per correggerlo1. Risposta del server (TTFB)da 891 ms su hosting saturo fino a 19-20 s con due plugin e un page builderda basso (trovare il carico) ad alto (cambiare piano o fornitore)2. Databasequery ripetute su tabelle cresciute a milioni di righemedio: pulizia, potatura dei log, motore delle tabelle3. Chiamate esterne dal serverfino a 20 secondi in un caso misuratobasso: una costante, con criterio4. Pluginun quarto o mezzo secondo per plugin, sul pannellomedio: uno per uno, con una misura dopo ogni gruppo5. Immagini e fileda 7,3 s a 1,9 s sulla stessa paginabasso: conversione dei formati e delle dimensioni6. Cache che non copre5+ s da collegato contro 1-2 s da anonimomedio: capire chi non è coperto e perché
Il consiglio pratico che esce dalla classifica è l'ordine: si scende dall'alto verso il basso e ci si ferma al primo collo di bottiglia che spiega il ritardo. Se il TTFB è sotto 0,8 secondi e la pagina pesa 4 MB, non serve a niente discutere di hosting: serve alleggerire la pagina.
Se il sospetto cade sull'hosting, la matrice che incrocia sintomi e cause sta nell'articolo su WordPress lento: cause e rimedi del sito che rallenta. Qui l'ordine è diverso: non «quale errore di hosting», ma «quale dei sei colli di bottiglia si sta mangiando il tempo».
Cosa non serve fare (e cosa rimandare)
Alcuni interventi sono inutili, altri sono giusti ma prematuri. Vale la pena dirlo, perché sono quelli che consumano più tempo.
- Disattivare i plugin «per vedere se è colpa loro» senza misurare. I plugin disattivati non vengono eseguiti, quindi il sito torna veloce per finta: manca il dato di quanto pesava ognuno. Si misura prima, con Query Monitor, e poi si disattiva.
- Cambiare hosting prima di aver misurato. Il caso da 7,3 a 1,9 secondi si è risolto restando sullo stesso hosting. Il caso da 19-20 secondi, invece, non si spiegava con il numero dei plugin: erano due soli, con un page builder che faceva il lavoro pesante
- Attivare una CDN per coprire un server lento. Aiuta per i file statici e per i visitatori lontani; non tocca il tempo che il server impiega a costruire la pagina.
- Rincorrere il punteggio di PageSpeed. Gli strumenti di test sono di monitoraggio, non di ottimizzazione: dicono cosa migliorare, non cosa conviene migliorare.
Due cose invece vanno rimandate con calma. La migrazione a un altro hosting: è una decisione costosa e va presa con i numeri in mano. La riscrittura del tema: si fa dopo aver capito se il tema è davvero il collo di bottiglia.
Domande frequenti
In sintesi
- Prima di toccare qualsiasi cosa, misura il TTFB: separa il tempo del server da quello del browser.
- I sei colli di bottiglia vanno controllati in ordine: server, database, chiamate esterne, plugin, peso della pagina, copertura della cache.
- Il numero di plugin, da solo, non spiega niente: conta quanto lavorano a ogni pagina.
- Le immagini sono il collo di bottiglia più economico da risolvere: da centinaia di KB a poche decine, senza cambiare nulla di strutturale.
- Chi è loggato non riceve la pagina in cache: se il pannello è lento e il sito no, la diagnosi parte da lì.
Ultimo aggiornamento: settembre 2026. I numeri citati vengono da casi pubblici verificati nelle community tecniche, non da un sito di prova: sono citati con la fonte dove questa ha un indirizzo pubblico, e per il resto con il caso e la data.
