Un sito è lento quando il server impiega troppo a preparare la pagina o il browser impiega troppo a scaricarla e disegnarla, e nella maggior parte dei casi la colpa è di una cache che non lavora, di risorse pesanti, di script di terze parti o di un server sotto carico. Per capire quale di queste è la tua, la domanda utile è lento per chi, dove e da quando: ogni risposta esclude metà delle cause.
Detta così sembra ovvia.
Eppure la reazione tipica è un'altra: si apre il sito, sembra lento, si installa un plugin di cache o si chiede un preventivo per cambiare hosting. A volte funziona. Spesso no, perché si è curato il sintomo sbagliato.
Gli errori che vediamo più spesso sono tre:
- misurare da loggati nel pannello di WordPress, cioè giudicare una versione del sito che i visitatori non vedono mai;
- cambiare hosting quando il rallentamento viene da un plugin, o riscrivere il tema quando il problema è del provider;
- comprimere le immagini mentre il server risponde a migliaia di richieste di bot che in Google Analytics non compaiono.
I progetti che seguiamo ce lo ricordano. Il negozio online di Scovaventi riceveva visite ma non vendeva: pagine lente, un CMS poco adatto allo smartphone, un checkout che faceva abbandonare il carrello. Rifatto lo store su Shopify, in dodici mesi ha generato 77.000 € di vendite con un carrello medio di 190 €.
Bosatta, che produce ricambi per Vespa e moto del gruppo Piaggio, aveva un collo di bottiglia simile su un CMS obsoleto: dopo il nuovo percorso d'acquisto ha venduto 240.000 € in un anno su quattro mercati.
E cosa c'entra con la velocità?
In entrambi i casi la lentezza non si risolveva comprimendo le foto: il problema era la piattaforma. È stata la diagnosi a decidere l'intervento, non la lista dei consigli.
Qui trovi:
- cosa coprono le otto guide italiane in prima pagina per "sito lento", e cosa saltano tutte;
- una tabella sintomo, causa, primo controllo da usare prima di toccare qualsiasi cosa;
- il nostro test sul tempo di risposta di visilay.com con e senza il cookie di login;
- i numeri sul traffico dei crawler AI, che nessuna guida italiana nomina;
- cosa guardare quando è lento solo il pannello di amministrazione.
Partiamo.
Cosa coprono le guide italiane su "sito lento" (e i cinque casi che saltano)
Il 9 ottobre 2026 abbiamo letto i risultati che Google.it mostra da mobile per "sito lento", esclusi video e forum. Su nove pagine, otto avevano un testo leggibile (l'helpdesk di IKIweb lo mostra solo con JavaScript attivo). Per ognuna abbiamo segnato se tratta cinque situazioni in cui un sito è lento solo per qualcuno o solo in certi momenti.
| Guida | Utente loggato | Bot e crawler AI | Solo area admin | Lento all'improvviso | Solo da mobile |
|---|---|---|---|---|---|
| supporthost.com | no | accenno | no | no | no |
| metaline.it | no | no | no | no | accenno |
| mirkociesco.it | no | no | no | no | sì |
| tophost.it | no | no | no | accenno | no |
| hostingvirtuale.com | no | no | no | no | sì |
| devergency.com | no | no | no | no | no |
| armandoferrandino.it | no | no | no | no | accenno |
| effettispeciali.com | no | no | no | no | sì |
| Totale | 0 su 8 | 0 su 8 (1 accenno) | 0 su 8 | 0 su 8 (1 accenno) | 3 su 8 (2 accenni) |
Tutte e otto elencano più o meno le stesse cause: hosting economico, immagini pesanti, troppi plugin, cache assente. È anche quello che ripete l'AI Overview sopra i risultati. Sono cause vere, ma presuppongono un sito lento sempre e per tutti, che è solo uno dei casi possibili.
Nella SERP americana per "why is my website slow" il quadro è simile, con un'eccezione: la guida di Calibre firmata da Karolina Szczur e aggiornata a maggio 2026 dedica una sezione al traffico aggressivo di bot e crawler AI. In italiano non l'ha ancora fatto nessuno.
Il sintomo dice dove cercare (la tabella dei primi dieci minuti)
La lentezza ha quasi sempre un "dove" e un "quando". Questa è la tabella che usiamo prima di aprire qualsiasi strumento di test.
| Sintomo | Causa più probabile | Primo controllo |
|---|---|---|
| Lento solo per te, veloce in incognito o da un altro telefono | Sessione di login che salta la cache, estensioni del browser, rete | Stessa pagina in una finestra in incognito e da rete mobile |
| Lento all'improvviso, da un giorno all'altro | Aggiornamento di plugin o tema, nuovo script, guasto del provider | Cosa è cambiato nelle ultime 48 ore; un altro sito sullo stesso hosting |
| Lento a ondate, con CPU o banda alte ma visite normali in Analytics | Bot e crawler AI | Log di accesso del server raggruppati per user agent |
| Lento solo il pannello di WordPress | Opzioni in autoload, Heartbeat, plugin pesanti nel backend | Strumenti > Salute del sito; plugin Query Monitor |
| Lento solo da mobile | JavaScript che occupa il processore del telefono | INP nel report Segnali web essenziali di Search Console |
| Lente solo alcune pagine | Filtri, ricerca interna, parametri nell'URL che la cache non serve | Stessa pagina con e senza parametri |
| Lento sempre, per tutti | Caricamento: server, scoperta e peso delle risorse | Scomposizione dell'LCP in PageSpeed Insights |
Le sezioni che seguono prendono le righe una per una.
Lento solo per te? Prima esci dal pannello di WordPress (il nostro test)
Quando sei collegato all'area riservata di WordPress, il browser invia a ogni pagina un cookie di login e i sistemi di cache trattano quella visita come personale: la copia pronta della pagina, quella che ricevono i visitatori, a te non viene servita. Il server la ricostruisce, oppure usa una cache privata solo tua.
Quanto cambia, in pratica?
L'abbiamo misurato su visilay.com.
| Pagina | Visitatore senza login (mediana) | Con cookie di login (mediana) | Rapporto |
|---|---|---|---|
| Home page | 77 ms | 318 ms | 4,1 volte |
| Articolo del blog | 49 ms | 308 ms | 6,3 volte |
| Pagina servizio | 45 ms | 286 ms | 6,4 volte |
Con il cookie la risposta è da quattro a sei volte più lenta, e nel caso peggiore ha toccato 2,2 secondi, contro un massimo di 151 ms per la home servita dalla cache.
Per i visitatori, il sito era sempre lo stesso.
Alcuni plugin attenuano l'effetto. LiteSpeed Cache, per esempio, ha l'opzione Cache Logged-in Users attiva di default, che conserva una copia privata per ciascun utente: dalla seconda visita va meglio, ma resta una cache diversa da quella del pubblico.
La regola che ne esce è semplice: la velocità si giudica in una finestra in incognito, meglio ancora da un telefono su rete mobile. Se lì il sito è veloce, il problema non è il sito.
Lo stesso vale per la tua connessione. Se rallentano anche gli altri siti, il collo di bottiglia è la rete o il browser, e le estensioni che bloccano o aggiungono script sono un classico. I dati AGCOM che citiamo nella guida al page speed dicono che in Italia la banda mobile raramente è il limite; il Wi-Fi dell'ufficio, a volte, sì.
Lento all'improvviso? Cerca cosa è cambiato (anche fuori dal tuo sito)
Un sito che ieri andava e oggi no ha quasi sempre una causa con una data: un aggiornamento automatico di plugin o tema, uno script aggiunto per una campagna, una modifica alla configurazione del server, a volte un'intrusione (sui segnali da riconoscere c'è la guida alla sicurezza del sito web). La prima domanda è cosa è successo nelle ultime 48 ore e chi ha accesso al sito.
A volte, però, sul sito non è cambiato niente.
A novembre 2025 un produttore B2B che seguiamo ci scrive: il sito è improvvisamente lento. Il sospetto cade sul page builder, fermo a una versione vecchia. Backup, aggiornamento, nessun miglioramento. Negli strumenti di WordPress compare un errore preciso, cURL error 28: Operation timed out after 10001 milliseconds: il server non riusciva a completare le connessioni in uscita entro 10 secondi.
Il controllo che ha chiuso la diagnosi è durato un minuto: abbiamo aperto il sito di un altro cliente ospitato dallo stesso provider. Lento anche quello. Il guasto era del fornitore di hosting, e nessun intervento su plugin o codice l'avrebbe risolto.
Da allora, davanti a un "il sito è lento da stamattina", il primo passo è quello: un altro sito sullo stesso hosting e la pagina di stato del provider, prima di toccare tema e plugin.
C'è anche un motivo SEO per non lasciar correre. Nella guida alla gestione del crawl budget, aggiornata a luglio 2026, Google scrive che quando un sito rallenta o risponde con errori 5xx e 429 il limite di capacità di scansione si abbassa e Googlebot scansiona meno. Un server in affanno per giorni rallenta anche l'ingresso delle pagine nuove nell'indice: il meccanismo è spiegato nella guida al crawling.
Il traffico che Analytics non vede: bot e crawler AI (e quanto costano a un server)
I crawler AI sono i programmi con cui OpenAI, Anthropic, Perplexity e gli altri scaricano le pagine web per addestrare i modelli o costruire le risposte. Quasi nessuno esegue JavaScript, quindi non compaiono in Google Analytics: per il server sono visite vere, per i tuoi report non esistono.
I numeri disponibili sono tutti rilevati fuori dall'Italia, su reti e siti con traffico globale:
- Sulla rete di Vercel, in un mese di fine 2024, GPTBot ha fatto 569 milioni di richieste e il crawler di Claude 370 milioni, insieme circa il 20% del volume di Googlebot. Il 34,8% delle richieste di ChatGPT finiva su pagine 404, contro l'8,2% di Googlebot.
- Read the Docs, che ospita la documentazione di migliaia di progetti open source, ha visto un solo crawler scaricare 73 TB di file a maggio 2024, quasi 10 TB in un giorno, con oltre 5.000 dollari di costi di banda. Bloccati i crawler, il traffico dei download è sceso del 75%, da circa 800 a 200 GB al giorno (Eric Holscher, Read the Docs).
- La Wikimedia Foundation ha calcolato che i bot generano circa il 35% delle pagine viste ma almeno il 65% del traffico più costoso da servire, e che la banda per i file multimediali è cresciuta del 50% da gennaio 2024.
- Secondo Cloudflare, nei dodici mesi fino a luglio 2025 l'80% della scansione dei crawler AI serviva ad addestrare i modelli. A luglio 2025 Anthropic faceva circa 38.000 scansioni per ogni visita rimandata al sito, OpenAI circa 1.100.
E in Italia? Abbiamo contato i bot sul nostro sito: tra il 31 agosto e il 27 settembre 2026, su circa 199.000 righe di log di visilay.com, i bot di OpenAI hanno fatto 4.773 richieste, più di tre volte le 1.355 di Googlebot. Il metodo è spiegato nell'articolo sui crawler AI linkato più sotto.
Il dettaglio dei 404 è quello che pesa di più su un sito piccolo. Una pagina inesistente spesso non è in cache, quindi ogni URL vecchio o inventato che un crawler richiede viene elaborato da zero da PHP e database.
Il segnale da cercare lo descrive bene la guida di Calibre: picchi di CPU o di banda senza un aumento corrispondente delle visite in Analytics. A quel punto servono i log di accesso del server raggruppati per user agent, e di solito bastano pochi minuti per vedere chi sta chiedendo cosa.
E allora li blocco tutti?
Non per forza. Bloccare GPTBot o ClaudeBot nel robots.txt riduce il carico, ma toglie i tuoi contenuti alle fonti da cui le AI costruiscono le risposte: per un'azienda che vuole comparire in ChatGPT è un costo. La via ragionevole di solito sta nel mezzo: limitare la frequenza delle richieste con il firewall del CDN, servire le pagine dalla cache anche ai bot, chiudere solo i crawler che non portano niente. Come riconoscerli lo spieghiamo nell'articolo sui crawler AI.
Il tuo server lavora per visitatori che non vedi?
Hai appena visto come un solo crawler può scaricare in un giorno più di quanto un sito serva in mesi ai clienti veri. Leggiamo i log del tuo server, separiamo persone, Googlebot e crawler AI e ti diciamo cosa limitare senza sparire dalle risposte di ChatGPT e Google.
Prenota una consulenza strategicaLento solo il pannello di WordPress: il problema sta dietro le quinte (autoload e Heartbeat)
Se il sito pubblico è veloce ma l'area di amministrazione no, il caricamento delle pagine c'entra poco. Secondo W3Techs, a ottobre 2026 WordPress è usato dal 40,1% di tutti i siti web e dal 58,6% di quelli con un CMS riconoscibile: è il caso che incontriamo più spesso.
Le cose da controllare per prime sono due.
1. Le impostazioni caricate a ogni richiesta
WordPress carica in memoria, a ogni richiesta, un gruppo di impostazioni marcate "autoload", e i plugin disinstallati spesso ne lasciano dietro di sé. Dalla versione 6.6, uscita a luglio 2024, le opzioni più grandi di 150 KB non vengono più caricate automaticamente e la pagina Strumenti > Salute del sito avvisa quando il totale supera gli 800 KB (nota tecnica di Paul Bearne e Joe McGill sul blog del core). Se vedi quell'avviso, hai trovato un indiziato.
2. Le richieste che il pannello fa da solo
L'API Heartbeat tiene aggiornato il pannello (salvataggi automatici, blocco dei post in modifica, notifiche) mandando una richiesta al server a intervalli tra 15 e 120 secondi, secondo la documentazione per sviluppatori. Dieci schede dell'editor aperte da tre persone fanno decine di richieste al minuto che nessuna cache può servire, e su un hosting condiviso si sentono.
Per capire quale plugin rallenta una schermata serve Query Monitor, che mostra il tempo di ogni chiamata al database e chi l'ha fatta. Molti di questi problemi nascono al momento di scegliere il CMS e il tema, molto prima che qualcuno se ne lamenti.
Lento solo da mobile o solo su alcune pagine (qui il server è innocente)
Quando il sito è lento solo da smartphone, quasi sempre il collo di bottiglia è il processore del telefono, occupato dal JavaScript di temi, chat, pixel e strumenti di tracciamento. Lo misura l'INP, la metrica di reattività dei Core Web Vitals: nella guida al page speed mostriamo come il divario tra desktop e mobile si concentri proprio lì. Era anche il caso di Scovaventi, dove il vecchio CMS rendeva il negozio poco adatto allo smartphone.
Quando sono lente solo alcune pagine, guarda l'URL. Filtri di un e-commerce, ordinamenti e ricerca interna aggiungono parametri, e molte configurazioni di cache trattano ogni combinazione come una pagina nuova da generare.
Nel primo giro del nostro test su visilay.com, la stessa pagina con un parametro casuale aggiunto all'URL ha risposto in 253-269 ms, contro i 70-85 ms della versione servita dalla cache: lo stesso salto del cookie di login. Su un catalogo con migliaia di combinazioni di filtri, e con i crawler che le seguono tutte, il conto cresce in fretta.
Le altre pagine lente per costruzione sono quelle con video incorporati, mappe e moduli di terze parti: ognuno si porta dietro file da domini esterni che non controlli.
Lento sempre e per tutti: allora è il caricamento (e si lavora per fasi)
Se il sito è lento in incognito, da mobile e da desktop, a qualsiasi ora, sei nell'ultima riga della tabella. Qui le cause delle guide in prima pagina sono quelle giuste, ma l'ordine conta più della lista.
Google considera buono un tempo al primo byte fino a 0,8 secondi (web.dev): se sei sopra, il lavoro parte dal server e dalla cache, non dalle immagini. Se il server risponde in fretta ma il contenuto principale compare tardi, il problema è come il browser scopre e scarica le risorse. La procedura completa, fase per fase, è nella guida su come velocizzare un sito web, e per le foto c'è quella sull'ottimizzazione delle immagini.
A volte la causa è più banale di quanto sembri. Su un gruppo di siti B2B che seguiamo, l'elemento più grande della pagina per Google era il banner dei cookie: ridotto dalla console della piattaforma di consenso, le segnalazioni sull'LCP si sono chiuse. Nessun cambio di hosting, nessuna riscrittura del tema.
Questi controlli fanno parte della SEO tecnica che curiamo nei progetti di consulenza SEO. E quando il problema è la piattaforma, come per Scovaventi e Bosatta, la velocità si decide prima della messa online, nei progetti di sviluppo siti web.
Domande frequenti sul sito lento
Dipende: la velocità è uno dei segnali di esperienza della pagina, ma Google scrive che buoni risultati nei report non garantiscono il posizionamento e che il contenuto più pertinente può vincere anche con una page experience scadente. L'effetto più diretto è un altro: un server lento o che risponde con errori 5xx riduce quanto Googlebot scansiona e rallenta l'indicizzazione delle pagine nuove.
Dipende: risolve se il tempo al primo byte resta alto anche con la cache attiva, o se il provider ha guasti ricorrenti. Non risolve se la lentezza viene da script, immagini o plugin: un server più potente genera solo un po' più in fretta la stessa pagina pesante.
No, se in incognito e da un altro dispositivo è veloce. Da loggato il cookie di accesso fa saltare la cache pubblica: nel nostro test su visilay.com la risposta era da 4 a 6 volte più lenta. È quello che vedi tu, non quello che vedono i clienti.
Sì, se sono loro a saturare il server: Read the Docs ha ridotto del 75% il traffico dei download bloccandoli. Il costo è sparire dalle fonti che ChatGPT, Claude e Perplexity usano per rispondere, quindi conviene prima limitare la frequenza delle richieste e bloccare solo chi non porta visite.
No. Serve la pagina già pronta ai visitatori anonimi, ma non aiuta il pannello di amministrazione, le pagine con parametri nell'URL, gli utenti loggati e il JavaScript che rallenta il telefono. È il primo intervento sul tempo di risposta, non l'unico.
Riepilogo in cinque righe (e chi sta davvero visitando il tuo sito)
Lento per chi: si misura in incognito, mai da loggati.
Lento da quando: cerca la data, anche fuori dal sito.
Lento con visite normali: guarda i log, non Analytics.
Lento solo nel pannello: autoload, Heartbeat e plugin del backend.
Lento sempre: server, cache e immagini, in quest'ordine.
Dieci anni fa la domanda "perché il mio sito è lento" aveva una risposta che riguardava solo le persone. Oggi una parte di chi visita il sito non è una persona, e decidere quanti di questi visitatori servire, con che priorità e in cambio di cosa è una scelta di marketing prima che tecnica. Chi la lascia all'impostazione predefinita dell'hosting la sta facendo comunque, solo senza saperlo.
Se vuoi capire quale riga della tabella è la tua, la guardiamo insieme in una consulenza, partendo dai dati del tuo server e di Search Console. Alla prossima!
