Cosa sono i Core Web Vitals?

I Core Web Vitals sono un insieme di metriche specifiche e misurabili che Google utilizza per valutare l'esperienza utente reale di una pagina web. Si concentrano su tre aspetti fondamentali di come una pagina viene percepita dai visitatori: quanto velocemente appare il contenuto principale, quanto velocemente la pagina risponde all'interazione e quanto stabile è il layout durante il caricamento. Google utilizza i Core Web Vitals come segnale di ranking ufficiale nei risultati di ricerca da giugno 2021, il che significa che queste metriche influenzano direttamente dove il tuo sito WordPress appare nei risultati di ricerca.

I tre Core Web Vitals spiegati

Ogni Core Web Vital misura una dimensione diversa dell'esperienza utente e ognuno ha una soglia specifica che definisce le prestazioni "buone", "da migliorare" e "scarse".

Largest Contentful Paint (LCP)

LCP misura quanto tempo impiega il più grande elemento di contenuto visibile per essere renderizzato completamente sullo schermo. Questo è di solito un'immagine hero, un grande blocco di testo o un poster video. L'orologio inizia quando l'utente naviga per la prima volta sulla pagina e si ferma quando quel più grande elemento termina di disegnare.

• Buono: 2,5 secondi o meno
• Da migliorare: tra 2,5 e 4,0 secondi
• Scarso: oltre 4,0 secondi

LCP è la metrica che riflette più direttamente la velocità di caricamento percepita. Una pagina può avere un veloce Time to First Byte (TTFB) ma comunque un LCP scarso se l'elemento più grande impiega molto tempo a renderizzarsi a causa di immagini grandi, risorse che bloccano il rendering o risposte server lente per asset critici.

Interaction to Next Paint (INP)

INP ha sostituito First Input Delay (FID) come Core Web Vital nel marzo 2024. Mentre FID misurava solo il ritardo della primissima interazione, INP misura la reattività di tutte le interazioni durante la vita della pagina. Traccia clic, tap e input da tastiera e registra il tempo dall'interazione a quando il browser effettivamente aggiorna lo schermo. Il valore finale INP è di solito l'interazione peggiore osservata (con alcune regolazioni per gli outlier).

• Buono: 200 millisecondi o meno
• Da migliorare: tra 200 e 500 millisecondi
• Scarso: oltre 500 millisecondi

INP è una metrica più difficile da ottimizzare rispetto a FID perché copre ogni interazione, non solo la prima. Una pagina può rispondere rapidamente al primo clic ma rallentare in seguito quando JavaScript pesante viene eseguito.

Cumulative Layout Shift (CLS)

