Guida all'Ottimizzazione della Velocità di WordPress (da uno sviluppatore che ha fatto oltre 100 audit di performance)

By Luca Ottolini · WordPress Developer since 2002 · Codeable Certified Expert

Ottimizzo la velocità dei siti WordPress da prima che esistessero i Core Web Vitals, da prima che Google rendesse la velocità di pagina un fattore di ranking, da prima che "performance" diventasse una parola di marketing per ogni azienda di hosting. Oltre 20 anni di sviluppo e più di 100 audit di performance su Codeable mi hanno insegnato una cosa che la maggior parte delle guide all'ottimizzazione della velocità non ti dirà: la maggior parte dei problemi di velocità di WordPress deriva da appena cinque cause di fondo, e risolverle nell'ordine giusto è più importante che conoscere ogni possibile tecnica di ottimizzazione.

Questo non è un elenco di 87 consigli. È un approccio sistematico — lo stesso che uso su veri progetti dei clienti — organizzato per impatto. Ti dirò cosa sistemare per primo, quali strumenti usare e quando il problema è il tuo codice rispetto a quando il problema è il tuo hosting.

Prima di ottimizzare qualsiasi cosa: diagnostica per prima cosa

L'errore più grande che vedo commettere ai proprietari di siti è buttarsi subito sull'ottimizzazione senza capire cosa è davvero lento. Installano un plugin di caching, attivano il lazy loading, minificano il CSS — e il sito è ancora lento perché il vero problema era un tempo di risposta del server di 1.200 ms che nessuna ottimizzazione frontend può correggere.

Ecco il mio flusso di lavoro diagnostico per ogni nuovo audit:

Passo 1: misura la baseline. Faccio girare il sito su Google PageSpeed Insights e GTmetrix. Non una volta — almeno tre volte, da posizioni diverse. Cerco coerenza, non un singolo risultato fortunato. Presto attenzione ai punteggi dei Core Web Vitals, che nel 2026 sono:

  • LCP (Largest Contentful Paint): Dovrebbe stare sotto i 2,5 secondi. È la tua velocità di caricamento percepita — quanto in fretta compare il contenuto principale.
  • INP (Interaction to Next Paint): Dovrebbe stare sotto i 200 millisecondi. Ha sostituito il FID nel 2024 e misura quanto la pagina risulta reattiva quando gli utenti vi interagiscono. È la metrica che la maggior parte dei siti oggi non supera.
  • CLS (Cumulative Layout Shift): Dovrebbe stare sotto 0,1. Misura se gli elementi saltano da una parte all'altra mentre la pagina si carica.

Passo 2: individua la categoria del collo di bottiglia. Il problema è lato server (TTFB lento, hosting inadeguato), frontend (immagini non ottimizzate, risorse che bloccano il rendering, troppo JavaScript) o strutturale (troppi plugin, database gonfio, tema scritto male)?

Passo 3: correggi in ordine di impatto. Questo è cruciale. Ottimizzare le immagini quando il TTFB è di 1.200 ms è come lucidare la carrozzeria di un'auto con il motore rotto. Sistemi prima le fondamenta, poi risali lo stack.

Livello 1: Hosting — le fondamenta che rendono possibile tutto il resto

Ho messo l'hosting al primo posto perché, dopo oltre 100 audit, è l'unico fattore che determina il tuo tetto massimo di velocità. Puoi fare tutto il resto alla perfezione — immagini perfette, plugin ridotti al minimo, tema leggero — e avere comunque un sito lento se il tuo hosting non riesce a fornire una risposta rapida del server.

Cosa cerco in un audit:

TTFB (Time to First Byte): È il tempo che passa tra il momento in cui un browser richiede la tua pagina e quello in cui riceve il primo byte della risposta. Riflette la velocità di elaborazione del tuo server — esecuzione PHP, query al database e configurazione del server.

Un buon TTFB è sotto i 200 ms. Un TTFB accettabile è sotto i 600 ms. Qualsiasi valore oltre i 600 ms è un problema che nessuna ottimizzazione frontend risolverà.

