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

WordPress e Core Web Vitals: lo stato attuale

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

Questo non è perché WordPress è intrinsecamente lento. Il core di WordPress è leggero. Il problema è ciò che viene aggiunto sopra: temi pesanti, page builder sovraccarichi, decine di plugin che iniettano ognuno 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 controllo completo sul codice, l'hosting e la strategia di ottimizzazione, è la piattaforma dove un'ottimizzazione competente fa la differenza più grande. 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.

Core Web Vitals di WordPress in numeri

Il CrUX Technology Report e HTTP Archive tracciano i tassi di superamento dei CWV per ogni CMS principale. Ecco dove si posiziona WordPress a fine 2025:

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

L'insight chiave da questi dati: il problema di WordPress non è INP (85,9% supera, solo leggermente sotto la media). Il problema di WordPress è LCP, causato da TTFB lento. Solo il 32% dei siti WordPress ha un buon TTFB secondo i dati CrUX, rispetto a piattaforme completamente gestite come Shopify dove il TTFB viene gestito a livello di infrastruttura. Questo è un problema di qualità dell'hosting, non della piattaforma.

Sui siti WordPress monitorati da CoreDash, il pattern è costante: prima dell'ottimizzazione, il 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. Il singolo cambiamento con il maggiore impatto è quasi sempre il passaggio da hosting condiviso senza page caching a hosting gestito con caching a livello server e un CDN, che da solo riduce tipicamente il TTFB da 800ms+ a meno di 200ms.

Perché WordPress fatica con i Core Web Vitals

Prima di passare alle soluzioni, devi capire le cinque cause principali che fanno fallire i siti WordPress sui Core Web Vitals. Ogni problema che vedo nel mio lavoro di consulenza risale a una (o più) di queste:

1. Sovraccarico del page builder

I page builder come Elementor, Divi e WPBakery aggiungono enormi quantità di HTML, CSS e JavaScript extra a ogni pagina. Solo Elementor 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 di risorse che bloccano il rendering.

Il risultato: pagine sovraccariche con centinaia di elementi wrapper <div> non necessari, file CSS multipli caricati su ogni pagina indipendentemente dal fatto che i loro widget siano utilizzati, e JavaScript che blocca il main thread durante il caricamento della pagina. Questo danneggia direttamente LCP (più risorse che bloccano il rendering), INP (più JavaScript che compete per il main thread) e CLS (ricalcoli del layout quando il CSS del builder si carica).