CLS misura quanto il contenuto visibile si sposta inaspettatamente mentre la pagina si carica e durante la sessione dell'utente. Ogni volta che un elemento cambia posizione senza che l'utente lo inizi (ad esempio cliccando un pulsante), quello spostamento contribuisce al punteggio CLS. Il punteggio viene calcolato moltiplicando la frazione di impatto (quanto del viewport è influenzato) per la frazione di distanza (di quanto l'elemento si è spostato).

• Buono: 0,1 o meno
• Da migliorare: tra 0,1 e 0,25
• Scarso: oltre 0,25

CLS è particolarmente frustrante per gli utenti. Immagina di cercare di cliccare un pulsante, ma appena prima che il tuo clic atterri, un annuncio si carica sopra e spinge il pulsante verso il basso. Finisci per cliccare sull'annuncio. Questo è esattamente il tipo di esperienza che CLS misura.

Come Google utilizza i Core Web Vitals come segnale di ranking

I Core Web Vitals fanno parte dei segnali di ranking "page experience" più ampi di Google, che includono anche la mobile-friendliness, HTTPS e l'assenza di interstiziali invasivi. Google valuta i Core Web Vitals utilizzando dati utente reali dal Chrome User Experience Report (CrUX). Questo significa che Google utilizza dati di campo reali da utenti Chrome reali che visitano il tuo sito, non dati di laboratorio da un singolo test. L'impatto sul ranking si applica sia ai risultati di ricerca mobile che desktop. Sebbene la rilevanza dei contenuti rimanga il fattore di ranking più forte, i Core Web Vitals possono decidere tra pagine con qualità di contenuto simile.

Misurare i Core Web Vitals

Esistono diversi strumenti per misurare i Core Web Vitals e si dividono in due categorie: dati di campo (misurazioni di utenti reali) e dati di laboratorio (test simulati).

• PageSpeed Insights: lo strumento di Google che mostra sia dati di campo (da CrUX) che dati di laboratorio (da Lighthouse). La sezione dei dati di campo mostra i punteggi reali dei Core Web Vitals basati su utenti reali degli ultimi 28 giorni. Questa è la sezione più importante perché riflette ciò che Google utilizza per il ranking.
• Google Search Console: il report Core Web Vitals raggruppa i tuoi URL per stato (buono, da migliorare, scarso) in base ai dati utente reali. Ti aiuta a identificare pattern sul tuo sito invece di controllare singole pagine.
• Chrome User Experience Report (CrUX): il dataset grezzo che alimenta PageSpeed Insights e Search Console. Puoi interrogarlo direttamente tramite l'API CrUX o BigQuery per analisi personalizzate.
• Lighthouse: uno strumento di test di laboratorio integrato in Chrome DevTools. Simula caricamenti di pagina su una connessione limitata e riporta LCP e CLS (INP richiede un'interazione utente reale e non può essere misurato in modo affidabile in condizioni di laboratorio). Utile per il debug ma non riflette l'esperienza utente reale.
• Estensione Chrome Web Vitals: un'estensione del browser che mostra i punteggi Core Web Vitals in tempo reale mentre navighi, rendendo facile individuare i problemi durante lo sviluppo e i test.

Dati utente reali vs dati di laboratorio

Questa distinzione è più importante di quanto molti proprietari di siti realizzino. I dati di laboratorio (da Lighthouse o strumenti simili) simulano un caricamento di pagina in condizioni controllate: un dispositivo specifico, velocità di rete e posizione. È utile per il debug e l'identificazione di problemi tecnici, ma non riflette ciò che sperimentano i visitatori effettivi. I dati utente reali (dati di campo) provengono da utenti Chrome reali che visitano il tuo sito. Catturano l'intera gamma di dispositivi, velocità di rete e posizioni geografiche che i tuoi visitatori utilizzano. L'algoritmo di ranking di Google utilizza dati di campo, non dati di laboratorio. Una pagina può ottenere un punteggio di 95 in Lighthouse ma avere comunque scarsi Core Web Vitals sul campo perché gli utenti reali su dispositivi più lenti hanno un'esperienza diversa.

Problemi WordPress comuni per LCP

I siti WordPress spesso lottano con LCP a causa di diversi problemi comuni:

• Immagini hero grandi e non ottimizzate: un'immagine hero da 3 MB impiega molto più tempo a scaricarsi e renderizzarsi rispetto a una versione WebP correttamente compressa da 200 KB. Comprimi sempre le immagini, usa formati moderni (WebP o AVIF) e fornisci immagini di dimensioni appropriate per lo schermo del visitatore.
• CSS e JavaScript che bloccano il rendering: quando il browser incontra file CSS o JavaScript nell'<head>, deve scaricarli e analizzarli prima di poter renderizzare il contenuto. Troppi o troppo grandi fogli di stile rallentano significativamente l'LCP. Inline il CSS critico e rinvia i fogli di stile non essenziali per risolvere questo problema.
• Tempo di risposta lento del server (TTFB): se il tuo server di hosting impiega 2 secondi solo per generare l'HTML, il tuo LCP non può essere inferiore a 2,5 secondi. Aggiorna l'hosting, abilita il caching lato server e usa un CDN per ridurre il TTFB.
• Troppi plugin: ogni plugin aggiunge potenzialmente CSS e JavaScript a ogni pagina. I siti con 30+ plugin attivi spesso hanno dozzine di risorse che bloccano il rendering in competizione per la larghezza di banda.
• Attributo fetchpriority mancante: l'elemento LCP dovrebbe avere fetchpriority="high" per segnalare al browser di scaricarlo per primo. Senza questo, il browser potrebbe dare priorità ad altre risorse rispetto a quella più importante.

Problemi WordPress comuni per INP

I problemi INP in WordPress sono di solito riconducibili all'esecuzione di JavaScript:

• JavaScript pesante dai plugin: slider, popup, analytics, widget di chat e plugin di condivisione social aggiungono tutti JavaScript che gira sul thread principale. Quando un utente clicca qualcosa, il browser potrebbe dover eseguire altri script prima di poter rispondere.
• Script di terze parti: Google Analytics, Facebook Pixel, script pubblicitari e strumenti di chat dal vivo spesso eseguono task lunghi che bloccano il thread principale. Caricare questi script con async o defer aiuta, ma consumano comunque tempo di elaborazione.
• Dimensione DOM eccessiva: le pagine con migliaia di elementi DOM (comuni con page builder come Elementor o Divi) impiegano più tempo per il browser ad aggiornarsi quando si verificano interazioni. Un clic che cambia una classe CSS può attivare costosi ricalcoli di stile su migliaia di elementi.
• Task lunghi del thread principale: qualsiasi task JavaScript che gira per più di 50 millisecondi è considerato un "task lungo" che blocca la reattività. Suddividere task grandi in parti più piccole utilizzando pattern requestAnimationFrame o setTimeout può aiutare.

Problemi WordPress comuni per CLS

Gli spostamenti del layout sui siti WordPress sono di solito causati da:

• Immagini senza attributi di larghezza e altezza: quando un'immagine si carica senza dimensioni esplicite, il browser non sa quanto spazio riservare. Il contenuto sottostante si sposta quando l'immagine viene finalmente renderizzata. Imposta sempre gli attributi width e height sulle immagini (WordPress lo fa automaticamente per le immagini aggiunte tramite la libreria multimediale).
• Caricamento dei webfont: i font personalizzati che si caricano dopo il rendering iniziale possono causare un rifluire del testo quando il font viene scambiato. Usa font-display: swap in combinazione con il preload dei font per minimizzare questo effetto, o considera font-display: optional per font non critici.
• Iniezioni di annunci: gli annunci che si caricano dinamicamente spingono il contenuto in giro. Riserva spazio per gli slot pubblicitari con contenitori di dimensioni fisse, anche prima che l'annuncio si carichi.
• Contenuto iniettato dinamicamente: banner di consenso ai cookie, popup di newsletter e barre di notifica che appaiono dopo il caricamento della pagina possono spostare il contenuto se vengono inseriti nel flusso del documento invece di sovrapposti.
• Embed e iframe senza dimensioni: video YouTube, tweet e altri contenuti incorporati senza dimensioni esplicite causano spostamenti quando si caricano.

Migliorare i Core Web Vitals per WordPress

Ecco un approccio pratico per migliorare ogni metrica su un sito WordPress:

• Per LCP: ottimizza e comprimi le immagini (usa WebP/AVIF), usa un CDN, abilita il caching lato server, inline il CSS critico, rinvia JavaScript non essenziale e aggiungi fetchpriority="high" all'immagine LCP. Rimuovi i plugin non utilizzati che aggiungono risorse che bloccano il rendering.
• Per INP: controlla e rimuovi JavaScript non necessario, rinvia gli script di terze parti, riduci la dimensione del DOM (considera page builder più leggeri o blocchi WordPress nativi) e suddividi task JavaScript lunghi in parti più piccole. Usa la scheda Performance in Chrome DevTools per identificare quali script bloccano il thread principale.
• Per CLS: imposta dimensioni esplicite su tutte le immagini, video e iframe. Precarica i font e usa font-display: swap. Riserva spazio per annunci e contenuti dinamici. Evita di inserire contenuto sopra il contenuto esistente dopo il caricamento della pagina.

Cosa controlla InspectWP

InspectWP analizza più fattori che impattano direttamente sui punteggi Core Web Vitals. Verifica la compressione HTTP (che influisce sull'LCP), l'uso di HTTP/2 (che consente il caricamento parallelo delle risorse), il numero di file JavaScript e CSS (che possono causare blocchi del rendering e influenzare sia LCP che INP), opportunità di ottimizzazione delle immagini, dimensione del documento HTML e altri indicatori relativi alle prestazioni. Questo ti dà un quadro chiaro di ciò che deve essere migliorato per ottenere migliori punteggi Core Web Vitals.