Core Web Vitals per WordPress: Guida all'ottimizzazione (2026)

WordPress e Core Web Vitals: La Situazione Attuale

WordPress ha un problema di prestazioni. Secondo il Core Web Vitals Technology Report (basato su dati CrUX), WordPress si posiziona costantemente dietro a Shopify, Wix e Squarespace nei tassi di superamento dei Core Web Vitals su mobile. Alla fine del 2025, solo circa il 44% dei siti WordPress su mobile supera tutti e tre i Core Web Vitals. Confrontalo con Shopify, circa al 65%, e Wix, oltre il 60%.

Questo non accade perché WordPress sia intrinsecamente lento. Il core di WordPress è leggero. Il problema è ciò che viene aggiunto sopra: temi pesanti, page builder sovraccarichi, dozzine di plugin che iniettano ciascuno il proprio JavaScript e CSS, immagini non ottimizzate e hosting condiviso economico con tempi di risposta del server lenti.

La buona notizia: poiché WordPress ti dà il pieno controllo sul codice, sull'hosting e sulla strategia di ottimizzazione, è la piattaforma in cui un'ottimizzazione esperta fa la differenza maggiore. I siti con cui lavoro superano regolarmente i Core Web Vitals su ogni pagina. La chiave è capire quali fattori specifici di WordPress influenzano ogni metrica e affrontarli sistematicamente.

I Core Web Vitals di WordPress in Numeri

Il CrUX Technology Report e HTTP Archive tracciano i tassi di superamento dei CWV per tutti i principali CMS. Ecco la situazione di WordPress alla fine del 2025:

Fonte: CrUX Technology Report via HTTP Archive, Giugno 2025. Classifiche INP dall'analisi di SearchEngineJournal.

L'intuizione chiave di questi dati: il problema di WordPress non è l'INP (85.9% di superamento, solo leggermente sotto la media). Il problema di WordPress è l'LCP, guidato da un TTFB lento. Solo il 32% dei siti WordPress ha un buon TTFB secondo i dati CrUX, rispetto a piattaforme completamente ospitate come Shopify, dove il TTFB è gestito a livello di infrastruttura. Si tratta di un problema di qualità dell'hosting, non di piattaforma.

Sui siti WordPress monitorati da CoreDash, il pattern è coerente: prima dell'ottimizzazione, l'LCP mobile mediano è tra 3.5 e 4.5 secondi. Dopo aver implementato le ottimizzazioni di hosting, caching e immagini descritte in questa guida, la mediana scende a 1.6 - 2.1 secondi. La singola modifica ad alto impatto è quasi sempre il passaggio da un hosting condiviso senza caching di pagina a un hosting gestito con caching a livello di server e una CDN, che da solo riduce tipicamente il TTFB da oltre 800ms a meno di 200ms.

Perché WordPress fatica con i Core Web Vitals

Prima di passare alle soluzioni, devi comprendere le cinque cause principali che impediscono ai siti WordPress di superare i Core Web Vitals. Ogni problema che incontro nel mio lavoro di consulenza è riconducibile a uno (o più) di questi:

1. Il peso eccessivo dei Page Builder

I page builder come Elementor, Divi e WPBakery aggiungono enormi quantità di HTML, CSS e JavaScript extra ad ogni pagina. Elementor da solo può aggiungere oltre 21 MB di codice non compresso a un'installazione WordPress. Ogni widget, animazione e opzione di stile aumenta la dimensione del DOM e il volume delle risorse che bloccano il rendering.

Il risultato: pagine appesantite con centinaia di elementi wrapper <div> non necessari, file CSS multipli caricati su ogni pagina a prescindere che i relativi widget siano usati o meno, e JavaScript che blocca il thread principale durante il caricamento della pagina. Questo danneggia direttamente l'LCP (più risorse che bloccano il rendering), l'INP (più JavaScript in competizione per il thread principale) e il CLS (ricalcoli del layout mentre si carica il CSS del builder).

