Ottimizzare i Core Web Vitals su WordPress nel 2026

Introduzione: il vero tema non è la velocità, è il compromesso

Gran parte delle guide sui Core Web Vitals risponde a una domanda che nessuno si pone davvero: come rendo molto veloce una pagina vuota? La domanda reale, quella che affrontano agenzie e team tecnici, è l'opposta: come conservo un sito che fa delle cose — consenso, ricerca a faccette, carrello, recensioni, analytics — e supero comunque le soglie?

Da qui parte questa guida. Non propone di togliere funzionalità finché il punteggio non sale: quella strategia funziona nella dashboard e fallisce in produzione, perché un sito che non converte più non ha nemmeno bisogno di essere veloce. Propone un metodo di arbitraggio, metrica per metrica, con il costo reale di ogni funzionalità e la contromisura tecnica corrispondente.

Un caso si presenta più di tutti gli altri, e per questo ha una sezione propria: il banner di consenso. È obbligatorio, compare prima di ogni altra cosa, nella metà dei casi è iniettato da una terza parte — ed è oggi una delle prime cause di spostamento visivo misurato sul web. È quindi l'esempio perfetto della tensione affrontata qui: un vincolo non negoziabile che danneggia una metrica e che si ripara senza essere rimosso.

1. Cosa misura davvero Google (e perché il punteggio Lighthouse vi inganna)

Tre metriche compongono i Core Web Vitals nel 2026:

INP ha sostituito FID a marzo 2024. Se la vostra documentazione interna parla ancora di First Input Delay, descrive un indicatore che non esiste più — e la differenza non è cosmetica. FID misurava solo il ritardo prima che venisse gestita la prima interazione: un sito poteva bloccarsi due secondi a ogni clic successivo e restare verde. INP misura la latenza completa — ritardo di input, elaborazione e disegno successivo — su quasi tutte le interazioni della visita, e riporta la peggiore (o quasi, sulle pagine con moltissime interazioni). Molti siti comodamente verdi con FID sono passati al rosso senza che una riga cambiasse.

Il secondo malinteso è ancora più costoso: il punteggio che Google usa non viene da Lighthouse. Viene dal CrUX, l'insieme delle misure raccolte dai veri visitatori Chrome. Tre conseguenze pratiche:

• Conta il 75° percentile, non la media. Tre visite su quattro devono rientrare nella soglia. Una minoranza di visitatori su smartphone di fascia media in 4G basta a far fallire una pagina che a voi appare istantanea.
• La finestra è mobile su 28 giorni. Una correzione rilasciata oggi non si legge domani nei dati di campo; si legge gradualmente e pienamente dopo un mese. È la prima causa di falsi verdetti di fallimento — si annulla una buona correzione perché «non ha cambiato niente» dopo tre giorni.
• Lighthouse è un laboratorio, su una macchina senza estensioni, senza cache di terze parti, spesso senza il vostro banner nel suo stato reale. È eccellente per diagnosticare una causa e molto debole per validare un risultato.

Regola di metodo: si diagnostica in laboratorio, si conclude sul campo. Un audit che cita solo punteggi Lighthouse non misura ciò che Google valuta.

2. LCP: scomporre prima di ottimizzare

L'LCP non è un blocco monolitico. Si scompone in quattro segmenti, e l'errore più comune è ottimizzare quello sbagliato:

1. TTFB — tempo al primo byte. Hosting, database, assenza di cache.
2. Ritardo di caricamento della risorsa — l'intervallo tra l'arrivo dell'HTML e l'inizio effettivo del download dell'immagine (o del testo) che costituisce l'LCP.
3. Durata di caricamento della risorsa — il download in sé.
4. Ritardo di rendering — l'intervallo tra risorsa disponibile e disegno effettivo.

Su WordPress la distribuzione è molto sbilanciata: TTFB e ritardo di caricamento dominano, mentre la durata del download è raramente il problema principale. In altre parole, comprimere ancora l'immagine di testata migliora il segmento più corto.

Ciò che muove il TTFB:

• cache delle pagine lato server, più una cache di oggetti persistente (Redis) per le query ripetute;
• la caccia a query lente, opzioni autoload sovradimensionate e meta_query non indicizzate — Query Monitor le espone in pochi minuti;
• la riduzione del lavoro svolto su tutte le pagine da plugin che servono solo su una.

Ciò che muove il ritardo di caricamento:

• identificare il vero elemento LCP — spesso l'immagine in evidenza, a volte solo un titolo reso con un font remoto;
• non applicare mai loading="lazy" a quell'elemento: è l'anti-ottimizzazione più diffusa su WordPress, perché il lazy loading globale è attivo per impostazione predefinita;
• assegnargli fetchpriority="high" e precaricare la risorsa quando viene scoperta tardi (immagine di sfondo CSS, carosello);
• rimuovere i fogli di stile bloccanti non necessari alla prima schermata;
• servire i font con font-display: swap e auto-ospitarli — un font di terze parti aggiunge una risoluzione DNS e un handshake TLS al percorso critico.

