Aureon
Demo gratuita
← Blog

Velocizzare un sito WordPress: la guida pratica per il 2026

Titolo decorativo guida alla velocità di WordPress

Per velocizzare un sito WordPress la sequenza giusta è questa: attiva una cache di pagina con impostazioni sicure, comprimi e converti le immagini in WebP o AVIF senza applicare il lazy loading all’immagine principale, poi minifica e rinvia CSS e JS non critici. Aggiungi preload o fetchpriority per l’elemento LCP e verifica ogni modifica con PageSpeed Insights o WebPageTest, usando il valore al 75° percentile come riferimento reale, non dal singolo test di laboratorio.

In breve:

  • La configurazione ottimale prevede attivare una cache di pagina sicura, comprimere immagini in WebP/AVIF senza lazy loading sull’immagine principale, e minificare CSS e JS non critici.
  • È fondamentale misurare le prestazioni iniziali con strumenti come PageSpeed Insights e WebPageTest, concentrandosi sul valore al 75° percentile dei dati di campo per un quadro reale.
  • Il TTFB dipende principalmente dalla qualità dell’hosting, dai parametri PHP, dal supporto HTTP/2/3 e dal numero di worker PHP disponibili, mentre i temi e plugin possono aggravare i tempi di caricamento.
  • La priorità per migliorare l’LCP include escludere l’immagine LCP dal lazy loading, aggiungere segnali di priorità come preload, e ottimizzare immagine e CSS di primo contenuto visivo.
  • Un solo sistema di cache di pagina attivo alla volta evita conflitti, mentre strumenti come WP-Optimize e Beplus consentono ulteriori ottimizzazioni senza sovrapposizioni.
Aureonweb
Parti con un sito più veloce
Aureon crea una demo realistica del tuo sito in 12 ore, con design personalizzato e velocità di caricamento ottimizzata.
Scopri Aureon

Indice

Come misurare la velocità del tuo sito wordpress: strumenti e metriche

Prima di toccare una sola riga di codice, misura. Senza un dato di partenza non saprai mai se un intervento ha funzionato o se hai solo spostato il problema altrove.

Esistono due famiglie di dati, e confonderle è l’errore più comune. I dati di laboratorio (quelli di Lighthouse, integrati in Chrome DevTools) simulano una visita in condizioni controllate: stessa rete, stesso dispositivo, stesse condizioni ogni volta. Sono perfetti per il debug perché sono ripetibili, ma non raccontano cosa vivono davvero i visitatori. I dati di campo, raccolti dal Chrome UX Report (CrUX) o da uno strumento di monitoraggio degli utenti reali (RUM), mostrano invece l’esperienza effettiva su migliaia di dispositivi e connessioni diverse.

Google stessa consiglia di guardare al 75° percentile (p75) delle visite reali per capire se una pagina supera le soglie “buone” dei Core Web Vitals. Un sito che ottiene 95 su Lighthouse ma fallisce il p75 su mobile ha un problema reale che il test di laboratorio non vede, magari legato a connessioni lente o dispositivi di fascia bassa.

Gli strumenti da tenere sotto mano sono pochi ma vanno usati bene:

  • PageSpeed Insights: combina dati di laboratorio e di campo nella stessa schermata, utile come primo controllo rapido.
  • WebPageTest: mostra la waterfall completa delle richieste e il filmstrip, cioè i fotogrammi del caricamento secondo per secondo, indispensabile per capire cosa blocca il rendering.
  • GTmetrix: utile per confronti storici nel tempo, con report che si possono salvare e riconfrontare dopo ogni intervento.
  • Chrome DevTools: il pannello Performance permette di isolare colli di bottiglia lato browser, come JavaScript che blocca il thread principale.

Le tre metriche che contano davvero sono il Largest Contentful Paint (LCP, il tempo per mostrare l’elemento visivo più grande), l’Interaction to Next Paint (INP, che ha sostituito il First Input Delay come misura della reattività) e il Cumulative Layout Shift (CLS, che misura quanto la pagina “salta” durante il caricamento). Tutte e tre insieme formano i Core Web Vitals.

