LCP è cambiato anche se non hai cambiato nulla sul tuo sito? Ecco perché

In questo articolo più “tecnico” del solito, condivido una notizia a proposito di LCP, una delle tre metriche che costituiscono i Core Web Vitals.

Leggi con attenzione se ti occupi di migliorare i Core Web Vitals del tuo sito o di quello dei tuoi clienti.

A partire da fine Novembre il Largest Contentful Paint (LCP) di alcuni siti che gestisco è cambiato senza apparente motivo.

Ecco alcuni screenshot presi dalle search console di alcuni miei clienti che mostrano rispettivamente un miglioramento e un peggioramento del LCP (Largest Contentful Paint), senza che fosse stata apportata alcuna modifica ai siti 

Cos’è successo?

Il cambiamento è stato causato dal rilascio della versione 118 di Google Chrome avvenuto a Ottobre che ha introdotto dei cambiamenti nella priorità di caricamento predefinita delle immagini.
(Ho già escluso le numerose altre variabili e da buon nerd mi sono già spulciato gli access.log prima di arrivare a questa conclusione)

Ma cosa c’entra Google Chrome con LCP?

LCP misura il tempo necessario a mostrare l’elemento più grande presente nel viewport, e di solito questo elemento è un’immagine.

I Core Web Vitals vengono calcolati a partire dai dati inviati dai browser Chrome (e Android) dei visitatori del tuo sito.

Perchè se il rilascio è avvenuto a Ottobre me ne posso accorgere solo ora?

I Core Web Vitals vengono rilasciati con 28 giorni di ritardo rispetto alla data di rilevamento e rappresentano l’esperienza di almeno il 75% dei visitatori.

Non tutti gli utenti aggiornano immediatamente il browser appena esce una nuova versione ecco spiegato il perché dei due mesi di ritardo.

Cos’è successo (tecnicamente)?

Quando un sito web si carica, il primo passo è il download del documento HTML. Il browser poi analizza l’HTML per identificare le risorse da scaricare come fogli di stile, script e immagini.

Il browser da priorità alle risorse “critiche”, ovvero le risorse necessarie a disegnare la parte visibile del sito (il famoso “above the fold”).

Questo processo all’apparenza semplice, presenta un grosso problema: Il browser non ha modo di distinguere quali immagini siano più importanti semplicemente guardando l’HTML, quindi assegna loro una priorità di caricamento bassa.

Solo dopo il aver avviato il render della pagina (e aver completato il CSSOM e il DOM), il browser riconosce quali immagini sono effettivamente visibili nell’area di visualizzazione e aumenta la loro priorità.

Per questo, Chrome ha modificato il modo in cui vengono prioritizzate le immagini: da Ottobre 2023, le prime cinque immagini nel documento hanno una priorità “Media” invece di “Bassa”.
(Puoi accorgertene aprendo il Network Inspector e abilitando la colonna Priority)

Questa nuova regola tenta di identificare le immagini importanti in anticipo causando un impatto sul largest contentful paint.

Questa novità rappresenta un problema o un’opportunità?

Di fatto perdiamo il controllo della situazione perché stiamo permettendo al browser di fare “come vuole”.

Se domani il team di Chrome si sveglia e decide di applicare un’altra regola ecco che i Core Web Vitals cambieranno di nuovo.

Inoltre non tutti gli utenti usano l’ultima versione di Chrome appena questa viene rilasciata e quindi ci ritroveremo sicuramente con risultati altalenanti per mesi e mesi dato che i Core Web Vitals rappresentano il 75% degli utenti.

Personalmente preferisco essere io a decidere come si deve comportare il sito e a mantenerne il controllo indipendentemente dagli aggiornamenti di Chrome.

Cosa fare per riprendere il controllo della situazione?

La soluzione in questo caso specifico è utilizzare correttamente i Priority Hints e applicare l’attributo fetchpriority a tutte le immagini critiche (e solo a quelle)

<img src=”/performance.png” fetchpriority=”high”>

Considera che le immagini critiche dipendono dalla dimensione del viewport che a suo volta dipende dalle dimensioni dello schermo del visitatore.

Tradotto: devi assegnare valori differenti al fetchpriority poiché devi gestire in maniera differente mobile o desktop.

In uesti due casi specifici ho utilizzato il filtro di WordPress
wp_get_attachment_image_attributes

A partire invece da WP 6.3 è meglio usare:

wp_get_loading_optimization_attributes

Ora aspetterò i canonici 28 giorni per vedere il risultato dell’intervento e aggiornerò questo post.

P.S. prima di intervenire verifica quale versione di WordPress stavi utilizzando al momento della variazione di LCP, la versione 6.3 (rilasciata l’8 Agosto 2023) contiene una migliora che aggiunge “in automatico” il fetchpriority=”high” all’immagine rilevata da WordPress come LCP.

Negli esempi riportati la versione utilizzata è la 6.2.x

Spero di esserti stato utile.

Alla prossima! 😉

——————————————————

Ti occupi di SEO o di sviluppo web vuoi capire come migliorare la velocità dei siti dei tuoi clienti senza perdite di tempo e tentativi a vuoto?

Ho preparato un breve manuale operativo che contiene l’elenco completo delle azioni da compiere per ottimizzare un sito web, ordinate per priorità e impatto sui Core Web Vitals.

È un condensato di informazioni da conoscere prima di eseguire qualunque ottimizzazione.

Lo trovi a questo link >> Cheat Sheet Core Web Vitals