Un sito WordPress che impiega più di 2,5 secondi a caricarsi perde visitatori in modo misurabile. Google valuta da anni la velocità delle pagine come fattore di posizionamento — con i Core Web Vitals è stata perfino formalizzata in LCP, INP e CLS. Nelle mie formazioni vedo regolarmente siti che arrancano a 25 punti su 100 in PageSpeed Insights, benché il contenuto sia di prim'ordine. In questo articolo pilastro Le mostro le dieci leve con cui porto in modo affidabile i siti dei clienti oltre quota 90 — dalla scelta dell'hoster alla manutenzione del database.
In sintesi — le 10 leve
| # | Leva | Impegno | Effetto | Quando è indispensabile? |
|---|---|---|---|---|
| 1 | Cambiare hoster | Alto | Molto alto | Con TTFB oltre 600 ms |
| 2 | Configurare un plugin di caching | Basso | Alto | Sempre |
| 3 | Ottimizzare le immagini e usare WebP | Medio | Alto | Sempre |
| 4 | Caricamento differito di immagini e iframe | Basso | Medio | Sempre |
| 5 | Ospitare i font in locale | Medio | Medio | Con i Google Fonts |
| 6 | Minificare/combinare CSS e JS | Basso | Medio | Sempre |
| 7 | Ripulire il database | Medio | Medio | Ogni 3–6 mesi |
| 8 | Ridurre i plugin | Alto | Alto | Con oltre 30 plugin attivi |
| 9 | Usare una CDN | Medio | Medio-alto | Pubblico internazionale o carichi elevati |
| 10 | Verificare versione PHP e HTTP/3 | Basso | Medio | Con PHP inferiore a 8.2 |
Che cosa sono i Core Web Vitals e perché li conto per primi?
Prima di ottimizzare qualcosa deve sapere rispetto a che cosa sta ottimizzando. Dal 2021 Google misura tre indicatori centrali:
- LCP (Largest Contentful Paint) — quanto in fretta viene caricato l'elemento visibile più grande? Valore obiettivo: massimo 2,5 secondi.
- INP (Interaction to Next Paint) — quanto in fretta la pagina reagisce a clic e tocchi? Valore obiettivo: massimo 200 ms. (Nel 2024 l'INP ha sostituito il più vecchio FID.)
- CLS (Cumulative Layout Shift) — quanto saltano gli elementi durante il caricamento? Valore obiettivo: massimo 0,1.
Può misurarli in PageSpeed Insights (pagespeed.web.dev) oppure più direttamente in Chrome DevTools → Lighthouse. Importante: PageSpeed Insights mostra due livelli di dati. I dati di laboratorio sono simulazioni — buoni per capire la tendenza. I dati sul campo derivano da utilizzi reali del Suo sito con Chrome nell'arco di 28 giorni — ed è ciò che Google usa per il posizionamento. Su un sito nuovo non ci sono ancora dati sul campo; i valori di laboratorio sono allora l'unico orientamento.
Leva 1: l'hoster — il freno invisibile
Sembra banale, ma: la leva più importante spesso non è WordPress stesso, bensì il server su cui gira. Se il Time to First Byte (TTFB) supera i 600 ms, non c'è plugin di caching al mondo che aiuti — la consegna dell'HTML parte già troppo tardi.
Categorie di hoster, a grandi linee:
- Hoster condivisi di massa (ad esempio Strato, 1&1, le tariffe standard di GoDaddy): economici, ma spesso lenti. TTFB da 800 ms a 1,5 s non sono insoliti.
- Hoster specializzati in WordPress (ad esempio Kinsta, WP Engine, Raidboxes, World4You „Optimized WordPress“): più cari (15–50 €/mese), ma con TTFB sotto i 300 ms.
- VPS / cloud (Hetzner, DigitalOcean): convenienti in rapporto alla potenza, ma il server lo gestisce Lei — ha senso solo con conoscenze pregresse.
Cambiare hoster è impegnativo, ma pianificabile. Altro nell'articolo esistente Trasloco di WordPress verso un nuovo hoster.
Leva 2: caching — il guadagno di velocità più rapido
Il caching salva la versione HTML già generata del Suo sito, così alla richiesta successiva WordPress non deve più passare per database e PHP. Effetto: il TTFB scende sotto i 200 ms, spesso a 50 ms.
I plugin più importanti:
- WP Rocket (a pagamento, circa 60 € l'anno per un sito): il mio standard. Ottime impostazioni predefinite, combina caching, minificazione, caricamento differito e pulizia del database.
- LiteSpeed Cache (gratuito): eccellente, ma ha senso solo se il Suo hoster usa server LiteSpeed (ad esempio World4You, Easyname). Altrimenti l'effetto è dimezzato.
- W3 Total Cache (gratuito): potente, ma un incubo di configurazione. Piuttosto per esperti.
- WP Super Cache (gratuito, di Automattic): solido, semplice, senza fronzoli.
Regola pratica di configurazione: dopo aver attivato il plugin lasci prima girare le impostazioni predefinite, misuri il PageSpeed, poi cambi una opzione e misuri di nuovo. Eviti la tentazione di spuntare subito tutte le opzioni aggressive — porta quasi sempre a pagine rotte (slider scomparsi, font che saltano).
Leva 3: le immagini — la principale causa dei tempi di caricamento
In un audit su due le immagini sono il fattore dimensionale. Esempio: un file PNG da stock di 4.000 × 2.700 px arriva rapidamente a 4–6 MB. Su una pagina con 5 immagini fanno 25 MB solo di immagini. Le connessioni mobili si arrendono.
Tre interventi, in ordine:
- Passare al formato WebP. A parità di qualità è circa il 30 % più piccolo del JPEG e circa il 70 % più piccolo del PNG. Plugin: Imagify (a pagamento), ShortPixel (a pagamento), Smush (versione gratuita con limiti). Confronto più approfondito nel mio articolo ShortPixel vs. Optimole.
- Adattare la risoluzione alla dimensione di visualizzazione. Un'immagine che nel tema viene mostrata larga solo 800 px non dovrebbe essere caricata a 3.000 px. WordPress genera sì automaticamente diverse dimensioni, ma l'originale consuma comunque spazio e volume di backup.
- Attivare il caricamento differito. Dalla versione 5.5 è integrato nativamente per le immagini, dalla 5.7 anche per gli iframe. È attivo, purché il Suo tema non sovrascriva
loading="lazy".
Vuole capire l'ottimizzazione del Suo sito WordPress dall'inizio alla fine — non solo reagire, ma migliorare in modo sistematico? Nel mio corso online Le mostro passo per passo ciascuna delle 10 leve su un sito reale. → Al corso online
Leva 4: caricamento differito per iframe e video
L'attributo loading="lazy" funziona anche per i video YouTube incorporati e per Google Maps. Spesso sono il maggiore ostacolo alla generazione della pagina. Se ha moltissimi video incorporati, conviene il plugin WP YouTube Lyte — sostituisce il player YouTube con un'immagine di anteprima e carica il player solo al clic. Effetto: da 1 a 2 secondi in meno di LCP.
Leva 5: ospitare i font in locale (niente CDN di Google Fonts)
I Google Fonts tramite la CDN di Google sono stati per anni lo standard. Dopo le sentenze in materia di GDPR, nei paesi di lingua tedesca la cosa è delicata sul piano giuridico (in questione: la trasmissione dell'indirizzo IP a Google senza consenso). Inoltre una ricerca DNS in più e una richiesta aggiuntiva sono più lente di un file .woff2 locale.
Soluzione: scaricare i font e integrarli nel tema. Plugin: OMGF (Optimize My Google Fonts) — download automatico e hosting locale in due clic. Altro sul lato giuridico negli articoli esistenti Checklist di conformità GDPR per l'Austria e Checklist di conformità GDPR per la Germania.
Leva 6: minificare CSS e JS
Minificare significa rimuovere spazi e commenti dai file CSS e JavaScript. Preso singolarmente l'effetto è ridotto, ma nel complesso si sente (dal 15 al 25 % di dimensione in meno su CSS e JS).
Combinare (unire più file in uno solo) è meno rilevante dai tempi di HTTP/2 — i server moderni consegnano molti file piccoli quasi con la stessa rapidità di uno grande. Sui server HTTP/1.1 aiuta ancora.
Attenzione alla minificazione e combinazione aggressive: slider rotti e layout che saltano sono la conseguenza più frequente. Attivi sempre gradualmente e controlli il frontend.
Leva 7: ripulire il database
Negli anni WordPress accumula nel database: revisioni degli articoli, bozze automatiche, transient, commenti cancellati, commenti spam, sessioni scadute. Su un sito di 5 anni ci possono stare tranquillamente 200.000 righe inutili — e il database diventa lento.
Per ripulire:
- WP Rocket (integrato, semplice)
- WP-Optimize (gratuito, più potente)
- Direttamente con phpMyAdmin (solo con backup preventivo e conoscenze di database)
Obbligatorio prima di ogni pulizia: il backup. Anche nel mio articolo esistente Strategia di backup WordPress 2026 questa regola è il primo paragrafo.
Leva 8: ridurre i plugin
Ogni plugin attivo carica codice, alcuni anche CSS e JavaScript su ogni pagina (anche dove non servono). La domanda più importante: quali plugin sono ancora attivi pur non essendo più usati?
Audit pratico: scorra l'elenco dei plugin con tre colonne — „mi serve ogni giorno“, „a volte“, „non ricordo più“. Disattivi l'ultima categoria, osservi per una settimana, poi cancelli. Che cosa Le serve davvero lo descrivo in Plugin WordPress 2026: quali Le servono davvero?.
Leva 9: usare una CDN
Una Content Delivery Network replica i Suoi file statici (immagini, CSS, JavaScript) su server in tutto il mondo. I visitatori vengono serviti dal server geograficamente più vicino. Si sente soprattutto con pubblici internazionali.
- Cloudflare (la versione gratuita basta a molti): il mio standard per i siti dell'area di lingua tedesca con visitatori esteri occasionali.
- BunnyCDN: conveniente (1 $ al mese di costo minimo), buona copertura europea.
- KeyCDN: simile, un po' più caro.
Cloudflare porta in più vantaggi di sicurezza (protezione DDoS, rilevamento dei bot), che approfondisco nel mio articolo esistente Misure di sicurezza per WordPress.
Leva 10: versione di PHP e HTTP/3
Versione di PHP: WordPress gira ufficialmente da PHP 7.4, ma diventa performante solo da PHP 8.0. Stato attuale nel 2026: PHP 8.3. Passare da 7.4 a 8.3 porta tipicamente un'elaborazione del backend più rapida del 30–50 %. Il cambio presso l'hoster richiede di solito due clic — però: prima verifichi che tutti i plugin siano compatibili (strumento: il plugin PHP Compatibility Checker).
HTTP/3 (detto anche QUIC) è il passo successivo a HTTP/2. Handshake TLS più rapidi, prestazioni migliori sulle reti mobili. L'attivazione avviene lato server — o direttamente presso l'hoster o tramite Cloudflare.
Flusso di misurazione per le Sue sessioni di ottimizzazione
Ecco come procedo in una sessione di audit:
- Misurare la base di partenza: PageSpeed Insights (mobile e desktop), GTmetrix, WebPageTest. Screenshot dei valori.
- Scegliere la prima leva (massimo effetto, minimo impegno per la Sua situazione).
- Realizzarla, poi misurare subito di nuovo, un solo giro di valori.
- Solo allora passare alla leva successiva.
Mai tutto insieme. Altrimenti alla fine non saprà quale modifica ha portato il miglioramento — o quale ha distrutto il layout.
Domande frequenti
Quanto dura un'ottimizzazione completa delle prestazioni?
Per un sito WordPress medio con 30–50 plugin calcolo 6–10 ore, distribuite su 2–3 sessioni. Un primo miglioramento percepibile (punteggio PageSpeed più 20 punti) è di solito realizzabile in 90 minuti.
Quale punteggio è realistico?
Un 80 e oltre su mobile e un 90 e oltre su desktop in PageSpeed Insights sono raggiungibili da ogni normale sito WordPress. Il 100/100 è possibile, ma costa una fatica sproporzionata — non sempre conveniente.
Un nuovo hoster porta davvero tanto?
Sì, se il vecchio hoster è il collo di bottiglia. Una misurazione del TTFB con WebPageTest lo chiarisce in 30 secondi.
Devo abbandonare Elementor per le prestazioni?
Non necessariamente. Elementor si lascia mettere a punto bene — veda Ottimizzazione delle prestazioni di Elementor. Ma sì, un editor a blocchi ben fatto con Astra/Kadence tenderà a essere più veloce.
Conviene un generatore di siti statici al posto di WordPress?
Per blog e magazine puri: sì, tecnicamente è nettamente più veloce. Ma perde la facilità di modifica. Per la maggior parte dei miei clienti non è un buono scambio.
Conclusione
La velocità delle pagine non è un progetto una tantum, ma una disciplina ricorrente. Le dieci leve qui sopra sono l'inventario — l'arte sta nell'ordine e in una misurazione pulita. Se vuole capire una volta per tutte le prestazioni di WordPress, il mio corso online è la via diretta: lì percorro con Lei leva per leva e mostro come portare il Suo sito stabilmente in zona verde — non solo per l'istantanea di un audit.
Fonte delle immagini in evidenza e inline: illustrazioni realizzate appositamente nel design pletzenauer (nessuna foto stock).
Tag