Come ottimizzare un sito WordPress: da dove iniziare e in quale ordine

Cerchi come velocizzare WordPress e troverà liste: trenta trucchi, cinquanta plugin, tutte le opzioni attivate. Ne segua una e comincia la solita storia. Il punteggio si muove, poi un menu non si apre più, un modulo non si invia più, e nessuno sa quale delle dieci impostazioni sia la colpevole.

Questa guida prende l’altra strada. Le dà un ordine: cosa misurare per primo, come trovare il vero problema e quale leva usare per risolverlo, dalla più sicura alla più delicata. Ogni passo rimanda a una guida dedicata quando vuole approfondire.

Che cosa significa «veloce» per Google

Google giudica la velocità di una pagina con tre indicatori, i Core Web Vitals, misurati sui suoi visitatori reali:

• LCP (Largest Contentful Paint): quando viene mostrato il contenuto principale, spesso l’immagine in alto o il titolo. Buono sotto i 2,5 s.
• INP (Interaction to Next Paint): quanto tempo impiega la pagina a reagire a un tocco o a un clic. Buono sotto i 200 ms.
• CLS (Cumulative Layout Shift): quanto salta il contenuto durante il caricamento. Buono sotto 0,1.

Il verdetto è dato al 75° percentile delle visite su 28 giorni: tre visite su quattro devono essere buone. Un singolo test lanciato dal suo computer veloce dice poco in merito.

Passo 1: misurare prima il campo, poi il laboratorio

Esistono due tipi di dati, e rispondono a domande diverse:

• I dati di campo (Search Console e la sezione in alto di PageSpeed Insights) vengono dai suoi visitatori reali. Le dicono se c’è un problema, e dove.
• I dati di laboratorio (il punteggio di PageSpeed Insights, Lighthouse) vengono da un unico caricamento simulato. Aiutano a capire perché, e a verificare subito una modifica.

Cominci dal rapporto Core Web Vitals di Search Console. Raggruppa i suoi URL per pagine simili, il che di solito significa per modello di pagina: home, articoli, schede prodotto, categorie, landing page. È l’unità su cui lavorerà, perché una correzione in un modello corregge tutte le pagine costruite su di esso.

Prima di cambiare qualsiasi cosa, annoti il punto di partenza di ogni modello: le tre metriche di campo e un test di laboratorio su mobile. Quando i due non concordano, e succede spesso, la nostra guida sui dati di laboratorio e di campo spiega come leggerli.

Passo 2: trovare quale metrica non passa, su quale modello

Ogni metrica rimanda a una famiglia di cause diversa. È questo che le evita di attivare tutto:

• LCP scarso: il server risponde tardi, oppure l’immagine principale arriva tardi (troppo pesante, scoperta tardi, caricata in lazy per errore, bloccata dietro i fogli di stile).
• CLS scarso: immagini senza spazio riservato, un font web che cambia a metà strada, un banner o un blocco inserito dopo la prima visualizzazione.
• INP scarso: troppo JavaScript sul thread principale, dal tema, dal builder o da terze parti.

Guardi anche il tempo di risposta del server (TTFB, mostrato in PageSpeed Insights). Se l’HTML stesso impiega più di circa 0,8 s ad arrivare, nessuna ottimizzazione lato browser potrà compensarlo: il passo successivo viene prima.

Passo 3: il server e la cache di pagina

WordPress costruisce ogni pagina in PHP, con query al database, a ogni visita. Una cache di pagina conserva l’HTML finito e lo serve direttamente ai visitatori successivi: è la leva con l’effetto maggiore sul tempo di risposta, e su un sito di contenuti è sicura per i visitatori anonimi.

• Un solo motore di cache, non due. Molti hosting mettono già in cache le pagine sul server. Aggiungere sopra la cache di un plugin crea due livelli che si svuotano in momenti diversi, e finisce per servire pagine scadute. Ne scelga uno che gestisca la cache di pagina.
• Controlli le basi dell’hosting: una versione di PHP supportata, e una cache degli oggetti (Redis o Memcached) se il sito è dinamico.
• I siti con account o carrello hanno bisogno di un confine tra ciò che può andare in cache e ciò che non deve mai andarci. Su WooCommerce, quel confine è tutto l’argomento della nostra guida per velocizzare un negozio WooCommerce.

Passo 4: le immagini e l’immagine principale

Le immagini sono di solito la parte più pesante di una pagina, e quella principale è spesso l’LCP. Le prime mosse sono tutte sicure, perché inviano la stessa immagine in meno byte: compressione, un formato moderno (WebP o AVIF) e la dimensione giusta per lo schermo. Se PageSpeed continua a chiederle di dimensionare correttamente le immagini nonostante un srcset, la causa è quasi sempre l’attributo sizes: veda la nostra guida su srcset e sizes.

