Velocità del blog: che cosa sono LCP, INP e CLS e come migliorarli

Per controllare le prestazioni del blog, analizza un URL pubblico in PageSpeed Insights, confronta dispositivi mobili e desktop e usa LCP, INP e CLS per valutare caricamento, reattività e stabilità del layout. Distingui i dati degli utenti reali dalla diagnostica di laboratorio, poi intervieni sulla causa della metrica problematica invece di concentrarti su un unico punteggio.

Che cosa sono LCP, INP e CLS?

I Core Web Vitals sono le principali misure di Google dell'esperienza degli utenti sul web. L'insieme attuale comprende le tre metriche seguenti. Per tutte sono preferibili valori inferiori, ma gli aspetti misurati e le unità sono diversi.

La guida di Google ai Web Vitals considera il 75º percentile, separatamente per dispositivi mobili e desktop. In termini pratici, è il valore entro il quale rientra circa il 75% delle visite osservate. Non è una media né il risultato più veloce di un singolo test. Quando tutte le metriche dispongono di dati sufficienti, devono risultare tutte buone per superare la valutazione: un buon LCP da solo non basta.

Un articolo potrebbe apparire rapidamente ma rispondere lentamente all'apertura del menu. Un altro potrebbe essere reattivo, ma spostare il testo verso il basso quando compare un annuncio. Individua l'aspetto dell'esperienza che non funziona prima di comprimere ripetutamente le immagini per un problema di “velocità” ancora indefinito.

Esegui un controllo con PageSpeed Insights

1. Scegli l'URL di un articolo accessibile senza autenticazione. Escludi gli indirizzi dell'editor e dell'anteprima.
2. Inseriscilo in PageSpeed Insights e avvia l'analisi.
3. Nel risultato per dispositivi mobili, leggi separatamente l'esperienza degli utenti reali e la diagnostica delle prestazioni.
4. Controlla anche desktop. Registra URL, data, categoria del dispositivo, metriche problematiche e risultati principali.

Invece di verificare soltanto l'ultimo articolo, scegli tipi di pagina rappresentativi: un normale testo, un post ricco di immagini e una pagina con tabelle o codice possono aiutare a distinguere problemi del modello condiviso da quelli di un contenuto specifico. Usa i formati effettivamente presenti nel blog.

Controlla se l'URL analizzato è diverso da quello inserito. Se un reindirizzamento porta il test altrove, usa la stessa destinazione finale nei confronti successivi. Registrazioni coerenti servono a giudicare le modifiche, non soltanto a far apparire migliore il punteggio.

Distingui i dati sul campo dal punteggio delle prestazioni

I dati degli utenti reali provengono dal Chrome User Experience Report, abbreviato CrUX, relativo ai precedenti 28 giorni. Se i campioni sono insufficienti, può essere mostrato il dato dell'intera origine oppure nessun dato sul campo. I dati a livello di origine comprendono le esperienze sulle pagine della stessa origine del sito, non soltanto sull'articolo. La diagnostica di laboratorio usa invece Lighthouse in un ambiente simulato. La documentazione di PageSpeed Insights spiega la distinzione.

Un punteggio delle prestazioni di 90 e il superamento dei Core Web Vitals degli utenti reali sono valutazioni differenti. Verifica se i dati sul campo riguardano l'URL specifico o l'intera origine. L'assenza di dati non certifica prestazioni buone e non dimostra un problema.

La finestra mobile di CrUX e il test Lighthouse attuale usano campioni e condizioni diversi. Il diagramma distingue le informazioni e lo scopo dei due strumenti, per chiarire che cosa confrontare dopo una modifica.

Per esempio, sostituire un'immagine può migliorare subito il risultato di laboratorio, mentre il periodo dei dati sul campo comprende ancora visite precedenti alla modifica. Verifica prima che la nuova immagine si carichi correttamente e che test confrontabili mostrino segnali di miglioramento. Esamina separatamente l'andamento degli utenti reali nel tempo.

Un INP mancante non significa zero millisecondi. PSI può dare esito positivo con dati INP insufficienti se i valori al 75º percentile di LCP e CLS sono entrambi buoni. Se mancano dati sufficienti per LCP o CLS, la valutazione non è possibile. Le regole di valutazione di PSI descrivono questa eccezione. Leggi quali dati sono effettivamente disponibili insieme all'etichetta di superamento.

Se LCP è scarso, individua che cosa ritarda il contenuto principale

Per prima cosa identifica l'elemento segnalato come contenuto più grande. Può essere l'immagine iniziale dell'articolo, un grande blocco di testo o altro. Non applicare ovunque la stessa impostazione per le immagini senza controllare l'elemento effettivo.

• Se è un'immagine, confronta le dimensioni del file fornito con quelle di visualizzazione.
• Usa dimensioni, compressione e formato adeguati, verificando dettagli importanti e leggibilità del testo.
• Controlla se l'immagine LCP nella prima schermata usa il caricamento differito, o lazy loading. Un'impostazione utile per immagini molto più in basso può ritardare quella principale.
• Se la diagnostica segnala tempi di risposta del server o risorse che bloccano il rendering, indaga anche queste cause.

La guida all'ottimizzazione di LCP distingue ritardi di individuazione, trasferimento e visualizzazione del contenuto. Se cambiare formato è appropriato, consulta come convertire le immagini in WebP. Se in seguito i visitatori ricevono ancora il vecchio file, controlla la cache e la risorsa effettivamente richiesta.