Una leva più recente merita attenzione: su un funnel prevedibile (pagina categoria → prodotto), le regole di speculazione permettono al browser di preparare la navigazione successiva. L'LCP percepito della seconda pagina diventa quasi nullo. Da usare con parsimonia: si anticipa un'intenzione probabile, non tutto il menu.

3. CLS: lo spostamento è quasi sempre un'altezza non riservata

Il CLS ha una causa unica in cinque varianti: qualcosa compare e spinge il contenuto già disegnato. La risposta è sempre la stessa — riservare lo spazio prima che arrivi.

• Immagini e video: sempre width e height, oppure aspect-ratio in CSS. Un'immagine senza dimensioni è uno spostamento garantito.
• Pubblicità ed embed (mappe, player, widget di recensioni): un contenitore con altezza minima fissata. Un iframe che si ridimensiona dopo il caricamento sposta tutto ciò che sta sotto.
• Font: il passaggio dal font di fallback a quello definitivo cambia la metrica del testo e sposta le righe. font-display: swap unito a override di metriche (size-adjust, ascent-override) rende la sostituzione quasi invisibile.
• Contenuto iniettato in cima alla pagina: barra promozionale, avviso di stock, barra di traduzione. Inseriti nel flusso, spostano l'intera pagina.
• Il banner di consenso — vedi la sezione 5, perché merita più di una riga.

Due precisazioni che fanno risparmiare tempo. Primo: il CLS si misura per tutta la vita della pagina, non solo al caricamento; uno spostamento causato da un clic su un accordion conta anch'esso (a meno che non avvenga nella finestra di 500 ms successiva a un'interazione dell'utente — gli spostamenti attesi, come l'apertura di un menu, sono esclusi). Secondo: content-visibility: auto sulle sezioni sotto la linea di piega riduce il lavoro di rendering senza creare spostamenti, purché si fornisca un contain-intrinsic-size credibile.

4. INP: la metrica che punisce le funzionalità mal cablate

È qui che il compromesso «funzionalità contro prestazioni» si gioca davvero, perché l'INP misura esattamente ciò che le funzionalità consumano: il thread principale.

Un'interazione si scompone in tre fasi: ritardo di input (il thread è occupato, l'evento attende), elaborazione (girano i vostri gestori di eventi) e ritardo di presentazione (il browser ricalcola e disegna). Un INP scarso si spiega quasi sempre con task lunghi — blocchi di JavaScript oltre i 50 ms che monopolizzano il thread.

Cosa fabbrica task lunghi su WordPress:

• script di terze parti caricati in modo sincrono nell'head;
• un gestore di eventi legato a un numero enorme di elementi invece di essere delegato a un antenato comune;
• chiamate a cascata ad admin-ajax.php dove basterebbe un unico endpoint REST;
• l'idratazione di componenti interattivi su tutte le pagine quando servono solo su una;
• lavoro sincrono innescato dal primo scorrimento o dal primo movimento del mouse.

Le contromisure, in ordine di resa:

1. Spezzare il lavoro. Restituire il controllo al browser tra i pezzi, con scheduler.yield() dove disponibile e una cessione di task classica altrove. Un'elaborazione di 400 ms divisa in otto pezzi da 50 ms produce un INP accettabile a parità di tempo totale.
2. Rinviare ciò che non è visibile. Caricare il codice di un componente quando l'utente si avvicina, non al caricamento della pagina.
3. Togliere le terze parti dal thread principale quando possibile, o almeno caricarle in modo asincrono dopo il primo disegno.
4. Non pagare per ciò che non si mostra. La deregistrazione condizionale di stili e script per template è la leva più redditizia di WordPress, e la più trascurata.
5. Preservare la cache di ritorno. Un header Cache-Control: no-store o un listener unload dimenticato disattiva il ritorno istantaneo alla pagina precedente — una regressione invisibile a ogni audit di laboratorio.

5. Il caso del consenso: obbligatorio, costoso e riparabile

Ecco la situazione reale. La normativa impone consenso preventivo e blocco effettivo degli script non essenziali. Il banner deve dunque comparire presto, sopra ogni cosa, e il codice di misurazione deve attendere. Ognuno di questi vincoli colpisce una metrica diversa:

• CLS: il banner è l'archetipo del contenuto iniettato in cima alla pagina. Inserito nel flusso, sposta l'intera pagina; e poiché compare alla prima visita di ogni utente, colpisce esattamente il traffico che Google misura.
• INP: una soluzione di terze parti carica uno script di gestione del consenso prima che sia possibile qualsiasi interazione. Se quello script è pesante e sincrono, la prima interazione — spesso il clic sul banner stesso — diventa la più lenta della visita.
• LCP: paradossalmente, bloccare gli script prima del consenso migliora l'LCP. I tag di analytics e pubblicitari non competono più con il contenuto principale. Un banner ben costruito rende il primo disegno più rapido, non più lento.