Leggere una waterfall richiede un minimo di pratica ma paga subito. Cerca il tempo che passa prima che arrivi la prima risposta dal server, il cosiddetto Time To First Byte (TTFB): se supera gli 800 millisecondi, il problema è probabilmente l’hosting, non il tema. Poi guarda quali risorse bloccano il rendering: file CSS caricati nell’head senza async o defer sono spesso i primi indiziati.

Quali fattori rallentano davvero un sito wordpress?

Un sito lento raramente ha una sola causa. Di solito è la somma di piccole inefficienze che, una per una, sembrerebbero trascurabili.

Il TTFB dipende quasi interamente dalla qualità dell’hosting. Una versione di PHP datata (la 7.4 è ormai fuori supporto, mentre le versioni 8.2 e successive offrono guadagni di velocità misurabili), un numero insufficiente di worker PHP per gestire richieste simultanee, e l’assenza di HTTP/2 o HTTP/3 sono le cause più frequenti di un server lento a rispondere. Un hosting condiviso economico spesso mette troppi siti sulla stessa macchina, e il tuo TTFB ne paga il prezzo nelle ore di traffico alto.

Il tema e il page builder incidono più di quanto si pensi. Molti temi multiuso caricano decine di file CSS e JavaScript anche per funzioni che non usi mai, gonfiando il peso della pagina prima ancora che arrivi un contenuto. I page builder visuali (Elementor, Divi e simili) sono comodi ma tendono ad aggiungere script propri sopra quelli del tema, creando bundle ridondanti che il browser deve comunque scaricare ed eseguire.

I plugin sono la fonte più insidiosa di rallentamenti perché i problemi si sommano silenziosamente:

  • Concorrenza tra plugin: due plugin SEO o due plugin di caching attivi insieme spesso duplicano operazioni e generano conflitti.
  • Funzioni duplicate: un plugin per i social share e un altro per i pulsanti di condivisione fanno la stessa cosa due volte.
  • Query al database lente: plugin mal scritti eseguono query non ottimizzate a ogni caricamento di pagina, aggravando il carico sul database.
  • Script caricati ovunque: plugin che iniettano JavaScript su ogni pagina anche quando la funzione serve solo in una sezione specifica del sito.

Infine, le risorse esterne contano più di quanto sembri. I font di Google caricati da un dominio esterno, gli script di terze parti per chat, tracking e pubblicità, e le immagini non compresse aggiungono richieste HTTP e tempi di connessione che si sommano uno dopo l’altro. Ogni dominio esterno richiede una nuova connessione DNS e TLS, un costo che pesa soprattutto su mobile con connessioni instabili.

Quali plugin scegliere per velocizzare wordpress?

Non tutti i plugin di ottimizzazione fanno la stessa cosa, e capire le categorie evita di installarne tre che si accavallano.

Ci sono quattro famiglie principali: i plugin di page cache (salvano una versione statica HTML della pagina per non rigenerarla a ogni visita), quelli di object cache (mettono in cache le query al database, utili su siti con molto traffico dinamico), gli ottimizzatori di immagini (comprimono e convertono i file in formati più leggeri) e gli ottimizzatori di asset (minificano e rinviano CSS e JavaScript).

Quattro categorie di plugin per WordPress

Ecco come si posizionano gli strumenti più diffusi nell’ecosistema WordPress:

W3 Total Cache è probabilmente il plugin di caching più completo disponibile gratuitamente. Integra page cache, minificazione, supporto CDN e object cache in un solo pannello. Il vantaggio è la copertura totale delle funzioni; lo svantaggio è che la configurazione ha decine di opzioni e una scelta sbagliata (tipica: minificazione aggressiva che rompe layout o funzionalità) può creare più danni che benefici. W3 Total Cache resta una scelta solida quando configurato con attenzione, meglio ancora se testato in staging prima del rilascio in produzione.

WP-Optimize punta su un approccio più centralizzato: unisce caching, compressione immagini, minificazione e soprattutto pulizia del database in un’unica interfaccia. È la scelta giusta per chi vuole un pannello solo, senza gestire tre plugin diversi per tre funzioni diverse. WP-Optimize è particolarmente utile su siti che accumulano revisioni di articoli, commenti spam e transient scaduti nel database.

