Sito lento: 6 cause reali e come risolverle

Un sito lento raramente ha una sola causa. Nella maggior parte dei casi ne ha tre o quattro che si sommano, e il motivo per cui gli interventi “standard” non funzionano è che si aggredisce la quarta in ordine di importanza lasciando intatta la prima.

Questa guida parte da un presupposto diverso rispetto alle solite liste di consigli: prima si misura, poi si capisce quale delle sei cause reali sta pesando sul tuo sito, e solo dopo si tocca qualcosa. Le sei cause coprono, per esperienza diretta su siti WordPress in produzione, la quasi totalità dei casi. Per ognuna trovi come riconoscerla con certezza, perché si verifica e cosa fare concretamente per risolverla.

Una premessa operativa: prima di modificare configurazioni, plugin o codice del tema, fai un backup completo del sito e lavora su staging quando possibile. Le ottimizzazioni di performance sono tra le più facili da rompere in modo silenzioso.

Prima di tutto: “lento” rispetto a cosa

La percezione di lentezza non è un dato. Prima di intervenire serve un numero, e serve il numero giusto: quello che raccoglie l’esperienza degli utenti reali, non quello di un test simulato eseguito una volta dal tuo ufficio con la fibra.

Le tre metriche che contano davvero

Google valuta l’esperienza di caricamento con tre Core Web Vitals. Se hai letto materiale scritto prima del 2024, attenzione: FID (First Input Delay) non esiste più. È stato sostituito da INP il 12 marzo 2024, ed è una sostituzione sostanziale, non un cambio di nome. FID misurava solo il ritardo della prima interazione; INP misura la reattività di tutte le interazioni della sessione, ed è molto più severo.

A queste si aggiunge il TTFB (Time To First Byte), che non è un Core Web Vital ma è la metrica diagnostica più utile in assoluto: misura quanto ci mette il server a rispondere. La soglia di riferimento è 800 ms. Se il TTFB è sopra, qualsiasi ottimizzazione front-end che farai partirà già in debito.

Gli strumenti, e cosa chiedere a ciascuno

• PageSpeed Insights — l’unico strumento che ti mostra insieme i dati di campo (utenti reali, finestra mobile di 28 giorni) e quelli di laboratorio. Guarda sempre la sezione in alto, quella dei dati reali. È l’unica che conta per il posizionamento.
• Search Console → Segnalazioni sull’esperienza sulla pagina — ti dice quali gruppi di URL hanno problemi. Fondamentale, perché quasi mai il problema è sulla home: di solito è sui template (archivio, scheda prodotto, articolo).
• Lighthouse nei DevTools di Chrome — per capire perché, non quanto. Il pannello Performance con throttling attivo è dove si trovano le risposte.
• Query Monitor (plugin) — indispensabile lato server: query lente, hook costosi, tempo di generazione della pagina, e soprattutto quale plugin sta consumando cosa.

L’errore da non fare: inseguire il punteggio

Il punteggio di Lighthouse è un indice sintetico calcolato su una simulazione. Un sito con 100/100 in laboratorio e LCP reale a 4 secondi è un sito lento. Un sito con 72/100 e tutti e tre i Core Web Vitals in verde sui dati di campo è un sito veloce. Ottimizza i dati di campo e ignora il resto: il punteggio è una conseguenza, non un obiettivo.

Causa 1 — L’hosting non regge e il TTFB è alto

È la causa più frequente e la più sottovalutata, perché non si vede: il browser resta semplicemente fermo su una pagina bianca ad aspettare il primo byte. È anche l’unica che non puoi compensare a valle. Se il server impiega 1,5 secondi a rispondere, il tuo LCP non scenderà mai sotto 1,5 secondi, per quanto tu ottimizzi le immagini.

Come riconoscerla

Apri i DevTools, scheda Network, ricarica con la cache disattivata e guarda il campo Waiting for server response della prima richiesta HTML. Oppure, più rapidamente:

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

Ripeti la misura tre o quattro volte, anche su una pagina interna e non solo sulla home. Sopra 800 ms hai un problema; sopra 1,5 secondi hai il problema principale del tuo sito.

Perché succede

