Migliorare i Core Web Vitals su WordPress non significa installare un plugin di cache e inseguire 100/100 in Lighthouse. Significa individuare l’elemento, l’interazione o lo spostamento che peggiora l’esperienza reale e correggerne la causa senza rompere il sito.
Le tre metriche sono LCP per il caricamento del contenuto principale, INP per la reattività e CLS per la stabilità visiva. Vanno lette al 75° percentile e separate per mobile e desktop.
Risposta breve: quali valori deve raggiungere WordPress?
- LCP: 2,5 secondi o meno.
- INP: 200 millisecondi o meno.
- CLS: 0,1 o meno.
Queste soglie devono essere raggiunte per almeno il 75% delle visite nel segmento analizzato. I dati reali di CrUX o RUM hanno priorità per valutare l’esperienza; i test di laboratorio servono a riprodurre e diagnosticare.
Field data e lab data: non sono intercambiabili
| Fonte | Cosa mostra | Uso corretto |
|---|---|---|
| Search Console | Gruppi di URL basati su dati reali CrUX | Individuare problemi diffusi e monitorare |
| PageSpeed Insights | Dati di campo disponibili e test Lighthouse | Confrontare esperienza e diagnosi |
| Chrome DevTools | Trace, rete, main thread e layout shift | Trovare la causa su una pagina riproducibile |
| RUM proprietario | Utenti, template e contesti del sito | Segmentare e validare l’impatto reale |
Perché PageSpeed cambia tra un test e l’altro
Un test di laboratorio dipende da rete simulata, dispositivo, posizione, carico del server, cache e contenuti terzi. I dati di campo aggregano esperienze avvenute in condizioni diverse e si aggiornano su finestre temporali.
Non considerare una singola esecuzione come una veritĂ assoluta. Ripeti i test, conserva il contesto e confronta la stessa URL con condizioni simili.
LCP: trovare l’elemento principale
Largest Contentful Paint misura quando viene renderizzato il più grande blocco di testo, immagine o video visibile nel viewport. Su WordPress l’elemento LCP è spesso hero image, featured image, titolo o banner.
La diagnosi va divisa in quattro parti:
- Time to First Byte;
- ritardo nella scoperta della risorsa;
- durata del download;
- ritardo di rendering.
Comprimere l’immagine aiuta soltanto se il problema è il trasferimento. Se il browser scopre la hero dopo l’esecuzione di JavaScript, devi correggere markup e priorità . Se il server risponde lentamente, serve lavorare su cache, database o infrastruttura.
Interventi LCP frequenti su WordPress
- rendere l’immagine LCP disponibile nell’HTML iniziale;
- non applicare lazy loading all’elemento LCP;
- usare
fetchpriority="high"solo sulle risorse davvero prioritarie; - fornire immagini responsive e formati efficienti;
- ridurre CSS e font che bloccano il rendering;
- migliorare cache di pagina e risposta del server;
- evitare slider che nascondono la prima immagine dietro JavaScript.
INP: misurare le interazioni lente
Interaction to Next Paint valuta la latenza delle interazioni durante la visita. Non misura soltanto il primo clic. Menu, filtri, ricerca, form, selettori di variante e pulsanti possono contribuire.
Un INP alto nasce spesso da task JavaScript lunghi, callback pesanti, rendering complesso o troppi script terzi. Su WordPress, page builder, tag manager, chat, heatmap, advertising e plugin possono competere per il main thread.
Interventi INP frequenti
- identificare l’interazione lenta con RUM o DevTools;
- ridurre JavaScript non necessario;
- caricare script soltanto sui template che li usano;
- spezzare task lunghi e restituire controllo al main thread;
- ridurre dimensione e complessitĂ del DOM;
- fornire feedback immediato all’utente;
- limitare componenti terzi non essenziali.
Ritardare ogni script fino al primo clic può spostare il costo proprio sull’interazione e peggiorare INP. Testa il comportamento, non soltanto il caricamento iniziale.
Riprodurre una interazione lenta
Scegli un’azione reale: aprire il menu, selezionare una variante, usare un filtro o inviare un form. Registra una sessione nel pannello Performance di Chrome sul template interessato e controlla attività lunghe, gestori dell’evento e aggiornamenti del layout attorno all’interazione. Ripeti con condizioni comparabili; un test di caricamento iniziale può non esercitare l’azione problematica.
Disattiva in staging un componente alla volta per verificare l’ipotesi, poi ripristina e applica la correzione mirata. Ritardare indiscriminatamente tutto il JavaScript può peggiorare il primo clic o rompere consenso e acquisto. Il criterio di accettazione include interazione funzionante, comportamento accessibile e assenza di regressioni. La misura di campo successiva verifica se il miglioramento si estende agli utenti reali.
CLS: eliminare spostamenti inattesi
Cumulative Layout Shift misura l’instabilità del layout. Le cause comuni includono immagini senza dimensioni, embed, annunci, banner inseriti tardi e font che cambiano geometria.
Interventi CLS frequenti
- impostare
widtheheighto aspect ratio per media; - riservare spazio per cookie banner, annunci ed embed;
- non inserire contenuto sopra ciò che l’utente sta leggendo;
- usare strategie font che limitino variazioni di metrica;
- testare sticky header, barre promozionali e widget;
- controllare componenti responsive a ogni breakpoint.
Uno spostamento può non comparire in un test breve se avviene dopo interazione o scroll. I dati di campo e la registrazione dei layout shift aiutano a catturarlo.
Cache WordPress: quale livello serve?
“La cache” comprende livelli diversi:
- page cache per evitare di rigenerare HTML a ogni richiesta;
- object cache per risultati di query e oggetti riutilizzati;
- browser cache per risorse statiche;
- CDN o edge cache per ridurre distanza e carico sull’origine.
La configurazione dipende dal sito. E-commerce, account e contenuti personalizzati richiedono esclusioni. Controlla HIT/MISS, cookie, purge e variazioni della cache prima di attribuire il problema al plugin.
Hosting, PHP e database
Un TTFB alto può derivare da hosting insufficiente, assenza di page cache, query lente, chiamate esterne, cron, autoload e plugin. Aggiornare PHP o aumentare risorse può aiutare, ma serve osservare log e profiler.
Ottimizzare il database non significa eseguire una pulizia aggressiva. Identifica tabelle, query e opzioni realmente coinvolte, esegui backup e testa le modifiche.
Immagini e media
Genera dimensioni adatte al layout, evita file originali enormi, usa srcset e comprimi senza degradare il contenuto. WebP e AVIF possono ridurre il peso quando supportati dal flusso.
Lazy-load per contenuti sotto la piega è utile, ma non applicarlo indiscriminatamente. Preload e alta priorità vanno riservati alla risorsa LCP; abusarne crea competizione.
Font
Riduci famiglie, pesi e set di caratteri. Ospitare localmente può dare controllo, ma richiede corretta cache e aggiornamento delle licenze. Precarica soltanto i file usati sopra la piega e verifica il comportamento di fallback.
CSS, page builder e DOM
Page builder e design system possono generare CSS e markup non utilizzati. Prima di sostituire il tema, identifica quali template e componenti incidono. Rimuovere CSS in modo automatico può rompere stati caricati dopo interazione.
Riduci wrapper inutili, componenti duplicati e variazioni non usate. Una struttura piĂą semplice aiuta rendering, manutenzione e accessibilitĂ .
Script terzi
Analytics, advertising, consent management, video, chat e recensioni possono aggiungere costi importanti. Per ogni script documenta proprietario, scopo, pagine, consenso, dimensione e impatto.
Carica la funzione quando serve, ma preserva accuratezza del tracking e conformità . Una soluzione tecnica che rende invisibile una conversione nei dati non è completa.
Ordine corretto di un progetto Core Web Vitals
- Stabilisci una baseline di campo.
- Raggruppa le URL per template.
- Scegli pagine rappresentative.
- Riproduci il problema in laboratorio.
- Identifica elemento o interazione responsabile.
- Correggi in staging.
- Testa funzionalitĂ , tracking e regressioni.
- Distribuisci in modo controllato.
- Monitora lab subito e field data nel tempo.
PrioritĂ basata su template e traffico
Non iniziare dalla pagina con il punteggio peggiore se nessuno la visita. Incrocia gravitĂ , numero di URL, traffico, conversioni e facilitĂ di intervento.
Una correzione sul template prodotto può migliorare migliaia di URL. Un’ottimizzazione su una landing rara può avere valore commerciale, ma va trattata come intervento specifico.
Core Web Vitals e SEO
Google usa i Core Web Vitals nei sistemi di ranking, ma chiarisce che punteggi buoni non garantiscono la prima posizione. Pertinenza e qualitĂ del contenuto restano centrali. Non sacrificare informazioni o funzionalitĂ utili per ottenere un numero perfetto.
Inserisci la diagnosi nella piĂą ampia checklist SEO WordPress e nella checklist tecnica.
Checklist finale
- Field data verificati al 75° percentile.
- Mobile e desktop separati.
- URL raggruppati per template.
- Elemento LCP identificato.
- Interazioni INP lente riprodotte.
- Layout shift attribuiti a componenti reali.
- Cache e TTFB misurati.
- Plugin e script terzi inventariati.
- Immagini, font e CSS ottimizzati selettivamente.
- Checkout, form e tracking testati.
- Monitoraggio post-rilascio attivo.
VelocitĂ utile, non cosmetica
Un progetto Core Web Vitals riuscito rende piĂą rapido e stabile il percorso reale delle persone. La metrica indica dove guardare; la diagnosi decide cosa cambiare.
Field data e lab data rispondono a domande diverse
Per migliorare i Core Web Vitals WordPress, prima separa esperienza osservata e diagnosi riproducibile. I field data aggregano visite reali, dispositivi e reti differenti; i test di laboratorio aiutano invece a isolare una regressione in condizioni controllate. Un buon risultato di Lighthouse non annulla un INP scarso negli utenti reali, e un dato di campo non identifica da solo lo script responsabile.
| Metrica | Soglia “buona” | Domanda diagnostica |
|---|---|---|
| LCP | ≤ 2,5 s | Quale elemento diventa il contenuto principale e quando viene scoperto? |
| INP | ≤ 200 ms | Quale interazione occupa il main thread e ritarda il frame successivo? |
| CLS | ≤ 0,1 | Quale componente cambia geometria senza input dell’utente? |
Le soglie ufficiali sono valutate al 75° percentile, separando mobile e desktop, secondo la guida Web Vitals. Trattale come confini diagnostici, non come promessa di ranking o conversione.
Esempio: LCP lento soltanto nelle pagine prodotto
Il campione di campo mostra LCP critico sui prodotti mobile, mentre articoli e categorie sono stabili. Il test identifica l’immagine hero caricata da uno slider che attende JavaScript e non espone correttamente la risorsa prioritaria. L’intervento non è “installare un altro plugin di cache”: è correggere il template, le dimensioni responsive e la priorità della risorsa, poi controllare che zoom, varianti e analytics continuino a funzionare.
Definisci un budget di rilascio per ogni template: variazione di LCP, INP e CLS, peso JavaScript, richieste terze e tempo server. Raccogli Real User Monitoring quando il traffico lo consente, annota deploy e confronta finestre omogenee. La guida WordPress alla performance inquadra cache, contenuti statici, database e server come parti dello stesso sistema; misurarle insieme evita ottimizzazioni cosmetiche.