WP Super Cache è più datato ma resta una scelta leggera e affidabile per chi ha bisogno solo di page cache di base, senza le funzioni aggiuntive di soluzioni più complesse. È spesso la scelta giusta su siti semplici, dove aggiungere un plugin con decine di opzioni sarebbe eccessivo.

Autoptimize si concentra su un compito solo: minificare e aggregare CSS, JavaScript e HTML. Non fa caching di pagina, quindi va abbinato a un plugin dedicato per quello, ma fa il suo lavoro in modo pulito e senza sovraccaricare il pannello di amministrazione con opzioni superflue.

Beplus Performance Booster entra in gioco quando serve un controllo più fine. Offre funzioni granulari per il differimento e il ritardo del caricamento JavaScript, la rimozione del CSS inutilizzato pagina per pagina e l’integrazione con CDN, con la possibilità di escludere ottimizzazioni specifiche su singole pagine quando un intervento troppo aggressivo rompe una funzionalità. È lo strumento giusto quando i plugin più generici hanno già dato i loro frutti e serve l’ultimo margine di miglioramento.

Una regola vale sempre, indipendentemente dal plugin scelto: un solo sistema di page cache attivo alla volta. Avere due plugin di caching che lavorano in parallelo non raddoppia i benefici, genera conflitti, contenuti obsoleti serviti agli utenti e regressioni difficili da diagnosticare.

Su hosting managed WordPress, spesso conviene lasciare la cache di pagina al server e usare i plugin solo per immagini e asset. Molti provider managed offrono già una cache a livello di server più veloce di qualsiasi plugin PHP, perché lavora prima che WordPress venga anche solo caricato.

Checklist operativa passo per passo per velocizzare wordpress

Segui questi passaggi nell’ordine indicato: ognuno prepara il terreno per quello successivo, e saltarne uno spesso vanifica i benefici dei passaggi seguenti.

  1. Misura la situazione di partenza. Prima di cambiare qualsiasi impostazione, esegui PageSpeed Insights e WebPageTest sulle pagine più importanti (home, una pagina prodotto, un articolo tipico) e salva i risultati. Senza un confronto “prima e dopo” non saprai mai cosa ha funzionato davvero.

  2. Attiva la page cache. Configura un solo plugin di caching o la cache nativa dell’hosting. Testa subito dopo l’attivazione che il carrello e-commerce, i form e le aree riservate funzionino ancora correttamente, ed escludi esplicitamente le pagine dinamiche dalla cache.

  3. Ottimizza le immagini. Ridimensiona ogni immagine alle dimensioni effettive di visualizzazione (mai caricare un file da 3000 pixel per uno spazio di 600), comprimi con qualità tra 70 e 85 e converti in WebP o AVIF dove il supporto browser lo permette. Escludi sempre l’immagine LCP dal lazy loading: caricarla in differita è uno degli errori più frequenti e più dannosi per questa metrica.

  4. Minifica e rinvia CSS e JavaScript. Usa Autoptimize, la funzione integrata di W3 Total Cache o Beplus Performance Booster per comprimere i file e rinviare gli script non critici. Aggiungi un preload per l’immagine LCP e per i font critici usati nel primo viewport, in linea con le pratiche ufficiali per ottimizzare l’LCP.

  5. Attiva una CDN. Una rete di distribuzione dei contenuti avvicina i file statici (immagini, CSS, JS) al visitatore, riducendo la latenza di rete. Confronta TTFB e LCP prima e dopo l’attivazione: se non vedi differenze, probabilmente il collo di bottiglia sta altrove, nel database o nel PHP.

  6. Pulisci il database. Rimuovi revisioni di articoli accumulate, commenti spam, transient scaduti e tabelle orfane lasciate da plugin disinstallati. Mentre sei lì, disinstalla (non solo disattiva) i plugin che non usi da mesi: ogni plugin attivo, anche inerte, aggiunge un minimo di overhead a ogni richiesta.

  7. Esegui un test di regressione e imposta un monitoraggio continuo. Rilancia PageSpeed Insights e WebPageTest sulle stesse pagine misurate al passo 1, confronta i numeri e programma controlli periodici, perché un aggiornamento di tema o plugin può silenziosamente peggiorare le metriche mesi dopo.