• Hosting condiviso saturo. Centinaia di siti sulla stessa macchina: le risorse dichiarate nel piano sono un massimo teorico, non una garanzia.
• Versione di PHP vecchia. Il salto da PHP 7.4 a PHP 8.2+ vale da solo un miglioramento consistente sul tempo di generazione della pagina, a costo zero.
• OPcache disattivato o object cache persistente assente (Redis, Memcached). Senza, WordPress ricompila e ri-interroga tutto a ogni richiesta.
• Server geograficamente lontano dal tuo pubblico. Un sito rivolto all’Italia ospitato negli Stati Uniti paga 100-150 ms di sola latenza di rete su ogni richiesta.
• Database gonfio. Revisioni accumulate, tabelle di plugin disinstallati, transient scaduti mai puliti, opzioni in autoload fuori controllo.

Ce n’è una sesta che non dipende dalla configurazione: il traffico automatizzato. Migliaia di richieste al minuto su endpoint che la cache non può servire — il login, la ricerca interna, admin-ajax.php — saturano i worker PHP e fanno salire il TTFB mentre le immagini continuano a caricare normalmente. Se la lentezza arriva a ondate invece che in modo costante, vale la pena guardare i log prima della configurazione.

Come risolverla

Nell’ordine, dal meno invasivo al più impegnativo:

1. Aggiorna PHP all’ultima versione supportata dal tuo stack. Verifica prima la compatibilità di tema e plugin su staging.
2. Attiva OPcache e una object cache persistente. Su un sito con molte query è l’intervento con il miglior rapporto tra sforzo e risultato.
3. Controlla le opzioni in autoload. WordPress carica a ogni richiesta tutte le opzioni marcate come autoload: se un plugin ne ha scritte da megabyte, paghi quel costo su ogni singola pagina.

SELECT option_name, LENGTH(option_value) AS peso
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY peso DESC
LIMIT 20;

Da WordPress 6.6 i valori della colonna autoload non sono più solo yes e no: la query sopra li copre tutti. Se il totale supera 800 KB – 1 MB, hai trovato un collo di bottiglia. Le voci sospette appartengono quasi sempre a plugin di cache mal configurati, form builder o page builder.

4. Metti una CDN davanti al sito e attiva passare a HTTP/3: riduci la latenza sulle connessioni mobili e sulle reti instabili, dove il guadagno è più evidente.
5. Cambia hosting se dopo i punti precedenti il TTFB resta sopra 800 ms. A quel punto non è più un problema di configurazione, ed è il momento in cui ha senso guardare a un VPS: come si sceglie fra condiviso e VPS — e perché una macchina più grande da sola non velocizza un sito lento.
6. Se il tema è custom, controlla le query del tema. Su un tema custom il TTFB dipende anche da quante query fa il template: ogni WP_Query aggiuntiva è un giro in più sul database, e di default WordPress esegue pure un conteggio totale delle righe che serve solo se stai paginando. Query Monitor te le elenca tutte con i tempi. Su come scriverle — e su quando la query giusta è quella che WordPress ha già eseguito — WP_Query e pre_get_posts nei template.

Causa 2 — Le immagini sono pesanti e gestite male

Nella stragrande maggioranza dei siti WordPress l’elemento LCP è un’immagine: l’hero della home, la featured image dell’articolo, la foto principale della scheda prodotto. Ottimizzare quella singola immagine vale più che ottimizzare tutte le altre messe insieme.

Come riconoscerla

In PageSpeed Insights, sotto la diagnostica, cerca la voce che identifica l’elemento LCP. Se è un <img>, controlla tre cose in quest’ordine: quanto pesa il file, se ha l’attributo loading="lazy" (non deve averlo) e quanto tempo passa tra l’inizio del caricamento e la sua comparsa.

Gli errori tipici

• Immagini caricate a dimensione originale. Un JPEG da 4000 px scalato via CSS a 800 px viene comunque scaricato per intero.
• Formati obsoleti. WordPress supporta l’upload di WebP dalla 5.8 e di AVIF dalla 6.5, ma non converte automaticamente quello che carichi: serve un plugin o un passaggio in fase di build.
• Lazy loading applicato all’immagine LCP. È l’autogol più comune: ritardi deliberatamente proprio l’elemento su cui vieni misurato. Dalla 5.9 WordPress cerca di escludere la prima immagine del contenuto e dalla 6.3 assegna in automatico fetchpriority="high" all’immagine LCP probabile, ma con page builder e hero costruiti fuori dal contenuto l’euristica sbaglia spesso.
• Nessuna dimensione dichiarata. Senza width e height il browser non sa quanto spazio riservare, e il layout salta (ne riparliamo nella causa 6).

Come risolverla

L’immagine LCP va trattata come un caso a parte rispetto a tutte le altre:

<!-- Immagine LCP: priorità alta, MAI lazy -->
<img src="/hero.webp"
     width="1200" height="675"
     fetchpriority="high"
     decoding="async"
     alt="Descrizione dell'immagine">