Sull'hosting condiviso vedo regolarmente valori di TTFB tra 800 ms e 1.500 ms. Sono da 800 a 1.500 ms di tempo morto prima che il browser possa anche solo iniziare a renderizzare la pagina. Su Kinsta, vedo costantemente un TTFB sotto i 200 ms — spesso sotto i 100 ms per le pagine in cache. Non è marketing — è ciò che misuro su veri siti dei clienti.

Perché l'hosting condiviso uccide le prestazioni:

Il problema di fondo dell'hosting condiviso è che il tuo sito condivide le risorse del server — CPU, memoria, I/O del disco — con centinaia di altri siti. Quando il sito del tuo vicino riceve un picco di traffico, il tuo sito rallenta. Quando un altro sito sul server esegue un plugin scritto male che consuma risorse eccessive, il tuo sito rallenta. Non hai alcun controllo, e la soluzione del provider di hosting di solito è "passa a un piano più costoso".

L'hosting WordPress gestito come Kinsta risolve questo isolando il tuo sito nel suo container sull'infrastruttura di Google Cloud Platform. Le tue risorse sono tue. Il picco di traffico di nessun altro incide sulle tue prestazioni.

Il fattore CDN:

Se i tuoi visitatori arrivano da più regioni geografiche — e quasi sicuramente è così — una CDN (Content Delivery Network) è essenziale. Senza, ogni richiesta viaggia fino al tuo server di origine, ovunque esso sia. Un visitatore a Tokyo che accede a un server ad Amsterdam aggiunge 200-300 ms di latenza solo per la fisica — la velocità della luce lungo i cavi in fibra ottica.

Kinsta include la CDN enterprise di Cloudflare, che mette in cache i tuoi contenuti su server edge in tutto il mondo. Combinata con l'edge caching delle pagine HTML, questo significa che un visitatore a Tokyo ottiene una risposta in cache da un server vicino, non un viaggio di andata e ritorno attraverso il pianeta.

Il mio consiglio: Se il tuo TTFB è costantemente oltre i 400 ms, sistema l'hosting prima di fare qualsiasi altra cosa. Ne ho parlato in dettaglio nel mio articolo sulle migrazioni di hosting — con numeri reali di prima e dopo tratti da progetti dei clienti.

Livello 2: Il tema — lo scheletro del tuo sito

Dopo l'hosting, il tema è il secondo fattore per impatto. Ed è qui che molti siti WordPress sbagliano.

Il problema dei page builder:

I page builder più diffusi — Elementor, Divi, WPBakery — rendono facile progettare le pagine visivamente. Ma hanno un costo: aggiungono enormi quantità di CSS e JavaScript a ogni pagina, che quella pagina usi o meno quelle funzionalità. Ho fatto l'audit di siti in cui il solo page builder aggiungeva 1-2 MB di CSS e 500 KB di JavaScript a ogni caricamento di pagina.

Per un'azienda che ha bisogno di un sito ad alte prestazioni, questo sovraccarico è inaccettabile. La comodità visiva si paga in velocità.

Cosa uso al suo posto:

Costruisco i siti dei clienti con GeneratePress Premium. Non è appariscente, non è drag-and-drop visivo e non ha un budget di marketing che lo renda un nome noto. Ma è veloce. L'intero tema, con tutti i moduli attivati, aggiunge circa 30 KB a una pagina. Confrontalo con gli 1-2 MB di un page builder.

GeneratePress mi dà pieno controllo grazie a hook puliti, un sistema di griglia CSS e una struttura logica che rende lo sviluppo efficiente. I clienti non notano su quale tema è costruito il loro sito — notano che si carica in fretta.

Come valutare l'impatto del tuo tema sulle prestazioni:

Ecco un test rapido che puoi fare da solo: attiva un tema WordPress predefinito (come Twenty Twenty-Five) ed esegui un test PageSpeed. Poi torna al tuo tema e testa di nuovo. La differenza ti dice quanto sovraccarico aggiunge il tuo tema. Se è più di 0,5 secondi, il tuo tema è un problema.