Si occupi poi dell’immagine principale stessa:

• non la carichi mai in lazy: il lazy loading è per le immagini sotto la piega;
• aiuti il browser a trovarla presto con un preload e una priorità di caricamento alta, e se differisce tra smartphone e desktop, ne precarichi una per dispositivo;
• se è uno sfondo CSS impostato da un builder, il browser la scopre tardi: la nostra guida sugli hero con immagine di sfondo mostra le soluzioni;
• e tenga le grandi illustrazioni fuori dall’SVG inline, che appesantisce l’HTML stesso: l’SVG inline è per le icone.

Passo 5: il CSS

Il browser non mostra nulla finché non ha scaricato e letto i fogli di stile nel <head>. Su un tema con builder, possono essere diverse centinaia di kilobyte, per lo più inutilizzati nella pagina corrente. Due tecniche se ne occupano:

• Il Critical CSS: gli stili di ciò che è visibile al caricamento vengono inseriti nella pagina, e il foglio completo si carica senza bloccare.
• Il CSS utilizzato (spesso chiamato «Rimuovi CSS inutilizzato»): le regole che la pagina non usa vengono rimosse.

Entrambe sono molto efficaci, ed entrambe possono rompere qualcosa, perché giudicano da un’unica istantanea della pagina. Un menu, una finestra modale o un mini carrello chiusi in quel momento sembrano inutili, e perdono i loro stili. Come trovare la regola mancante e rimetterla: la nostra guida sugli stili mancanti, con due casi frequenti: il menu che appare aperto e il mini carrello che scompare.

Passo 6: il JavaScript e la reattività

Il JavaScript pesa su tutto: compete con l’immagine principale per la rete, e tiene occupato il thread principale quando il visitatore tocca lo schermo. La leva più forte è ritardare gli script che non servono al caricamento fino alla prima interazione. È anche la leva che rompe più siti:

• un menu che si apre solo al secondo tocco: la nostra guida sul menu hamburger;
• uno slider, un modulo o un banner di consenso che non funziona più: come trovare lo script colpevole;
• un banner di consenso che arriva tardi e trattiene il resto: la nostra guida sui banner di consenso.

Non ritardi mai ciò di cui il visitatore ha bisogno subito: lo strumento di consenso, il menu, gli script di aggiunta al carrello e di pagamento. E conosca il limite dell’esercizio: alcuni temi forniscono tutto il loro codice in un unico grande file, il che pone un tetto a qualsiasi ottimizzazione. Come riconoscerli.

Passo 7: la stabilità del layout

Un contenuto che salta raramente ha una sola grande causa, piuttosto diverse piccole: immagini senza width e height, un font web che cambia la dimensione del testo quando arriva, un banner dei cookie o una barra promozionale che spinge giù la pagina, uno slider che parte in uno stato e finisce in un altro. Riservi lo spazio, e scelga di proposito il font-display dei suoi font: swap mostra subito il testo ma può spostarlo quando arriva il font, optional non lo sposta mai ma a volte mantiene il font di riserva. I page builder aggiungono cause proprie, trattate nella nostra guida CLS per Divi ed Elementor.

Il suo builder, il suo negozio

L’ordine qui sopra vale per ogni sito WordPress. Alcune configurazioni hanno trappole proprie, con una guida dedicata:

• Divi: molto CSS e molte immagini di sfondo di serie, e opzioni che si sovrappongono a qualsiasi plugin di ottimizzazione. Velocizzare un sito Divi, passo dopo passo.
• Elementor e Divi: spostamenti del layout tipici dei builder. Correggere il CLS sui temi con builder.
• WooCommerce: cache, frammenti del carrello, immagini prodotto e script di pagamento. Velocizzare un negozio WooCommerce.

Il metodo che mantiene il sito funzionante

Non tutte le leve sono uguali. Alcune riducono solo il peso dei file o danno un’indicazione al browser, e non possono rompere nulla. Altre cambiano ciò che viene eseguito, in quale ordine o ciò che viene servito, e richiedono un test. La nostra guida sulle ottimizzazioni sicure le classifica una per una.

Con Mantys Core

In sintesi

• Legga prima i dati di campo, modello per modello: le dicono se c’è un problema e dove.
• Associ la metrica che non passa alla sua famiglia di cause: LCP a server e immagini, CLS a spazio riservato, INP a JavaScript.
• Corregga nell’ordine: server e cache di pagina, immagini, CSS, JavaScript, stabilità.
• Attivi prima le leve sicure, poi quelle delicate una alla volta, testando su mobile e desktop, senza login.
• Confermi in laboratorio subito, e sul campo quattro settimane dopo.