Un consiglio: prima di ottimizzare qualsiasi cosa, verifica la versione di PHP del tuo hosting. Passare da PHP 7.4 a PHP 8.2 spesso porta un guadagno di velocità paragonabile a un intero pomeriggio di lavoro sui plugin, e richiede letteralmente un clic nel pannello di controllo dell’hosting.

Perché l’immagine LCP va gestita diversamente dalle altre

L’elemento LCP, cioè il blocco di contenuto più grande visibile nel primo schermo (quasi sempre un’immagine hero o un titolo con sfondo), merita un trattamento a parte rispetto al resto della pagina. Trattarlo come qualsiasi altra immagine è l’errore che vanifica ore di lavoro su tutto il resto.

Illustrazione priorità LCP nella parte visibile della pagina

Puoi identificarlo aprendo PageSpeed Insights o il pannello Performance di Chrome DevTools: entrambi segnalano esplicitamente quale elemento è stato misurato come LCP, e WebPageTest lo mostra anche nel filmstrip, il fotogramma per fotogramma del caricamento.

Una volta identificato, le correzioni pratiche sono quattro:

  • Non applicare mai il lazy loading all’immagine LCP. Il lazy loading dice al browser di aspettare prima di scaricare l’immagine, e per definizione l’elemento LCP è tra i primi contenuti richiesti dal browser.
  • Aggiungi fetchpriority="high" o un <link rel="preload"> per far partire il download dell’immagine il prima possibile, senza aspettare che il browser scopra la risorsa leggendo tutto l’HTML.
  • Rimuovi transizioni e animazioni CSS dalla sezione iniziale. Effetti di dissolvenza o slide sull’hero possono far percepire al browser che il rendering finale è ritardato, anche quando l’immagine è già scaricata.
  • Usa srcset e immagini responsive per servire il file della dimensione giusta a ogni dispositivo, invece di scaricare la versione desktop anche su mobile.

Le linee guida ufficiali su come ottimizzare l’LCP insistono su un punto spesso trascurato: comprimere le immagini non basta se il problema è altrove nella catena di caricamento. Se il file CSS che definisce lo sfondo dell’elemento LCP è esterno e bloccante, il browser deve prima scaricare quel CSS prima di sapere quale immagine caricare, un ritardo chiamato “resource load delay” che nessuna compressione può risolvere da sola.

Un caso concreto racconta bene l’impatto di questi interventi: una piattaforma eCommerce ha portato il proprio tasso di pagine con LCP “buono” dal 57% al 96% semplicemente rimuovendo transizioni dalle sezioni iniziali e aggiungendo segnali di priorità corretti sulle immagini, senza toccare l’infrastruttura server. Chi gestisce una vetrina di prodotti fotografici, come nel caso di una boutique di moda online, trova in scelte come queste sull’immagine hero e sul primo viewport uno dei margini di miglioramento più immediati disponibili.

Hosting e server: cosa controllare per ridurre il TTFB

Il piano di hosting stabilisce un limite che nessun plugin può superare. Puoi minificare, comprimere e mettere in cache tutto quello che vuoi, ma se il server impiega un secondo solo per generare la prima risposta, quel secondo resta lì.

Le tre categorie principali di hosting per WordPress si comportano in modo molto diverso sotto carico:

  • Hosting condiviso: economico, ma le risorse (CPU, RAM, worker PHP) sono divise tra centinaia di siti sullo stesso server. Va bene per siti a basso traffico, ma il TTFB peggiora rapidamente durante i picchi.
  • VPS (server virtuale privato): risorse dedicate e configurabili, richiede più competenza tecnica per la gestione ma offre margini di ottimizzazione molto più ampi.
  • Hosting managed WordPress: ottimizzato specificamente per WordPress, spesso include già una cache a livello server, aggiornamenti PHP automatici e configurazioni HTTP/2 o HTTP/3 pronte all’uso.