Livello 3: Plugin — gli assassini silenziosi delle prestazioni

È qui che passo più tempo durante gli audit, perché il sovraccarico da plugin è il problema di prestazioni più comune che incontro sui siti WordPress.

L'equivoco: "Più plugin significa un sito più lento." Non è esattamente vero. Ho visto siti con oltre 40 plugin caricarsi in meno di 1 secondo, e siti con 12 plugin impiegarci 6 secondi. Il problema non è il numero di plugin — è la qualità e la necessità di ciascuno.

Cosa rallenta davvero un sito:

Plugin che caricano risorse su ogni pagina. Molti plugin caricano i loro file CSS e JavaScript su ogni singola pagina del sito, anche su pagine che non usano la funzionalità di quel plugin. Un plugin per moduli di contatto che carica i suoi script sui tuoi articoli del blog. Un plugin slider che si carica su pagine senza slider. Un plugin di condivisione social che carica 200 KB di JavaScript sulla tua pagina della privacy policy.

Plugin che fanno query eccessive al database. Alcuni plugin interrogano il database a ogni caricamento di pagina per verificare impostazioni, condizioni o contenuti dinamici. Query mal ottimizzate — soprattutto quelle senza un'indicizzazione adeguata — possono aggiungere centinaia di millisecondi a ogni caricamento di pagina.

Plugin che "telefonano a casa". Alcuni plugin effettuano richieste HTTP esterne a ogni caricamento di pagina — controllano aggiornamenti, caricano risorse remote, inviano dati analitici. Ognuna di queste richieste aggiunge latenza e può bloccare il rendering della pagina.

Il mio processo di audit per i plugin:

Uso Query Monitor — un plugin WordPress gratuito che rivela esattamente quali plugin fanno query al database, caricano script e consumano risorse su ciascuna pagina. È lo strumento di debug più utile dell'ecosistema WordPress.

Quando faccio l'audit del sito di un cliente, guardo:

  • Quali plugin caricano risorse su pagine dove non servono
  • Quali plugin fanno più query al database
  • Quali plugin aggiungono più richieste HTTP
  • Se qualche plugin effettua chiamate API esterne a ogni caricamento di pagina

Poi rimuovo ciò che non è necessario, sostituisco i plugin pesanti con alternative più leggere e carico le risorse in modo condizionale solo sulle pagine dove servono. Questo da solo di solito migliora il tempo di caricamento di 1-3 secondi.

Un plugin che merita una menzione: Perfmatters è un plugin di performance leggero che ti dà un controllo granulare sul caricamento degli script. Puoi disattivare script specifici di plugin su pagine specifiche — per esempio, impedendo agli script di WooCommerce di caricarsi sugli articoli del blog. È proprio questo tipo di ottimizzazione chirurgica a fare la differenza.

Livello 4: Immagini — il frutto a portata di mano

Le immagini sono di solito le risorse più pesanti di qualsiasi pagina WordPress. Ottimizzarle è la vittoria di performance più immediata e quella dall'impatto più visibile.

Le basi che contano ancora:

Dimensioni corrette. Non caricare un'immagine da 4000×3000 pixel e lasciare che WordPress la ridimensioni via CSS. Carica le immagini alle dimensioni con cui verranno visualizzate. Un'immagine hero che viene mostrata a 1200 px di larghezza non deve essere un file largo 4000 px.

Formati moderni. Il WebP offre una compressione decisamente migliore del JPEG a parità di qualità visiva. Se sei su Kinsta, la loro CDN converte automaticamente le immagini in WebP per i browser che lo supportano — non devi fare nulla. Se non sei su Kinsta, un plugin come ShortPixel o Imagify può gestire la conversione.