Gutenberg (l'editor a blocchi nativo di WordPress) produce HTML significativamente più pulito con un footprint DOM più piccolo. Se stai costruendo un nuovo sito WordPress, considera 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 il proprio CSS e JavaScript su ogni pagina, anche su pagine dove quel plugin non viene utilizzato. Un plugin per moduli di contatto che carica i suoi script sulla tua homepage. Uno script WooCommerce che si carica sui tuoi post del blog. Un plugin slider che si carica ovunque anche se lo usi solo su una pagina.

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

3. Immagini non ottimizzate

WordPress non impone l'ottimizzazione delle immagini di default. I redattori di contenuti caricano foto da 3000x2000 pixel direttamente dalla fotocamera, e WordPress le serve a piena risoluzione anche quando il tema le visualizza a soli 800 pixel di larghezza. L'elemento LCP sulla maggior parte delle pagine WordPress è un'immagine, e un'immagine hero non ottimizzata è la causa più comune di fallimento LCP.

WordPress 5.8+ ha aggiunto il supporto nativo WebP e WordPress 5.5+ ha aggiunto 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 su ottimizzare le 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 il limite inferiore per il tuo LCP. Nessuna ottimizzazione frontend può compensare un server che impiega 800ms a rispondere. L'hosting condiviso economico (dove centinaia di siti condividono un singolo server) è la causa più comune di TTFB scarso 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 configurato il caching). Senza page caching, WordPress è intrinsecamente più lento dei siti statici. Con un caching appropriato e un host di qualità, il TTFB può essere sotto i 200ms. Senza, da 500ms a 1500ms è comune. Scopri di più nella nostra guida all'ottimizzazione del Time to First Byte.

5. Problemi di caricamento dei font

Molti temi WordPress caricano Google Fonts dai server di Google, il che richiede un lookup DNS e una connessione a un dominio esterno prima che i font possano iniziare a scaricarsi. Questo ritarda il rendering del testo (danneggiando LCP per gli elementi LCP basati su testo) e può causare Flash of Unstyled Text (FOUT) quando il web font si sostituisce al fallback, provocando CLS.

La soluzione: ospita i tuoi font localmente e usa font-display: swap o font-display: optional con un font fallback correttamente abbinato per minimizzare lo spostamento del layout.

Correggere LCP su WordPress

Largest Contentful Paint misura quanto velocemente il tuo contenuto principale diventa visibile. Su WordPress, i fallimenti LCP risalgono quasi sempre a immagini, risorse che bloccano il rendering o risposta lenta del server. Ecco l'ordine di priorità per correggere LCP:

Identifica il tuo elemento LCP

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

Precarica l'immagine LCP

Se il tuo elemento LCP è un'immagine, aggiungi un suggerimento di precaricamento nel <head> del tuo tema. In WordPress, puoi aggiungerlo tramite il functions.php del 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, consulta come precaricare l'immagine LCP.

Elimina le risorse che bloccano il rendering

I temi e i plugin WordPress inseriscono frequentemente CSS e JavaScript nel <head> che bloccano il rendering. Usa un plugin di 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 di JavaScript fino all'interazione dell'utente, genera il CSS critico automaticamente
• FlyingPress: alternativa leggera con funzionalità simili di defer e CSS critico
• Perfmatters: gestione granulare degli script per pagina, disabilita le funzionalità non utilizzate
• Il nostro plugin WP Core Web Vitals: progettato specificamente per l'ottimizzazione CWV con rilevamento LCP e timing avanzato delle immagini

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

Abilita il page caching

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

Configura anche un CDN per servire le pagine memorizzate nella cache da posizioni edge vicine ai tuoi visitatori. Consulta come configurare Cloudflare per le prestazioni.

Correggere INP su WordPress

Interaction to Next Paint misura quanto velocemente il tuo sito risponde a clic, tocchi e pressioni di tasti. I siti WordPress falliscono INP a causa di JavaScript eccessivo sul main thread. Le cause principali:

Il problema del JavaScript dei plugin

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

Analizza i tuoi plugin senza pietà. Per ogni plugin, chiediti: deve caricarsi su 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 sulle pagine dove non sono necessari.

Gestione degli script WooCommerce

WooCommerce è uno dei maggiori contributori ai problemi INP su WordPress. Di default, WooCommerce carica il suo JavaScript e CSS su ogni pagina, inclusi post del blog e pagine statiche che non hanno funzionalità di commercio. Usa un plugin come Disable WooCommerce Bloat o Perfmatters per impedire il caricamento degli asset WooCommerce sulle pagine non relative allo shop.

Differisci e ritarda 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 main thread. La strategia più efficace è ritardare questi script fino alla prima interazione dell'utente (scroll, clic o pressione di tasto). In questo modo, gli script di terze parti non influenzano affatto la reattività iniziale della pagina.

La funzionalità "Delay JavaScript Execution" di WP Rocket lo fa automaticamente. Puoi anche implementarlo manualmente con la nostra guida su differire JavaScript.

Correggere CLS su WordPress

Cumulative Layout Shift misura i movimenti imprevisti del contenuto. I siti WordPress falliscono CLS a causa di dimensioni delle immagini mancanti, sostituzione dei font e contenuto iniettato dinamicamente.

Imposta le dimensioni delle immagini

Ogni tag <img> ha bisogno di attributi espliciti width e height in modo che il browser possa riservare lo spazio corretto prima che l'immagine si carichi. WordPress li aggiunge automaticamente dalla versione 5.5, ma molti temi sovrascrivono questo comportamento o usano 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 contenuto dinamico

Slot pubblicitari, banner di consenso ai cookie, popup per iscrizione email e barre di notifica che iniettano contenuto 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 il contenuto circostante non si sposti quando appaiono.

Correggi lo spostamento del layout relativo ai font

Quando un web font si carica e sostituisce il font fallback, il testo può ridisporsi e spostare gli elementi circostanti. La soluzione è duplice: ospita i tuoi font localmente (eliminando il lookup DNS esterno) e configura il tuo CSS per usare font-display: optional o un fallback accuratamente abbinato usando la proprietà CSS size-adjust. In questo modo, anche se il web font si carica in ritardo, il testo non si sposta. Per una guida completa, consulta la nostra guida all'ottimizzazione CLS.

Hosting WordPress e Core Web Vitals

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

Se il tuo TTFB è costantemente sopra i 400ms, nessuna ottimizzazione frontend ti porterà a un buon LCP. Aggiorna prima il tuo hosting. Gli hosting WordPress gestiti come SiteGround, Kinsta e Cloudways offrono caching a livello 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 è gestita. I dati di campo di CoreDash mostrano lo stesso pattern. I siti WordPress su hosting condiviso hanno un TTFB medio al p75 da 900ms a 1400ms. Lo stesso sito trasferito su hosting gestito con caching a livello server scende a 120ms - 250ms. Quel singolo cambiamento spesso sposta LCP da "scarso" a "buono" senza nessun'altra ottimizzazione.

Page builder: prestazioni a confronto

La scelta del page builder (o non usarne uno) è la singola decisione architetturale più importante che influisce sui Core Web Vitals su WordPress. Ecco cosa vedo costantemente nei miei audit:

Se stai già usando Elementor o Divi e non puoi migrare, abilita le loro funzionalità "Optimized DOM Output" e "Optimized Asset Loading", rimuovi widget e animazioni inutilizzati, e usa un plugin di caching come WP Rocket per compensare l'overhead extra.

I dati di campo di CoreDash dai siti WordPress raccontano la stessa storia. I siti costruiti con Gutenberg e temi leggeri raggiungono costantemente un LCP mobile mediano sotto i 2,0 secondi. I siti Elementor prima dell'ottimizzazione mostrano tipicamente un LCP mobile mediano da 3,8 a 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 Elementor possono raggiungere 2,0 - 2,8 secondi, ma richiedono manutenzione continua poiché gli aggiornamenti di plugin e builder reintroducono frequentemente il bloat.

La checklist di ottimizzazione Core Web Vitals per WordPress

Ecco l'approccio sistematico che uso quando ottimizzo i siti WordPress per i Core Web Vitals. Procedi con questi in ordine:

Infrastruttura (fai questo per primo)

• Passa a hosting WordPress gestito con caching a livello server e PHP 8.x
• Configura un CDN (guida alla configurazione di Cloudflare)
• Abilita il page caching (a livello 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 ottimizzato e il caricamento asset ottimizzato
• Rimuovi funzionalità, widget e animazioni del tema non utilizzati
• Aggiorna il core di WordPress, il tema e tutti i plugin alle ultime versioni

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 appropriati
• Aggiungi width e height espliciti a tutti i tag <img>
• NON applicare lazy loading alle immagini above the fold (questo danneggia LCP)

JavaScript e CSS

• Differisci il JavaScript non critico
• Ritarda gli script di terze parti fino all'interazione dell'utente
• Genera e inline il CSS critico
• Rimuovi gli script dei plugin inutilizzati per pagina usando Perfmatters o Asset CleanUp
• Disabilita gli asset WooCommerce sulle pagine non relative allo shop

Font

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

Monitoraggio

• Configura CoreDash Real User Monitoring per tracciare i dati di campo continuamente
• Monitora il report Core Web Vitals di Google Search Console settimanalmente
• Ritesta dopo ogni aggiornamento del tema, modifica dei plugin o aggiornamento dei contenuti

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

Misurare i Core Web Vitals su WordPress

WordPress non ha un report Core Web Vitals integrato. Hai bisogno di strumenti esterni per misurare le tue prestazioni:

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

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

Errori comuni di Core Web Vitals su WordPress

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

• Lazy loading dell'immagine LCP. WordPress aggiunge loading="lazy" alle immagini di default. Se la tua immagine hero è l'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 unico plugin di caching/ottimizzazione e configuralo correttamente.
• Ignorare i dati di campo. Un punteggio Lighthouse di 95 non significa che superi i Core Web Vitals. Google usa dati di campo dai visitatori reali. I tuoi visitatori reali su dispositivi reali possono avere un'esperienza completamente diversa. Controlla sempre Search Console o usa il RUM.
• Non testare dopo gli aggiornamenti. Un aggiornamento del tema o di un plugin può peggiorare silenziosamente i tuoi Core Web Vitals. Monitora continuamente, non solo dopo l'ottimizzazione iniziale.