<!-- Tutte le immagini sotto la piega -->
<img src="/foto.webp"
     width="800" height="450"
     loading="lazy"
     decoding="async"
     alt="Descrizione dell'immagine">

Se l’hero è impostato come sfondo CSS, il browser lo scopre tardi: aggiungi un preload esplicito nell’<head>.

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

Sul resto della libreria: converti in WebP o AVIF, genera le dimensioni intermedie corrette e servile con srcset. Per il funzionamento del lazy loading, i suoi limiti e la sua interazione con caching e minificazione ho scritto un approfondimento dedicato: lazy loading, caching e minificazione.

Causa 3 — Troppi plugin, o meglio: i plugin sbagliati

“Hai troppi plugin” è un consiglio inutile. Trenta plugin ben scritti che caricano codice solo dove serve pesano meno di tre plugin che iniettano CSS, JavaScript e query su ogni pagina del sito. Il problema non è il numero: è cosa fanno e dove lo fanno.

Come riconoscerla

Installa Query Monitor e apri una pagina qualsiasi da amministratore. Ti interessano tre pannelli:

• Queries → by Component: quale plugin sta facendo più query, e quante.
• Scripts e Styles: quanti file vengono accodati e da chi. Cerca gli asset di plugin che non c’entrano nulla con la pagina che stai guardando — il classico plugin per i form caricato anche sugli articoli del blog.
• HTTP API Calls: le chiamate a servizi esterni eseguite durante la generazione della pagina. Una sola chiamata bloccante verso un’API lenta può aggiungere secondi al TTFB.

Per isolare il colpevole in modo pulito usa il plugin ufficiale Health Check & Troubleshooting: attiva la modalità risoluzione problemi, che disattiva tutto solo per la tua sessione lasciando il sito online per i visitatori, e riattiva un plugin alla volta misurando.

Come risolverla

Il primo intervento, quasi sempre risolutivo, è smettere di caricare asset dove non servono:

add_action( 'wp_enqueue_scripts', function () {
    // Carica gli asset del form solo sulla pagina contatti
    if ( ! is_page( 'contatti' ) ) {
        wp_dequeue_script( 'contact-form-7' );
        wp_dequeue_style( 'contact-form-7' );
    }
}, 100 );

Gli altri interventi, in ordine di efficacia:

• Elimina i plugin ridondanti. Due plugin SEO, tre di cache, quattro che aggiungono blocchi: succede più spesso di quanto sembri, e i conflitti costano più della somma delle parti.
• Sostituisci i plugin abbandonati. Un plugin non aggiornato da due anni è insieme un problema di performance e di sicurezza.
• Sostituisci con codice le funzioni banali. Un plugin da 200 KB per aggiungere uno snippet nell’header non ha senso.
• Tieni tutto aggiornato. Molte regressioni di performance si risolvono con un aggiornamento fatto bene, senza toccare altro.

Un caso a parte è WP-Cron: WordPress esegue le attività pianificate al momento della visita di un utente, e su siti con molte attività questo si traduce in visitatori che pagano il conto. Disattivalo e delega a un cron di sistema:

// In wp-config.php
define( 'DISABLE_WP_CRON', true );

// Nel crontab del server, ogni 5 minuti
*/5 * * * * cd /var/www/iltuosito && wp cron event run --due-now > /dev/null 2>&1

Causa 4 — La cache manca, o è configurata male

Senza cache, ogni visita fa girare PHP, interroga il database e assembla la pagina da zero. Con la cache, la stessa pagina viene servita come HTML statico. La differenza sul TTFB è tipicamente di un ordine di grandezza.

Il problema, però, è raramente l’assenza totale di cache: quasi tutti ne hanno una. Il problema è che non funziona come si crede.

Come riconoscerla

Controlla gli header di risposta in navigazione anonima, su una pagina che non hai appena modificato:

curl -sI https://iltuosito.it/una-pagina/ | grep -i "cache\|x-cache\|age\|cf-"

Se non vedi alcun indicatore di HIT, o se ogni richiesta risulta un MISS, la cache c’è ma non sta lavorando. Verifica anche il TTFB da loggato e da anonimo: se sono simili, con ogni probabilità la cache è di fatto disattivata.

Le configurazioni che annullano la cache