Espandi la scomposizione di LCP nella diagnostica per capire dove viene impiegato il tempo. Parti dal ritardo maggiore o evitabile, anziché trattare tutte le componenti nello stesso modo:

1. Time to First Byte (TTFB): tempo dalla navigazione al primo byte della risposta HTML. Esamina risposta del server, catene di reindirizzamento e uso della cache.
2. Resource load delay: attesa dopo quella risposta prima che inizi il download dell'immagine principale o di un'altra risorsa LCP. Verifica caricamento differito o individuazione tardiva.
3. Resource load duration: durata del download della risorsa. Dimensioni corrette e compressione intervengono direttamente su questa componente.
4. Element render delay: attesa tra l'arrivo del file e la visualizzazione dell'elemento. Script o condizioni di visualizzazione possono ancora bloccarlo: un'immagine più piccola, da sola, potrebbe non migliorare LCP complessivo.

Un elemento LCP testuale che non richiede un download separato può non avere un intervallo di caricamento della risorsa. Applica la scomposizione all'elemento realmente individuato dal test.

Se INP è scarso, esamina il lavoro dopo l'interazione

INP valuta la reattività fino al successivo aggiornamento visivo dopo un'interazione. Attività JavaScript lunghe possono occupare il thread principale del browser, che gestisce script e lavoro sullo schermo, ritardando la gestione dell'input. La guida all'ottimizzazione di INP esamina ritardo dell'input, elaborazione degli eventi e ritardo di presentazione.

Come gestore del blog, riproduci prima azioni concrete su un dispositivo mobile: apertura del menu, ricerca e uso di un collegamento dell'indice. Annota quale azione appare lenta, poi esamina plugin inutili o duplicati, widget e script esterni attivi nella pagina.

Il Total Blocking Time (TBT), cioè il tempo totale di blocco, in un test di caricamento standard di Lighthouse può indicare attività lunghe, ma non è INP. Per INP servono clic, tocchi o input da tastiera: una visita con solo scorrimento o senza interazioni può non produrre un valore. Distingui inoltre il primo riscontro visivo dopo aver premuto Cerca, come un indicatore di caricamento, dal completamento dell'intera ricerca sul server. La definizione e l'ambito di misurazione di INP spiegano questi limiti.

Evita di disattivare molti plugin contemporaneamente. Prepara un backup o un ambiente di prova e cambia una cosa alla volta per identificarne l'effetto. Se abiliti l'esecuzione ritardata di JavaScript, verifica che menu, ricerca e controlli del consenso continuino a funzionare, oltre a controllare il punteggio.

Se CLS è scarso, riserva spazio ai contenuti che si spostano

Immagini, annunci e contenuti incorporati caricati in ritardo possono spostare l'articolo o un link che il lettore sta per toccare. La guida all'ottimizzazione di CLS evidenzia le dimensioni delle immagini e lo spazio da riservare ai contenuti che arrivano dopo.

• Specifica width e height delle immagini oppure riserva un rapporto d'aspetto adatto.
• Prevedi spazio adeguato per annunci e video incorporati alle diverse dimensioni dei dispositivi.
• Controlla che uno spazio pubblicitario non riempito non si chiuda improvvisamente provocando un altro spostamento.
• Osserva testi e pulsanti quando compaiono caratteri web o banner.

L'elemento elencato nella diagnostica degli spostamenti non è necessariamente il responsabile. Un annuncio inserito sopra l'articolo può far registrare lo spostamento dell'articolo sottostante. Esamina i contenuti vicini e ciò che viene aggiunto immediatamente sopra. Un test del solo caricamento iniziale può anche non rilevare gli spostamenti di annunci o immagini che compaiono dopo lo scorrimento. Leggi l'articolo pubblico e prova anche menu e controlli del consenso.

Ridurre gli spazi vuoti mantenendo stabile il layout può richiedere un compromesso. Non dare per scontato che l'altezza di un annuncio desktop sia adatta al cellulare. Apri articoli reali e osserva gli spostamenti vicino alla parte alta, centrale e bassa dello schermo.

Ripeti il controllo in condizioni confrontabili

1. Conserva impostazioni, file e risultati originali.
2. Scegli una causa importante e applica una modifica mirata.
3. Aggiorna le cache pertinenti e verifica la risorsa modificata sulla pagina pubblica.
4. Ripeti il test sullo stesso URL e con la stessa categoria di dispositivo, poi controlla menu, immagini, annunci e layout dell'articolo.
5. Se una funzione smette di funzionare o altre metriche peggiorano, annulla la modifica e restringi nuovamente la ricerca della causa.

Quando cambi le impostazioni della cache, distingui la distribuzione delle risorse salvate dall'esecuzione ritardata degli script. Consulta che cosa fanno i plugin cache di WordPress e come sceglierli. Registra le impostazioni da ripristinare, invece di attivare più ottimizzazioni insieme.

Non dichiarare il successo sulla base di una piccola differenza in un solo test. Confronta le registrazioni e i problemi ricorrenti prima della modifica successiva. Un punteggio più alto ottenuto rompendo funzioni necessarie ai lettori non è un miglioramento utile.

Il punteggio di velocità, da solo, non determina la visibilità nei risultati di ricerca. La guida di Google all'esperienza sulle pagine afferma che i Core Web Vitals sono usati dai sistemi di ranking, ma buoni risultati non garantiscono le prime posizioni. Migliora anche la possibilità dei lettori di leggere l'articolo e completare azioni utili.