Tre parametri tecnici incidono più di tutti gli altri sul TTFB: la versione di PHP (le versioni 8.2 e successive sono sensibilmente più veloci delle precedenti nell’eseguire lo stesso codice), il numero di worker PHP disponibili per gestire richieste simultanee senza metterle in coda, e il supporto a HTTP/2 o HTTP/3, che permette al browser di scaricare più risorse in parallelo sulla stessa connessione.

Un vantaggio spesso sottovalutato del caching lato server rispetto ai plugin PHP è la velocità pura: una cache gestita da Nginx o Varnish serve la pagina prima ancora che WordPress si avvii, mentre un plugin di caching PHP deve comunque far partire l’intero stack per poi restituire la versione cacheata. La differenza si misura in decine di millisecondi per richiesta, che diventano rilevanti su siti con molto traffico simultaneo.

L’upgrade dell’hosting è giustificato quando il TTFB resta sopra gli 800 millisecondi anche dopo aver ottimizzato plugin e cache, oppure quando il traffico cresce e il piano attuale mostra rallentamenti nelle ore di punta. Se invece il TTFB è già sotto i 200 millisecondi, il margine di miglioramento sta quasi sicuramente altrove: immagini, JavaScript, o CSS bloccante.

Come evitare che il sito rallenti di nuovo dopo un aggiornamento

Ottimizzare una volta non basta. WordPress cambia costantemente, tra aggiornamenti di plugin, nuovi contenuti e picchi di traffico stagionali, e ognuno di questi eventi può silenziosamente peggiorare le metriche.

Un sistema di monitoraggio degli utenti reali (RUM) che tracci il p75 di LCP e INP nel tempo è la difesa più efficace contro le regressioni. Puntare a soglie basate sui percentili invece che su un singolo test evita di ottimizzare solo per condizioni ideali che pochi visitatori vivono davvero.

Alcune pratiche riducono drasticamente il rischio di sorprese:

  • Automatizza i test periodici integrando le API di PageSpeed Insights o WebPageTest in un cron job settimanale, così le regressioni emergono prima che se ne accorgano gli utenti.
  • Esegui sempre un controllo dopo ogni aggiornamento di tema o plugin, confrontando LCP e CLS con la baseline salvata in precedenza.
  • Tieni pronta una procedura di rollback (backup recente, versione precedente del plugin scaricabile) per tornare rapidamente indietro se un aggiornamento introduce un peggioramento evidente.
  • Isola le regressioni disattivando i plugin uno alla volta in un ambiente di staging, piuttosto che indovinare quale modifica ha causato il rallentamento.

La maggior parte dei guadagni reali arriva da caching e ottimizzazione delle immagini fatte bene fin dall’inizio: interventi più complessi, come il rendering lato server o la riscrittura del tema, servono solo se queste basi non bastano già a portare le metriche sotto soglia.

Quando conviene affidarsi a un professionista invece del fai-da-te

Ci sono situazioni in cui la checklist da sola non basta. Temi costruiti su page builder pesanti con dipendenze JavaScript intrecciate, siti con rendering lato server personalizzato, o layout dinamici dove l’elemento LCP cambia in base ai contenuti caricati via JavaScript, richiedono interventi di sviluppo che vanno oltre l’attivazione di un plugin.

In questi casi il fai-da-te rischia di trasformarsi in ore spese a testare combinazioni di impostazioni senza una vera diagnosi del problema. Un plugin come Beplus Performance Booster può escludere singole pagine da un’ottimizzazione troppo aggressiva, ma solo se qualcuno ha già capito quale pagina sta causando il problema e perché.

Aureonweb affronta questo problema alla radice: ogni sito, vetrina o e-commerce che sia, viene consegnato con una demo realistica visibile entro 12 ore, costruita già con attenzione alla velocità di caricamento fin dalla struttura del tema, non aggiunta dopo come rattoppo. Chi ha bisogno di un negozio online performante fin dal primo giorno può vedere, ad esempio, come un salone di parrucchieri o un’attività di ristorazione gestiscono immagini e primo viewport senza compromettere l’LCP.

La linea guida pratica è semplice: se la checklist di caching, immagini e minificazione porta le metriche sotto soglia, il fai-da-te ha già vinto. Se invece il problema persiste nonostante interventi corretti, il tempo speso a cercare la causa vale probabilmente più del costo di un intervento mirato, e i tre mesi di supporto post-lancio inclusi nell’offerta di Aureonweb coprono proprio questa fase di assestamento.