Gutenberg (l'editor a blocchi nativo di WordPress) produce un HTML significativamente più pulito con un impatto sul DOM minore. Se stai costruendo un nuovo sito WordPress, considera l'uso di Gutenberg con un tema leggero come GeneratePress, Astra o Kadence, invece di un page builder pesante.

2. Sovraccarico di Plugin

Il sito WordPress medio ha da 20 a 30 plugin attivi. Ogni plugin può iniettare i propri CSS e JavaScript su ogni pagina, anche su quelle in cui non viene utilizzato. Un plugin per il modulo di contatto che carica i suoi script sulla homepage. Uno script di WooCommerce che si carica sugli articoli del blog. Un plugin slider che si carica ovunque anche se lo usi solo in una pagina.

Ho verificato siti WordPress dove la rimozione degli script di plugin inutilizzati ha ridotto il JavaScript totale di oltre il 40%. La soluzione non è necessariamente rimuovere del tutto i plugin. Si tratta del caricamento condizionale: assicurarsi che gli asset di ogni plugin si carichino solo sulle pagine in cui sono effettivamente necessari. Plugin come Perfmatters e Asset CleanUp ti offrono il controllo per singola pagina su quali script e stili caricare.

3. Immagini non ottimizzate

WordPress non forza l'ottimizzazione delle immagini per impostazione predefinita. Gli editor di contenuti caricano foto da 3000x2000 pixel direttamente dalla fotocamera, e WordPress le serve a piena risoluzione anche quando il tema le mostra larghe solo 800 pixel. L'elemento LCP sulla maggior parte delle pagine WordPress è un'immagine, e un'immagine hero non ottimizzata è la causa più comune di fallimento dell'LCP.

WordPress 5.8+ ha aggiunto il supporto nativo a WebP e WordPress 6.1+ ha introdotto il lazy loading nativo, ma queste funzionalità richiedono una configurazione corretta. Molti temi e plugin le sovrascrivono o implementano le proprie versioni (spesso peggiori). Consulta la nostra guida sull'ottimizzazione delle immagini per i Core Web Vitals per la strategia completa.

4. Hosting lento e Risposta del Server

Il Time to First Byte (TTFB) del tuo server stabilisce la base per il tuo LCP. Nessuna ottimizzazione frontend può compensare un server che impiega 800ms per rispondere. L'hosting condiviso economico (dove centinaia di siti condividono un solo server) è la causa più comune di uno scarso TTFB sui siti WordPress.

WordPress è un CMS dinamico che esegue PHP e interroga un database MySQL ad ogni richiesta di pagina (a meno che non sia configurata la cache). Senza la cache di pagina, WordPress è intrinsecamente più lento dei siti statici. Con una cache adeguata e un host di qualità, il TTFB può scendere sotto i 200ms. Senza di essa, tempi da 500ms a 1500ms sono comuni. Scopri di più nella nostra guida all'ottimizzazione del Time to First Byte.

5. Problemi nel caricamento dei Font

Molti temi WordPress caricano i Google Fonts dai server di Google, il che richiede una ricerca DNS e una connessione a un dominio esterno prima che i font possano iniziare a essere scaricati. Questo ritarda il rendering del testo (danneggiando l'LCP per gli elementi LCP basati sul testo) e può causare il Flash of Unstyled Text (FOUT) quando il web font subentra e sostituisce quello di fallback, causando CLS.

La soluzione: ospita i tuoi font localmente (self-hosting) e usa font-display: swap o font-display: optional con un font di fallback correttamente abbinato per minimizzare i layout shift.

Risolvere l'LCP su WordPress

Largest Contentful Paint misura la velocità con cui il tuo contenuto principale diventa visibile. Su WordPress, i fallimenti dell'LCP sono quasi sempre riconducibili a immagini, risorse che bloccano il rendering o una lenta risposta del server. Ecco l'ordine di priorità per risolvere l'LCP:

Identifica il tuo elemento LCP

Passa la tua pagina tramite PageSpeed Insights e cerca sotto "Diagnostics" la voce "Largest Contentful Paint element". Sulla maggior parte delle pagine WordPress, questo è l'immagine hero, l'immagine in evidenza o il primo grande blocco di testo. Conoscere qual è il tuo elemento LCP determina la tua strategia di ottimizzazione.

Precarica (Preload) l'immagine LCP

Se il tuo elemento LCP è un'immagine, aggiungi un suggerimento di preload nel tag <head> del tuo tema. In WordPress, puoi aggiungerlo tramite il file functions.php del tuo tema:

// Preload the hero image on the homepage
function preload_lcp_image() {
    if ( is_front_page() ) {
        echo '<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" fetchpriority="high">';
    }
}
add_action( 'wp_head', 'preload_lcp_image', 1 );

Aggiungi anche fetchpriority="high" direttamente al tag <img> della tua immagine LCP. WordPress 6.3+ lo fa automaticamente per la prima immagine di contenuto, ma verifica che funzioni sul tuo tema. Per la strategia completa, vedi come precaricare l'immagine LCP.

Elimina le risorse che bloccano il rendering

I temi e i plugin di WordPress spesso accodano CSS e JavaScript nel tag <head> che bloccano il rendering. Usa un plugin per le prestazioni per differire il JavaScript non critico e caricare il CSS non critico in modo asincrono. Le opzioni più efficaci:

• WP Rocket: ritarda l'esecuzione del JavaScript fino all'interazione dell'utente, genera automaticamente il CSS critico
• FlyingPress: alternativa leggera con capacità simili di differimento e CSS critico
• Perfmatters: gestione granulare degli script per singola pagina, disabilita le funzioni non utilizzate
• Il nostro plugin WP Core Web Vitals: progettato specificamente per l'ottimizzazione dei CWV con rilevamento LCP e temporizzazione avanzata delle immagini

Per il controllo manuale, vedi 14 metodi per differire il JavaScript e come generare e usare il CSS critico.

Abilita la Cache di Pagina

La cache di pagina memorizza l'HTML completamente renderizzato di ogni pagina, in modo che WordPress non debba eseguire il PHP e interrogare il database a ogni visita. Questo riduce drasticamente il TTFB, il che migliora direttamente l'LCP. La maggior parte degli host WordPress gestiti di qualità (Kinsta, SiteGround, WP Engine, Cloudways) include la cache a livello di server. Se il tuo non la possiede, installa un plugin di cache.

Configura anche una CDN per fornire pagine memorizzate nella cache da posizioni edge vicine ai tuoi visitatori. Vedi come configurare Cloudflare per le prestazioni.

Risolvere l'INP su WordPress

Interaction to Next Paint misura la velocità con cui il tuo sito risponde a clic, tap e pressioni dei tasti. I siti WordPress falliscono sull'INP a causa dell'eccessivo JavaScript sul thread principale. Le cause principali:

Il Problema del JavaScript dei Plugin

Ogni plugin installato può aggiungere JavaScript che viene eseguito a ogni caricamento di pagina. Anche se un visitatore non interagisce mai con una funzionalità, il JavaScript per quella funzionalità compete comunque per il tempo del thread principale. Quando un visitatore fa clic su un pulsante, il browser non può rispondere finché il thread principale non è libero.

Verifica i tuoi plugin in modo spietato. Per ogni plugin, chiediti: ha bisogno di essere caricato in questo tipo di pagina? Usa la scheda Coverage di Chrome DevTools per vedere quanto JavaScript rimane inutilizzato su ogni pagina. Poi usa un plugin di gestione degli script per disabilitare script specifici nelle pagine in cui non servono.

Gestione degli Script di WooCommerce

WooCommerce è uno dei maggiori responsabili dei problemi di INP su WordPress. Per impostazione predefinita, WooCommerce carica i suoi JavaScript e CSS su ogni pagina, compresi gli articoli del blog e le pagine statiche che non hanno funzionalità commerciali. Usa un plugin come Disable WooCommerce Bloat o Perfmatters per impedire agli asset di WooCommerce di caricarsi nelle pagine non appartenenti allo shop.

Differire e Ritardare gli Script di Terze Parti

Google Analytics, Facebook Pixel, Google Tag Manager, widget di chat e strumenti di marketing aggiungono tutti JavaScript che blocca il thread principale. La strategia più efficace è ritardare questi script fino alla prima interazione dell'utente (scroll, clic o pressione di un tasto). In questo modo, gli script di terze parti non influiscono minimamente sulla reattività iniziale della pagina.

La funzione "Delay JavaScript Execution" di WP Rocket lo fa automaticamente. Puoi anche implementarlo manualmente con la nostra guida sul differire il JavaScript.

Risolvere il CLS su WordPress

Cumulative Layout Shift misura il movimento imprevisto dei contenuti. I siti WordPress falliscono sul CLS a causa di dimensioni delle immagini mancanti, sostituzione dei font (font swapping) e contenuti iniettati dinamicamente.

Imposta le Dimensioni delle Immagini

Ogni tag <img> necessita di attributi espliciti width e height affinché il browser possa riservare lo spazio corretto prima che l'immagine venga caricata. WordPress li aggiunge automaticamente a partire dalla versione 5.5, ma molti temi sovrascrivono questo comportamento o usano un markup personalizzato per le immagini che omette le dimensioni. Controlla i template delle immagini del tuo tema e verifica che le dimensioni siano presenti.

Riserva Spazio per Annunci e Contenuti Dinamici

Spazi pubblicitari, banner di consenso ai cookie, popup per l'iscrizione via email e barre di notifica che iniettano contenuti dopo il caricamento della pagina sono le cause più comuni di CLS sui siti WordPress. Riserva spazio esplicito per questi elementi usando dichiarazioni CSS min-height in modo che i contenuti circostanti non si spostino quando appaiono.

Risolvi il Layout Shift legato ai Font

Quando un web font viene caricato e sostituisce il font di fallback, il testo può scorrere in modo diverso e spostare gli elementi circostanti. La soluzione è duplice: ospita localmente i tuoi font (eliminando la ricerca DNS esterna) e configura il tuo CSS per usare font-display: optional o un fallback abbinato con cura usando la proprietà CSS size-adjust. In questo modo, anche se il web font viene caricato in ritardo, il testo non si sposta. Per una guida completa, vedi la nostra guida all'ottimizzazione del CLS.

Hosting WordPress e Core Web Vitals

Il tuo provider di hosting stabilisce il tetto massimo delle prestazioni per il tuo sito WordPress. Ecco come i principali tipi di hosting influenzano i Core Web Vitals:

Se il tuo TTFB è costantemente superiore a 400ms, nessuna ottimizzazione frontend ti permetterà di ottenere un buon LCP. Migliora prima di tutto il tuo hosting. Gli host WordPress gestiti come SiteGround, Kinsta e Cloudways offrono cache a livello di server, PHP 8.x e integrazione CDN che riducono drasticamente il TTFB.

I dati CrUX confermano che questo è il problema più grande di WordPress: solo il 32% dei siti WordPress ha un buon TTFB, rispetto a piattaforme completamente gestite come Shopify e Wix, dove l'infrastruttura è inclusa. I dati dal campo di CoreDash mostrano lo stesso pattern. I siti WordPress su hosting condiviso hanno una media p75 di TTFB tra 900ms e 1400ms. Lo stesso sito spostato su un hosting gestito con cache a livello di server scende a 120ms - 250ms. Questa singola modifica sposta spesso l'LCP da "scadente" a "buono" senza alcuna altra ottimizzazione.

Page Builder: Prestazioni a Confronto

La scelta del page builder (o la decisione di non usarne alcuno) è la più grande decisione architettonica che influenza i Core Web Vitals su WordPress. Ecco cosa vedo costantemente durante le mie analisi:

Se stai già usando Elementor o Divi e non puoi migrare, abilita le loro funzioni di "Output DOM ottimizzato" e "Caricamento asset ottimizzato", rimuovi i widget e le animazioni non utilizzati, e usa un plugin di cache come WP Rocket per compensare il peso extra.

I dati dal campo di CoreDash provenienti dai siti WordPress raccontano la stessa storia. I siti creati con Gutenberg e temi leggeri raggiungono costantemente un LCP mobile mediano inferiore a 2.0 secondi. I siti in Elementor prima dell'ottimizzazione mostrano tipicamente un LCP mobile mediano tra 3.8 e 5.2 secondi, con il divario quasi interamente attribuibile a CSS e JavaScript aggiuntivi che bloccano il rendering. Dopo l'ottimizzazione (CSS critico, JS differito, DOM ridotto), i siti in Elementor possono raggiungere i 2.0 - 2.8 secondi, ma richiedono una manutenzione continua poiché gli aggiornamenti dei plugin e dei builder spesso reintroducono appesantimenti.

La Checklist per l'Ottimizzazione dei Core Web Vitals su WordPress

Ecco l'approccio sistematico che utilizzo per ottimizzare i siti WordPress per i Core Web Vitals. Segui questi passaggi nell'ordine indicato:

Infrastruttura (fallo prima di tutto)

• Passa a un hosting WordPress gestito con cache a livello di server e PHP 8.x
• Configura una CDN (guida di configurazione Cloudflare)
• Abilita la cache di pagina (a livello di server o tramite WP Rocket / LiteSpeed Cache)
• Abilita la compressione GZIP o Brotli

Tema e Builder

• Passa a un tema leggero (GeneratePress, Astra, Kadence) se possibile
• Se usi un page builder, abilita l'output DOM e il caricamento degli asset ottimizzati
• Rimuovi funzionalità del tema, widget e animazioni non utilizzati
• Aggiorna il core di WordPress, il tema e tutti i plugin all'ultima versione

Immagini

• Precarica l'immagine LCP con fetchpriority="high"
• Converti le immagini in WebP o AVIF usando ShortPixel, Imagify o Smush
• Servi immagini responsive con attributi srcset e sizes adeguati
• Aggiungi width e height espliciti a tutti i tag <img>
• NON attivare il lazy loading per le immagini above the fold (peggiora l'LCP)

JavaScript e CSS

• Differisci i JavaScript non critici
• Ritarda gli script di terze parti fino all'interazione dell'utente
• Genera e usa il CSS critico in linea
• Rimuovi gli script dei plugin non utilizzati per pagina tramite Perfmatters o Asset CleanUp
• Disabilita gli asset di WooCommerce nelle pagine non appartenenti allo shop

Font

• Ospita in locale i Google Fonts
• Precarica i file dei font critici
• Usa font-display: swap o optional
• Limita le famiglie di font a un massimo di 2

Monitoraggio

• Imposta CoreDash Real User Monitoring per tracciare continuamente i dati dal campo
• Controlla settimanalmente il report Core Web Vitals in Google Search Console
• Riesegui il test dopo ogni aggiornamento di tema, modifica di plugin o aggiornamento di contenuti

Per la checklist completa multipiattaforma che copre tutte le aree di ottimizzazione, consulta la nostra Checklist Definitiva per i Core Web Vitals.

Misurare i Core Web Vitals su WordPress

WordPress non dispone di report integrati per i Core Web Vitals. Hai bisogno di strumenti esterni per misurare le tue prestazioni:

• Google Search Console: mostra quali pagine superano o falliscono sull'intero sito, basandosi su dati reali CrUX dal campo. Controlla il report "Core Web Vitals" sotto la voce "Esperienza".
• PageSpeed Insights: testa i singoli URL con dati dal campo (CrUX) e dati di laboratorio (Lighthouse). Usalo per diagnosticare pagine specifiche.
• CoreDash: Real User Monitoring che ti fornisce dati sul campo in tempo reale, suddivisi per pagina, dispositivo, paese e singoli elementi. A differenza della finestra mobile di 28 giorni di CrUX, CoreDash mostra l'impatto immediato dei tuoi cambiamenti.
• Chrome DevTools: usa il pannello Performance per identificare i task lunghi che bloccano l'INP e la scheda Coverage per trovare i JavaScript e CSS inutilizzati.

Per un confronto completo di questi strumenti, vedi la nostra panoramica sui Core Web Vitals che include una tabella di confronto degli strumenti di misurazione.

Errori Comuni sui Core Web Vitals in WordPress

Nella mia esperienza analizzando centinaia di siti WordPress, questi sono gli errori che incontro più spesso:

• Lazy loading dell'immagine LCP. WordPress aggiunge loading="lazy" alle immagini in automatico. Se l'immagine hero è il tuo elemento LCP, il lazy loading ne ritarda il caricamento. Assicurati che l'immagine LCP sia esclusa dal lazy loading e abbia fetchpriority="high".
• Troppi plugin di ottimizzazione. Installare WP Rocket, Autoptimize, LiteSpeed Cache e W3 Total Cache contemporaneamente crea conflitti. Scegli un solo plugin di cache/ottimizzazione e configuralo correttamente.
• Ignorare i dati dal campo. Un punteggio Lighthouse di 95 non significa che tu stia superando i Core Web Vitals. Google usa i dati dal campo (field data) di visitatori reali. I tuoi visitatori reali su dispositivi reali potrebbero avere un'esperienza completamente diversa. Controlla sempre Search Console o usa un sistema RUM.
• Non testare dopo gli aggiornamenti. L'aggiornamento di un tema o di un plugin può far regredire silenziosamente i tuoi Core Web Vitals. Monitorali continuamente, non solo dopo l'ottimizzazione iniziale.