Velocità del sito, cosa rallenta davvero WordPress
WordPress non è lento. Lo sono i siti costruiti aggiungendo un plugin alla volta senza togliere mai niente. Le cinque cause vere, in ordine di peso.
WordPress non è lento. Sono lenti i siti WordPress costruiti aggiungendo un plugin ogni volta che serve una funzione, senza togliere mai niente. La differenza tra un sito che carica in un secondo e uno che ne impiega sei sta quasi sempre in cinque cose, e nessuna è la piattaforma.
Prima si misura, e sui dati veri
Il punteggio degli strumenti di test simula una visita da un dispositivo di riferimento. Serve a capire cosa sistemare, non a sapere come sta il sito.
Il dato che conta arriva dalle visite reali ed è nel rapporto sull’esperienza sulla pagina di Search Console. Le soglie da tenere a mente sono tre: il contenuto principale entro 2,5 secondi, la risposta alle interazioni entro 200 millisecondi, lo spostamento degli elementi sotto 0,1.
Guarda il dato mobile, non quello desktop. È dove sta il traffico e dove i problemi si vedono, perché il telefono ha meno potenza di calcolo e una connessione peggiore.
Le immagini, che sono quasi sempre la prima causa
La foto in cima alla pagina caricata a piena risoluzione è la causa più frequente di caricamento lento sui siti aziendali italiani. Una immagine da 3.000 pixel di larghezza mostrata in uno spazio da 800 fa scaricare quattro volte i byte necessari.
Le tre cose da fare sono banali: ridimensionare alla misura reale di utilizzo, usare formati moderni, e caricare in differita tutto tranne l’immagine principale. Proprio quella in cima non va differita, perché è l’elemento che determina la metrica.
Su un sito con molte foto questo intervento da solo porta la metrica sotto soglia nella maggior parte dei casi, e si fa in un pomeriggio senza toccare il tema.
Il consenso ai cookie, il sospetto che nessuno controlla
Su moltissimi siti lo script più pesante della pagina non è del tema e non è un plugin di funzionalità: è il banner del consenso. Si carica per primo, blocca il resto, e spesso porta con sé un intero sistema di categorizzazione. Conviene sistemarlo una volta sola, perché quello stesso banner decide anche se il sito è a norma e quanti dati ti restano in analitica: abbiamo scritto come si imposta un banner dei cookie che regge.
Peggiora due metriche insieme. Il caricamento, perché occupa banda e tempo di elaborazione prima di tutto il resto. La stabilità visiva, perché compare dopo che la pagina si è disegnata e sposta tutto.
Non si può togliere, ma si può scegliere una soluzione leggera e riservare lo spazio dove comparirà. È il singolo intervento con il miglior rapporto tra mezz’ora di lavoro e numeri che si muovono.
| Causa | Cosa peggiora | Tempo per sistemarla |
|---|---|---|
| Immagine principale non ottimizzata | Caricamento | Mezza giornata |
| Banner cookie pesante | Caricamento e stabilità | Mezza giornata |
| Script di terze parti | Reattività | Una giornata |
| Plugin che caricano ovunque | Tutte e tre | Una giornata |
| Caratteri da servizi esterni | Caricamento e stabilità | Due ore |
| Hosting condiviso sovraccarico | Tempo di risposta del server | Un trasloco |
I plugin, ma non quelli che pensi
Il numero di plugin non dice niente. Venti plugin leggeri che caricano codice solo dove serve pesano meno di tre plugin che mettono i loro file su ogni pagina del sito. C’è anche un motivo di sicurezza per togliere quelli che non usi, visto che i plugin dimenticati sono la via d’ingresso più usata da chi attacca i siti.
Il caso tipico è il plugin dei moduli di contatto che carica il suo JavaScript anche sulle pagine senza moduli, o il costruttore di pagine che aggiunge il suo foglio di stile completo ovunque, anche dove la pagina è scritta a mano.
Il controllo si fa dagli strumenti per sviluppatori del browser, scheda rete, ordinando per dimensione. In cinque minuti si vede chi porta i file più pesanti e se quei file servono su quella pagina.
I caratteri tipografici, il dettaglio che sposta la stabilità
Un carattere caricato da un servizio esterno richiede una connessione a un altro dominio prima ancora di scaricare il file. Nel frattempo il testo o è invisibile o viene mostrato con un carattere di sistema e poi sostituito, e in quel momento la pagina si sposta.
Le due soluzioni sono ospitare i caratteri sul proprio server e dichiarare cosa mostrare durante l’attesa. Sono due righe di configurazione e tolgono una delle cause più frequenti di instabilità visiva.
Conviene anche contare quanti pesi diversi vengono caricati. Molti temi ne caricano sei o sette quando la grafica ne usa due, e ogni peso è un file in più su ogni visita.
La cache viene dopo, non prima
È il primo intervento che fanno tutti e migliora il tempo di risposta del server, che è solo una parte del problema. Quello che rallenta l’esperienza di chi naviga è il lavoro che fa il browser dopo aver ricevuto la pagina, e la cache non lo tocca.
Il rischio pratico è che la cache nasconda il problema invece di risolverlo: i numeri migliorano quel tanto che basta a chiudere la discussione, e il sito resta pesante.
E un avvertimento: tre plugin di ottimizzazione installati insieme fanno le stesse cose, si sovrappongono, e quando il sito si rompe nessuno sa quale disattivare. Uno solo, configurato bene.
L’hosting, l’unica voce dove spendere risolve
Su un piano condiviso da tre euro al mese il server risponde quando gli riesce, e nessuna ottimizzazione del sito compensa un tempo di risposta di un secondo e mezzo.
Il numero da guardare è il tempo alla prima risposta. Sopra i 600 millisecondi in modo costante, il problema è il server e non il sito. È misurabile in un minuto dagli strumenti del browser.
Un hosting decente per un sito aziendale italiano costa tra i 15 e i 50 euro al mese. È la voce di spesa che a parità di euro sposta più numeri, ed è anche quella su cui si risparmia per prima. I numeri che distinguono un fornitore serio da uno che costa poco e basta sono pochi, e li abbiamo messi in fila in cosa si controlla prima di firmare un contratto di hosting.
Gli script di terze parti, in ordine di peso
Ogni strumento aggiunto al sito gira sul telefono di chi visita. Il gestore dei tag, le statistiche, i pixel pubblicitari, la chat, le mappe, i widget delle recensioni: presi singolarmente sembrano piccoli, insieme superano il peso del sito.
Sono anche la prima causa di scarsa reattività, perché occupano il processore proprio nel momento in cui qualcuno tocca lo schermo. È il tipo di problema che non si vede sul computer dell’ufficio e si vede benissimo su un telefono di quattro anni fa.
La regola pratica è che ogni script deve avere un proprietario che sappia dire a cosa serve. Quelli di cui nessuno sa rispondere vanno tolti, e sui siti che ereditiamo sono in media tre o quattro.
Cosa non fare
Non inseguire il punteggio cento: gli ultimi punti costano molto e non corrispondono a niente che un utente percepisca.
Non misurare il giorno dopo l’intervento. I dati reali si muovono su una finestra di ventotto giorni, quindi la verifica vera arriva fra un mese.
E non rifare il sito per risolvere un problema di velocità. Nove volte su dieci le cause sono nella configurazione e non nella struttura, e si sistemano in due giorni invece che in due mesi. Quando invece il problema è davvero strutturale, la decisione è un’altra e l’abbiamo messa per iscritto nell’articolo su rifare il sito ogni tre anni, quanto costa.
Le soglie e il significato delle tre metriche stanno nell’articolo su quali numeri contano davvero nei Core Web Vitals, e quando il lavoro va fatto su un sito che deve restare online mentre lo si sistema, è manutenzione ordinaria dentro lo sviluppo dei siti.
Un’ultima verifica che vale più di molti strumenti: apri il tuo sito dal telefono, con i dati e non con il wifi, in un posto con poco segnale. Quello che provi in quei venti secondi è l’esperienza di una parte reale dei tuoi visitatori, e nessun punteggio la restituisce. Se in quelle condizioni la pagina è inutilizzabile, hai trovato il lavoro da fare prima di tutti gli altri.
Una parte degli interventi che rendono un sito più veloce lo rendono anche più usabile per chi naviga con la tastiera o con un lettore di schermo, e su quel fronte esistono obblighi precisi: sono elencati in gli obblighi di accessibilità di un sito.
Aggiornato al 30 settembre 2026.