Da cui un metodo preciso, e non un compromesso:

1. Sovrapporre, non inserire. Un banner in position: fixed sta fuori dal flusso: copre invece di spingere. Spostamento nullo per costruzione. Questo singolo punto è ciò che ribalta il CLS.
2. Rendere il banner lato server. Generato nell'HTML iniziale invece di essere iniettato via JavaScript, è presente al primo disegno — quindi nessuna comparsa tardiva e nessuno script sul percorso critico.
3. Separare presentazione e logica. L'HTML e il CSS del banner sono minimi; il peso sta nella libreria che gestisce categorie, prove e registro. Nulla obbliga a caricare quest'ultima prima del clic dell'utente.
4. Conservare le prove sulla propria infrastruttura. Un consenso registrato nel vostro database evita un viaggio verso un servizio terzo sul percorso critico — e vi appartiene, cosa che conta almeno quanto le prestazioni.
5. Verificare lo stato dopo il consenso. La vera trappola sta dopo il clic: tutti gli script autorizzati si risvegliano insieme e fabbricano un task lungo di diverse centinaia di millisecondi. Vanno liberati in modo scaglionato.

Il tema in sé è trattato in profondità nella nostra guida tecnica GDPR e cookie per WordPress, e il confronto tra le soluzioni esistenti nella nostra analisi delle alternative a Complianz. Sul piano delle prestazioni pure, AIFORYA GDPR Consenso applica i cinque punti sopra per impostazione predefinita: rendering lato server, sovrapposizione, archiviazione locale delle prove.

6. La tabella degli arbitraggi: tenere la funzionalità, pagarla meno

È il cuore di questa guida. Per ogni funzionalità costosa esiste una risposta che non consiste nel rimuoverla.

La logica comune a tutta la colonna di destra: spostare il costo al momento in cui l'utente ne ha bisogno. Quasi nessuna funzionalità deve essere pronta al millisecondo zero; quasi tutte vengono caricate come se lo fossero.

7. Misurare senza illudersi

Un protocollo in cinque punti, imparato nel modo costoso:

1. Misurare prima di correggere. Senza un punto di partenza, ogni miglioramento è una convinzione.
2. Misurare per template, non per sito. Home, categoria, prodotto, articolo e carrello hanno profili slegati. Una media di sito nasconde proprio il template che fallisce.
3. Tenere un testimone. Una pagina comparabile che non si tocca. Se migliora quanto le pagine corrette, la causa era altrove — un rilascio, un cambio di hosting, una stagione.
4. Attendere la finestra di 28 giorni prima di concludere sui dati di campo, verificando subito in laboratorio che la correzione faccia ciò che si crede.
5. Diffidare di un indicatore che non si muove mai. Una sonda che restituisce lo stesso numero dopo una modifica reale non misura ciò che credete. Succede più spesso di quanto si pensi, ed è sempre lo strumento la prima cosa da verificare.

8. Checklist operativa

Server

• Cache delle pagine attiva, cache di oggetti persistente presente
• Query lente e autoload verificati
• Compressione e HTTP/2 o superiore confermati

LCP

• Elemento LCP identificato su ogni template principale
• Nessun loading="lazy" su quell'elemento
• fetchpriority="high" impostato, preload se scoperto tardi
• Font auto-ospitati, due pesi al massimo

CLS

• Dimensioni o aspect-ratio su tutte le immagini e gli iframe
• Altezza riservata per pubblicità, recensioni, embed
• Banner di consenso in sovrapposizione, mai nel flusso
• Nessuna barra in cima alla pagina iniettata nel flusso

INP

• Nessuno script di terze parti sincrono nell'head
• Elaborazioni lunghe spezzate con cessione del thread
• Stili e script deregistrati per template
• Risveglio degli script scaglionato dopo il consenso
• Cache di ritorno preservata

Misurazione

• Dati di campo seguiti per template
• Pagina testimone non modificata conservata
• Conclusioni rinviate alla finestra di 28 giorni

Conclusione

I Core Web Vitals non chiedono un sito più povero: chiedono un sito ordinato. Le tre metriche puniscono lo stesso errore da tre angoli — lavoro svolto troppo presto, per un utente che non l'ha ancora chiesto. Il TTFB punisce il lavoro server inutile, il CLS il contenuto che arriva dopo essere stato promesso, l'INP il codice che gira prima di essere utile.

Corollario incoraggiante: la maggior parte dei guadagni non costa alcuna funzionalità. Costa rigore sul quando. E il caso del consenso lo dimostra meglio di ogni altro — l'obbligo normativo che sembrava il più ostile alle prestazioni diventa, se implementato bene, un miglioramento del primo disegno.

Per approfondire le immagini, spesso la prima fonte di guadagno sull'LCP, si veda AIFORYA Image SEO; per la strumentazione di misura e le correzioni per template, AIFORYA Page Speed Pro. Le nostre estensioni premium prevedono rimborso integrale entro 14 giorni.