Il punto di vista sull’ottimizzazione della velocità

La maggior parte delle guide sulla velocità di WordPress tratta i plugin come una bacchetta magica: installane uno, spunta qualche casella, e il sito vola. Non funziona così, e la prova è nella stessa Web, che avverte esplicitamente contro l’illusione che comprimere le immagini risolva tutto.

Il problema più sottovalutato è la sovrapposizione di strumenti. Ho visto siti con tre plugin di caching attivi contemporaneamente, ognuno convinto di essere l’unico a gestire la pagina, che producevano contenuti serviti in modo incoerente agli utenti. La disciplina conta più della quantità di strumenti installati.

La priorità va sempre data al p75, non al punteggio perfetto ottenuto in un singolo test di laboratorio. Prima di rincorrere il punteggio 100, guarda cosa vive davvero chi visita il sito da uno smartphone di fascia media in una zona con rete instabile.

— Alessandro

Vuoi un sito veloce fin dal primo giorno, senza rincorrere plugin?

Si possono costruire siti vetrina ed e-commerce con una demo realistica pronta entro 12 ore, già impostata per caricare velocemente su mobile e desktop, senza dover intervenire dopo con una checklist di dieci punti come quella appena letta. Non è necessario effettuare un pagamento anticipato: si può vedere prima il sito e decidere dopo.

Aureonweb

Ogni sito include dominio, hosting e tre mesi di supporto post lancio, così le regressioni di performance dopo un aggiornamento vengono gestite dal fornitore del servizio. Se gestisci un negozio di moda o un’attività di artigianato, dai un’occhiata a come strutturiamo l’e-commerce per questo tipo di attività; se invece parti da zero, la pagina prodotti mostra i pacchetti disponibili per sito vetrina ed e-commerce. Un buon punto di partenza, prima ancora di scegliere, è chiedere una misurazione baseline delle prestazioni del sito attuale, così sai esattamente da dove parti.

Fonti

Per verificare ogni intervento descritto in questa guida, tieni a portata di mano questi strumenti e riferimenti:

Salva sempre i risultati della misurazione iniziale prima di intervenire: senza un confronto concreto, non saprai mai se un cambiamento ha davvero funzionato.

Domande frequenti

Perché il mio sito wordpress è lento nonostante la cache attiva?

Spesso la cache copre solo l’HTML della pagina ma non risolve immagini pesanti, script bloccanti o un TTFB alto legato all’hosting. Verifica con PageSpeed Insights quale fase del caricamento richiede più tempo prima di aggiungere altri plugin.

Come posso velocizzare il mio sito web in generale?

Le azioni con il maggiore impatto sono attivare una cache di pagina, comprimere e convertire le immagini in WebP o AVIF, e rinviare il caricamento di CSS e JavaScript non critici. Dopo ogni modifica, ricontrolla i risultati con WebPageTest per confermare il miglioramento reale.

Quali sono i migliori plugin per velocizzare un sito wordpress?

Tra i più usati ci sono W3 Total Cache e WP Super Cache per la cache di pagina, WP-Optimize per un approccio centralizzato che include anche la pulizia del database, Autoptimize per la minificazione di CSS e JS, e Beplus Performance Booster per interventi più granulari come il differimento selettivo degli script.

Come svuoto la cache di un sito wordpress?

Ogni plugin di caching ha un pulsante dedicato nel proprio pannello, di solito etichettato come “svuota cache” o “purge cache”. Se usi anche una CDN, ricordati di svuotare separatamente anche la cache della rete di distribuzione, altrimenti continuerai a vedere la versione precedente.

Quanto costa far realizzare un sito wordpress già ottimizzato?

Il prezzo dipende dal tipo di sito e dai listini disponibili sulla pagina prodotti di Aureonweb, dove sono indicati i pacchetti per sito vetrina ed e-commerce. Il mantenimento mensile che include dominio, hosting e backup settimanali è disponibile a partire da un prezzo accessibile per il sito vetrina.

Raccomandati

← Torna al blog