Lazy loading. WordPress 5.5+ include il lazy loading nativo per le immagini. Questo significa che le immagini sotto la piega non si caricano finché l'utente non ci scorre sopra. Un'eccezione importante: non applicare mai il lazy loading alla tua immagine LCP. L'LCP (Largest Contentful Paint) è di solito la tua immagine hero o il primo grande elemento visivo della pagina. Applicarvi il lazy loading ne ritarda la comparsa, il che danneggia direttamente il tuo punteggio LCP.

Dimensioni esplicite. Ogni immagine dovrebbe avere gli attributi width e height nell'HTML. Senza, il browser non sa quanto spazio riservare prima che l'immagine si carichi, causando lo spostamento dei contenuti quando compare — che è esattamente ciò che misura il CLS (Cumulative Layout Shift).

Precarica la tua immagine LCP. Se il tuo elemento LCP è un'immagine, aggiungi un hint di preload nell'head della pagina:

html

<link rel="preload" as="image" href="hero-image.webp">

Questo dice al browser di iniziare a scaricare l'immagine immediatamente, prima di scoprirla nell'HTML. Sui siti che ho ottimizzato, questa singola modifica ha migliorato l'LCP di 300-500 ms.

Livello 5: Database — il collo di bottiglia nascosto

Il database di WordPress accumula scorie nel tempo. Revisioni degli articoli, transient scaduti, metadati orfani, commenti spam, articoli cestinati — tutto questo rallenta le query al database.

Cosa pulisco in ogni progetto di ottimizzazione:

Revisioni degli articoli. WordPress salva per impostazione predefinita ogni versione salvata di ogni articolo e pagina. Un articolo modificato 50 volte ha 50 revisioni. Moltiplicalo per centinaia di articoli e la tua tabella wp_posts si gonfia. Io limito le revisioni a 5 e cancello quelle in eccesso.

Transient. Sono valori temporanei messi in cache nel database. Alcuni plugin creano centinaia di transient e non li puliscono mai. I transient scaduti andrebbero cancellati regolarmente.

Opzioni con autoload. Il wp_options contiene impostazioni che WordPress carica a ogni singola richiesta di pagina. Alcuni plugin vi memorizzano grandi quantità di dati con autoload impostato su yes. Ho visto siti in cui i dati con autoload superavano i 5 MB — sono 5 MB di query al database a ogni caricamento di pagina.

Metadati orfani. Quando cancelli un articolo, i suoi metadati non sempre vengono cancellati. Con il tempo si accumulano. Lo stesso vale per i metadati dei commenti, degli utenti e dei termini.

Come farlo: Plugin come WP-Optimize gestiscono la maggior parte di questo con un clic. Su Kinsta, puoi anche usare il loro strumento integrato di ricerca e sostituzione nel database e l'accesso a phpMyAdmin per pulizie più chirurgiche.

Una nota sui database WooCommerce: I siti WooCommerce accumulano sovraccarico nel database più in fretta dei siti normali — dati degli ordini, dati di sessione, transient dai gateway di pagamento e dai calcolatori di spedizione. L'ottimizzazione del database WooCommerce è una disciplina a sé, ed è uno dei motivi per cui consiglio sempre un hosting gestito con adeguate risorse di database per qualsiasi sito WooCommerce.

Livello 6: Caching — il moltiplicatore

Il caching è l'aspetto più frainteso delle prestazioni di WordPress. Incontro regolarmente siti che eseguono due o tre plugin di caching contemporaneamente, ognuno che si contende il controllo con l'altro.

Come funziona il caching (in breve):

Senza caching, ogni richiesta di un visitatore fa sì che WordPress esegua codice PHP, interroghi il database, assembli la pagina e invii il risultato. Con il caching, quella pagina assemblata viene memorizzata e servita direttamente — saltando del tutto il sovraccarico di PHP e database.

I livelli di caching che contano:

Caching di pagina a livello di server. È la forma di caching dall'impatto maggiore, e dovrebbe essere gestita dal tuo provider di hosting, non da un plugin. Su Kinsta, il caching di pagina a livello di server è integrato e configurato automaticamente. Combinato con il loro edge caching tramite Cloudflare, le pagine in cache vengono servite dal server edge più vicino in millisecondi.

