Core Web Vitals su WordPress: Ogni Metrica Spiegata, Diagnosticata e Risolta
Google usa tre metriche per giudicare l’esperienza utente del tuo sito: LCP (quanto ci mette a caricare il contenuto principale), INP (quanto ci mette a rispondere al click), CLS (quanto si sposta il layout durante il caricamento). Insieme sono i Core Web Vitals.
Se il tuo sito WordPress fallisce anche solo una di queste tre metriche, Google lo penalizza nel ranking mobile. Non è una supposizione: è un fattore di ranking confermato dal 2021 e rafforzato con l’aggiunta di INP nel marzo 2024.
Questo articolo copre tutte e 3 le metriche con la diagnostica specifica per WordPress: dove trovare il problema, cosa lo causa, e come risolverlo con codice reale.
Le 3 Metriche e le Soglie Google
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo di caricamento dell’elemento più grande visibile | ≤ 2.5s | 2.5-4s | > 4s |
| INP (Interaction to Next Paint) | Latenza della peggiore interazione dell’utente | ≤ 200ms | 200-500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Quanto si sposta il layout durante il caricamento | ≤ 0.1 | 0.1-0.25 | > 0.25 |
I dati vengono da utenti reali (Chrome User Experience Report, CrUX), non da test sintetici. Il tuo Lighthouse può dare 100, ma se i visitatori reali hanno LCP > 4s su mobile 3G, Google lo sa.
LCP: Il Più Comune Problema su WordPress
Cos’è l’elemento LCP
L’elemento LCP è il pezzo più grande di contenuto visibile nel viewport iniziale. Su WordPress, di solito è:
- L’immagine hero (la più comune)
- Un blocco di testo H1 grande
- Un video o slider nel header
- Un’immagine featured post
Le 5 cause più comuni di LCP lento su WordPress
1. Immagine hero non ottimizzata (60% dei casi)
Un’immagine hero da 2MB caricata senza lazy loading, senza dimensioni specificate, in formato JPEG non compresso. Fix:
<!-- Prima (lento) -->
<img src="hero.jpg">
<!-- Dopo (veloce) -->
<img src="hero.webp"
width="1200" height="600"
fetchpriority="high"
decoding="async"
alt="Descrizione">
L’attributo fetchpriority="high" dice al browser di scaricare questa immagine prima di tutto il resto. Fondamentale per l’elemento LCP.
2. Server lento (TTFB alto)
Se il Time to First Byte supera 800ms, l’LCP non può essere sotto 2.5s. Le cause WordPress: hosting economico, nessuna cache di pagina, PHP non ottimizzato, database lento.
Fix rapido: abilita una cache di pagina (WP Super Cache, W3 Total Cache, o Nginx FastCGI cache). L’impatto è immediato: TTFB da 800ms a 100-200ms.
3. Render-blocking CSS/JS
WordPress carica 15-30 file CSS e JS nel <head> prima di renderizzare qualsiasi contenuto. Ogni file blocca il rendering.
// Defer JavaScript non critico
add_filter('script_loader_tag', function($tag, $handle) {
$defer_scripts = ['jquery-migrate', 'comment-reply', 'wp-embed'];
if (in_array($handle, $defer_scripts)) {
return str_replace(' src=', ' defer src=', $tag);
}
return $tag;
}, 10, 2);
4. Font web non precaricati
Google Fonts caricati via CSS @import bloccano il rendering fino al download. Fix:
<!-- Preload il font critico -->
<link rel="preload" href="https://fonts.gstatic.com/s/inter/v13/font.woff2"
as="font" type="font/woff2" crossorigin>
5. Plugin pesanti nel header
Slider, social widget, chat widget caricati nel header. Ognuno aggiunge 100-500ms all’LCP. Audit: apri DevTools → Performance → registra il caricamento. I file che bloccano il rendering sono evidenziati.
INP: La Metrica Che WordPress Ignora
INP ha sostituito FID (First Input Delay) nel marzo 2024. Misura la latenza della peggiore interazione dell’utente, non solo la prima. È più severa.
Cause comuni di INP alto su WordPress
JavaScript pesante nel main thread:
- jQuery + plugin jQuery (slider, lightbox, smooth scroll) che bloccano il main thread per 200-500ms durante l’interazione
- Analytics e tracking (Google Analytics, Facebook Pixel, Hotjar) che intercettano ogni click
- Page builder JavaScript (Elementor, Divi) che aggiungono handler su ogni elemento
Fix pratici:
// 1. Carica script di tracking in modo asincrono
add_action('wp_enqueue_scripts', function() {
wp_script_add_data('google-analytics', 'strategy', 'async');
});
// 2. Rimuovi jQuery Migrate (non serve da WP 5.5+)
add_action('wp_default_scripts', function($scripts) {
if (!is_admin()) {
$scripts->remove('jquery');
$scripts->add('jquery', false, ['jquery-core'], '3.7.1');
}
});
3. Riduci i layout recalc: evita CSS che triggerano layout recalculation su hover/click (es: width, height, top, left animati). Usa transform e opacity per le animazioni.
CLS: Lo Spostamento che Fa Impazzire gli Utenti
Le cause WordPress più comuni
1. Immagini senza dimensioni
WordPress 5.5+ aggiunge automaticamente width e height alle immagini nel content. Ma i temi custom e i page builder spesso le rimuovono. Verifica:
# Cerca immagini senza dimensioni
grep -r '<img' wp-content/themes/ | grep -v 'width=' | head -10
2. Font swap che causa flash
Google Fonts con font-display: swap caricano il fallback font, poi swappano al web font quando è pronto. Lo swap causa un layout shift visibile.
Fix: usa font-display: optional per i font non critici (il browser mostra il fallback e non swappa se il font è lento). Oppure self-host i font per caricarli più velocemente.
3. Ad e embed che caricano tardi
Banner pubblicitari, embed YouTube/Twitter, widget di terze parti. Caricano dopo il contenuto e spostano tutto in basso.
Fix: riserva lo spazio con CSS aspect-ratio o dimensioni fisse:
.video-embed {
aspect-ratio: 16/9;
width: 100%;
background: #f0f0f0; /* placeholder mentre carica */
}
4. Cookie banner che spinge il contenuto
Un cookie banner che appare dall’alto e spinge tutto il contenuto in basso causa CLS. Soluzione: posizionalo fisso in basso (position: fixed; bottom: 0) o come overlay che non sposta il contenuto.
Tool per la Diagnostica
| Tool | Dati | Quando usarlo |
|---|---|---|
| PageSpeed Insights | Lab + Field (CrUX) | Primo check: vedi sia dati sintetici che reali |
| Chrome DevTools → Performance | Lab dettagliato | Debug approfondito: trace di ogni richiesta |
| Search Console → Core Web Vitals | Field (CrUX aggregato) | Monitoraggio continuo su tutti gli URL |
| Web Vitals Extension (Chrome) | Real-time nel browser | Test rapido durante lo sviluppo |
| GEO Optimizer | Meta tag + contenuto | Verifica che le ottimizzazioni non rompano la citabilità AI |
La Checklist Fix Rapido (30 Minuti)
- ☐ Abilita cache di pagina (WP Super Cache o equivalente)
- ☐ Converti immagini hero in WebP
- ☐ Aggiungi
fetchpriority="high"all’immagine LCP - ☐ Aggiungi
widtheheighta tutte le immagini - ☐ Defer JavaScript non critico
- ☐ Preload Google Fonts
- ☐ Cookie banner in position fixed bottom
- ☐ Aspect-ratio su embed video/iframe
Queste 8 azioni coprono l’80% dei problemi Core Web Vitals su WordPress. Per il restante 20%, servono ottimizzazioni server-side (trattate nel nostro articolo su velocizzare WordPress senza plugin).
FAQ
PageSpeed Insights mostra 90+ ma Search Console dice “scarso”. Perché?
PageSpeed Insights Lab data testa con una connessione standard simulata. Search Console usa i dati reali dei tuoi visitatori. Se i tuoi utenti sono su mobile con 3G lento in aree rurali, i dati reali saranno peggiori del lab. Fidati di Search Console: è quello che Google usa per il ranking.
Quale metrica prioritizzare?
LCP. È la più impattante per il ranking e la più facile da migliorare (cache + immagine ottimizzata). INP è secondo. CLS è il più facile da risolvere (dimensioni immagini + position fixed) ma ha l’impatto minore sul ranking.
I plugin di cache risolvono tutto?
Risolvono LCP (riducendo il TTFB). Non risolvono INP (che dipende dal JavaScript lato client) né CLS (che dipende dal CSS e dal layout). La cache è il primo passo, non l’unico.