• Cookie impostati su tutte le pagine. Un plugin di analytics, un banner cookie mal configurato o WooCommerce che avvia la sessione ovunque possono rendere ogni richiesta “unica” e quindi non cacheabile.
• Doppio livello di cache non coordinato. Plugin di cache più cache dell’hosting più CDN: quando i tre non si parlano, il risultato è contenuto vecchio servito a caso e invalidazioni che non si propagano.
• Esclusioni troppo larghe. Escludere l’intero carrello è corretto; escludere /* perché “così non ci sono problemi” è quello che si trova più spesso.
• TTL troppo brevi. Una cache che scade ogni 10 minuti su un sito con traffico medio-basso non serve quasi a niente: la maggior parte delle visite trova comunque la cache vuota.

Come risolverla

Scegli un solo livello di cache pagina come riferimento e configura gli altri in modo che lo rispettino. Escludi con chirurgia solo ciò che deve esserlo (carrello, checkout, area riservata, pagine di conferma) e tieni TTL lunghi con invalidazione alla pubblicazione. Sul confronto tra i due plugin più diffusi e sui rispettivi casi d’uso ho scritto un articolo dedicato: W3 Total Cache vs WP Rocket.

Dopo ogni modifica, ripeti il test con curl: la cache è una di quelle cose che si dà per funzionante e quasi mai lo è al primo tentativo.

Causa 5 — CSS e JavaScript bloccano il rendering e la reattività

Qui si gioca la partita dell’INP, ed è la causa su cui più siti sono passati dal verde al rosso dopo marzo 2024. FID era una metrica indulgente: bastava che la prima interazione non fosse ritardata. INP misura tutte le interazioni e prende quasi il valore peggiore. Un sito che caricava JavaScript pesante e se la cavava con FID, con INP non se la cava più.

Come riconoscerla

Nei DevTools, pannello Performance: attiva il throttling della CPU a 4x, registra un caricamento e poi interagisci (clic sul menu, apertura di un accordion, digitazione in un campo). Cerca i long task, i blocchi gialli sopra i 50 ms nel main thread. Sono quelli che tengono il browser occupato mentre l’utente sta cliccando.

Come risolverla

• La scheda Coverage dei DevTools ti mostra la percentuale di codice mai eseguito: su molti siti WordPress supera il 60%. Quel codice raramente è tuo — arriva dal tema, che carica slider, icon font e librerie per pagine che non li usano. Sui progetti a lungo termine è l’argomento più solido a favore di un tema scritto su misura, che carica solo ciò che serve; prima ancora, è il motivo per cui il peso di un tema si misura sulla demo e non sulla scheda prodotto.
• Rimanda gli script non critici con defer, e carica chat, mappe, widget social e player video solo su interazione dell’utente. Nessuno di questi deve partire al caricamento.
• Spezza i task lunghi. Se hai codice tuo che elabora molti elementi, cedi il controllo al browser tra un blocco e l’altro invece di occupare il main thread per centinaia di millisecondi.
• Riduci il CSS che blocca il rendering. Inlinea il critical CSS della porzione visibile e carica il resto in modo asincrono. Attenzione: i generatori automatici di critical CSS vanno verificati a mano, perché rompono facilmente il layout.
• Limita l’Heartbeat API, che di default invia una richiesta ogni 15 secondi in area amministrativa:

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

Per i contenuti lunghi, content-visibility evita al browser di calcolare il layout di sezioni che nessuno sta ancora guardando:

.sezione-sotto-la-piega {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

Da WordPress 6.8 il core include lo speculative loading: le pagine collegate vengono precaricate in base al comportamento dell’utente, con un effetto molto evidente sulla navigazione percepita. Verifica che il tuo plugin di cache non entri in conflitto con questo comportamento. È una delle poche funzionalità di prestazioni arrivate nel core negli ultimi anni: le altre, e in quale release sono comparse, sono nello storico delle versioni di WordPress.

Causa 6 — Il layout si muove mentre la pagina carica

Il CLS non è una metrica di velocità: un sito può caricare in un secondo e avere un CLS pessimo. È una metrica di stabilità, e misura una cosa che gli utenti odiano — il pulsante che si sposta nell’istante esatto in cui lo stanno premendo.

Come riconoscerla

Nei DevTools, pannello Performance, la traccia Layout Shifts evidenzia ogni spostamento e l’elemento che lo ha causato. Prova anche sul serio: apri il sito da mobile su una connessione lenta e osserva cosa succede nei primi due secondi.

Le quattro cause classiche, e i rimedi

• Immagini e iframe senza dimensioni. Dichiara sempre width e height nell’HTML, anche se poi il CSS li rende fluidi con max-width: 100%; height: auto;. Il browser usa quei due numeri per calcolare l’aspect ratio e riservare lo spazio.
• Font web che sostituiscono il fallback. Usa font-display: swap, precarica il font principale e allinea le metriche del fallback per rendere lo scambio invisibile:

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter.woff2") format("woff2");
  font-display: swap;
}

@font-face {
  font-family: "Inter Fallback";
  src: local("Arial");
  size-adjust: 107%;
  ascent-override: 90%;
}

• Banner cookie, alert e annunci inseriti dinamicamente. Riserva lo spazio con un contenitore di altezza fissa, oppure sovrapponili al contenuto invece di spingerlo verso il basso. Se la barra la costruisci tu, il modo di riservare lo spazio a una barra di avviso senza sovrapposizioni è metterla nel flusso della pagina fin dall’inizio.
• Contenuto iniettato via JavaScript sopra a quello esistente: slider, caroselli, sezioni personalizzate. Vale la stessa regola: lo spazio va riservato prima, non conquistato dopo.

In che ordine intervenire

Le sei cause non hanno lo stesso peso e non vanno affrontate in parallelo. Questa è la sequenza che dà risultati misurabili prima:

Una regola che vale più di tutte le altre: un intervento alla volta, e misura dopo ognuno. Se ne fai cinque insieme e il sito peggiora, non saprai quale tornare indietro.

Checklist operativa

Da usare come diagnostica rapida su qualsiasi sito WordPress:

• TTFB sotto 800 ms, misurato più volte e anche su pagine interne
• PHP su versione supportata e recente
• OPcache attiva; object cache persistente su siti con molte query
• Opzioni in autoload sotto il megabyte
• Cache pagina verificata via header, non solo “attivata”
• Un solo livello di cache pagina come riferimento
• Immagine LCP in WebP/AVIF, con fetchpriority="high" e senza loading="lazy"
• Lazy loading su tutto ciò che sta sotto la piega
• width e height su tutte le immagini e gli iframe
• Font precaricati con font-display: swap
• Nessun asset di plugin caricato su pagine dove non serve
• Nessuna chiamata HTTP esterna bloccante durante la generazione della pagina
• WP-Cron disattivato e sostituito da cron di sistema
• Script di terze parti in defer o caricati su interazione
• Spazio riservato per banner cookie e contenuti dinamici
• LCP, INP e CLS in verde sui dati di campo, non in laboratorio

Questa checklist copre la performance. Per la parte editoriale — intento, struttura, metadati, link interni — il corrispettivo sono i 15 controlli on-page: insieme coprono quasi tutto quello che puoi verificare su una singola pagina.

Come non tornare al punto di partenza

Le performance non sono un progetto con una data di fine. Un sito ottimizzato torna lento nel giro di pochi mesi: si aggiungono plugin, si pubblicano immagini non compresse, si installa uno script di tracciamento in più, si aggiorna il tema.

• Controlla Search Console una volta al mese. Il rapporto sull’esperienza sulla pagina lavora su una finestra mobile di 28 giorni: un peggioramento diventa visibile con qualche settimana di ritardo, quindi va guardato con regolarità.
• Misura un URL per template, non solo la home: archivio, articolo, pagina, scheda prodotto.
• Rimisura dopo ogni aggiunta rilevante: nuovo plugin, nuovo script di tracciamento, restyling.
• Tieni una nota della configurazione di cache ed esclusioni. È la prima cosa che si dimentica e la prima che serve quando qualcosa smette di funzionare.

Domande frequenti

In sintesi

Un sito lento si risolve in ordine: prima si misura sui dati reali, poi si guarda il TTFB, poi l’immagine LCP, poi la cache, poi i plugin, poi il JavaScript, infine la stabilità del layout. Le sei cause di questa guida coprono quasi tutti i casi che si incontrano su WordPress, e nella grande maggioranza dei siti i primi quattro interventi della tabella valgono già la differenza tra rosso e verde. E se qualcuno ti ha proposto di riscrivere il frontend per risolvere la lentezza, vale la pena sapere quanto costa davvero un’architettura headless: è una scelta che si giustifica per molti motivi, quasi mai per la velocità.

Se vuoi approfondire i singoli temi trovi gli altri articoli nella sezione performance web.

Hai misurato e i numeri non migliorano, oppure preferisci che a metterci mano sia qualcuno che lo fa di mestiere? Richiedi un’analisi delle performance del tuo sito WordPress: ti restituisco le cause reali in ordine di impatto, con gli interventi da fare e quelli che non serve fare.