È per questo che di norma non consiglio plugin di caching su Kinsta — entrano in conflitto con il caching integrato. L'eccezione è WP Rocket, che Kinsta ha reso specificamente compatibile disattivando il caching di pagina di WP Rocket pur consentendone le funzioni di ottimizzazione (minificazione, lazy loading, pulizia del database).

Object caching. Mette in cache i risultati delle query al database. Redis è lo standard per l'object caching, e Kinsta lo offre come componente aggiuntivo. Per i siti con molte query al database — soprattutto WooCommerce — l'object caching può ridurre drasticamente il carico sul database e velocizzare le pagine dinamiche che non possono essere messe in cache di pagina (come le pagine di carrello e checkout).

Caching del browser. Dice ai browser dei visitatori di ritorno di riutilizzare le risorse già scaricate (CSS, JavaScript, immagini) invece di scaricarle di nuovo. Header di cache adeguati sono essenziali e di solito si configurano a livello di server.

Caching CDN. Le risorse statiche (immagini, CSS, JavaScript, font) vengono messe in cache sui server edge della CDN in tutto il mondo. Su Kinsta questo è gestito automaticamente tramite la loro integrazione con Cloudflare.

Il mio consiglio sul caching: Lascia che sia il tuo hosting a gestire il caching quando possibile. Se il tuo host non offre un caching integrato (il che è un campanello d'allarme), usa WP Rocket — è il miglior plugin di performance all-in-one che ho testato.

Livello 7: Ottimizzazione frontend — l'ultimo miglio

Una volta che le fondamenta sono solide (hosting, tema, plugin, immagini, database, caching), l'ottimizzazione frontend fornisce la rifinitura finale.

Ottimizzazione di CSS e JavaScript:

Rimuovi il CSS inutilizzato. La maggior parte dei temi e dei plugin fornisce CSS per funzionalità che potresti non usare. Strumenti come Coverage in Chrome DevTools rivelano quanto CSS di una pagina viene effettivamente usato. Rimuovere il CSS inutilizzato riduce la dimensione dei file e velocizza il rendering.

Rinvia il JavaScript non critico. Il JavaScript che non serve per il rendering iniziale della pagina andrebbe rinviato o caricato in modo asincrono. Questo gli impedisce di bloccare il processo di rendering del browser. Plugin come Perfmatters e WP Rocket gestiscono bene questo aspetto.

Minificazione. Rimuovere spazi, commenti e caratteri non necessari dai file CSS e JavaScript. Fornisce un miglioramento piccolo ma misurabile. La maggior parte dei plugin di performance lo gestisce automaticamente.

Ottimizzazione dei font:

I web font personalizzati sono un comune colpevole per le prestazioni. Ogni file di font può pesare 20-100 KB, e un sito che usa 3-4 pesi di font potrebbe scaricare 200-400 KB di dati di font prima che qualsiasi testo diventi visibile.

Il mio approccio:

  • Limitarsi a un massimo di 2 pesi di font (regular e bold)
  • Usare font-display: swap così il testo resta visibile mentre i font si caricano
  • Precaricare i font critici per iniziare a scaricarli prima
  • Valutare i font di sistema per il testo del corpo — non aggiungono alcun tempo di caricamento e hanno un aspetto perfettamente professionale

Script di terze parti:

Google Analytics, Facebook Pixel, widget di chat, tag di marketing, script per A/B test — sono spesso i maggiori colpevoli per le prestazioni su siti per il resto ottimizzati. Ogni script di terze parti aggiunge lookup DNS, tempo di connessione ed esecuzione di JavaScript alla tua pagina.

Consiglio di fare l'audit di ogni script di terze parti sul tuo sito e chiederti: "Sta davvero fornendo un valore che giustifica il suo costo in prestazioni?" Ti sorprenderebbe quanti clienti eseguono script di analisi che non controllano mai, widget di chat che nessuno usa e pixel di marketing per campagne finite mesi fa.

L'ordine di ottimizzazione che conta

Se da questo articolo ti porti via una sola cosa, che sia questa: l'ordine in cui ottimizzi conta quanto ciò che ottimizzi.

Ecco la sequenza che seguo su ogni progetto:

  1. Hosting — Sistema le fondamenta. Se il tuo TTFB è oltre i 400 ms, niente altro conta finché non si risolve questo. Kinsta è il mio consiglio di riferimento.
  2. Tema — Valuta se vale la pena costruire sul tuo tema. Se è un page builder pesante, considera il passaggio a un'alternativa leggera come GeneratePress.
  3. Plugin — Fai un audit senza pietà. Rimuovi ciò che non è necessario. Sostituisci i plugin pesanti con alternative più leggere. Carica gli script in modo condizionale.
  4. Immagini — Ridimensiona, comprimi, usa WebP, applica il lazy loading (tranne all'immagine LCP) e aggiungi dimensioni esplicite.
  5. Database — Pulisci revisioni, transient, dati con autoload e metadati orfani.
  6. Caching — Assicurati un adeguato caching a livello di server, valuta l'object caching per i siti dinamici, verifica la configurazione della CDN.
  7. Frontend — Rinvia il JavaScript, rimuovi il CSS inutilizzato, ottimizza i font, fai l'audit degli script di terze parti.

Farlo in ordine inverso — che è ciò che suggerisce la maggior parte delle guide — significa rifinire i dettagli mentre le fondamenta sono rotte. Sistema prima le cose grandi.

Quando ti serve un professionista

Ho esposto qui l'intera metodologia di ottimizzazione, e un proprietario di sito a suo agio con la tecnica può gestirne molta in autonomia. Ma ci sono situazioni in cui coinvolgere uno sviluppatore esperto fa risparmiare tempo ed evita errori:

  • Il tuo sito è un asset che genera fatturato e downtime o errori non sono accettabili
  • Usi WooCommerce e ti serve un'ottimizzazione che non rompa le funzioni di carrello/checkout
  • Il tuo TTFB è lento e ti serve qualcuno che gestisca una migrazione di hosting come si deve
  • Hai provato a ottimizzare e i tuoi punteggi non sono migliorati — il problema potrebbe essere nel codice, non nella configurazione
  • Ti serve un audit di performance che identifichi i veri colli di bottiglia, non solo quelli ovvi

È esattamente il tipo di lavoro che faccio su Codeable — audit di performance, ottimizzazione della velocità, migrazioni di hosting e costruzione di siti veloci fin dalle fondamenta. Se vuoi lavorare con me, puoi trovarmi su Codeable.

In Conclusione

WordPress non è lento per natura. WordPress mal configurato è lento. La piattaforma in sé, con l'hosting giusto, un tema leggero, plugin scelti con cura e un'ottimizzazione adeguata, è in grado di fornire caricamenti di pagina sotto il secondo.

Dopo oltre 100 audit, lo schema è sempre lo stesso: la maggior parte dei problemi di velocità deriva da un numero ristretto di cause di fondo, e risolverle nell'ordine giusto produce risultati notevoli. I clienti che vedono i miglioramenti maggiori sono quelli che partono dall'hosting e risalgono, invece di partire da ritocchi frontend e chiedersi perché nulla è cambiato.

La velocità non è una funzionalità — è una fondamenta. Tutto il resto che costruisci sul tuo sito — la tua strategia di contenuti, la tua SEO, la tua ottimizzazione delle conversioni, la tua user experience — funziona meglio quando il sito è veloce.

Rendilo veloce per prima cosa. Poi rendilo tutto il resto.

Sono Luca Ottolini — costruisco siti web dal 2002 e sono Codeable Certified WordPress Expert. Amo fare siti web che siano sia belli che veloci. Se volete lavorare con me, trovarmi su Codeable o visitate lucaottolini.com.

Strumenti e risorse menzionati in questo articolo: