Ottimizzare l'immagine del Largest Contentful Paint

Ottimizzare l'immagine del Largest Contentful Paint

Secondo Google solo il 65% di tutte le visualizzazioni di pagina su internet (incluse sia desktop che mobile) hanno un punteggio 'buono' di Largest Contentful Paint. Ciò significa che il 35% delle visualizzazioni non supera la soglia, in parte a causa di errori commessi con le immagini. Questo articolo analizza i pattern di buone pratiche più comuni e gli errori quando le immagini diventano l'elemento Largest Contentful Paint.

Sebbene tutti questi fattori siano importanti, se il tuo elemento LCP è un'immagine (e spesso lo è!), ci sono passi semplici che puoi intraprendere per assicurarti che si carichi il più velocemente possibile!

Esperimenti con il Largest Contentful Paint

Dico sempre: ascolta e impara ma non dare per scontato la parola di nessuno. Ci sono troppi 'guru' là fuori che diffondono informazioni errate. Ecco perché ho creato un esperimento LCP completamente automatico dove puoi verificare tu stesso cosa succede quando l'elemento LCP non viene caricato in modo ottimale.  Dai un'occhiata al mio Test LCP su github o prova la demo live! 

Testerà automaticamente più scenari LCP per te e ti mostrerà i risultati. Discuterò questi scenari di seguito e spiegherò come e perché velocizzano o rallentano l'elemento immagine LCP.

1. Controlla il candidato LCP: la strategia Text-First

Il modo più veloce per migliorare il tuo Largest Contentful Paint basato su immagine? Non usare un'immagine! Aspetta, cosa? Sì, hai sentito bene. Lascia che ti spieghi.

Perché il testo è più veloce di un'immagine. La differenza di prestazioni si riduce alla pipeline delle richieste. Un nodo di testo (come un <h1> o <p>) fa parte del documento HTML principale. Non ha una richiesta di risorsa separata; il suo rendering è bloccato solo dal CSS. Un'immagine, d'altra parte, è una risorsa esterna che richiede una propria richiesta HTTP. Questo introduce latenza di rete (DNS, TCP, TLS e tempo di download) oltre ad essere bloccata dal CSS. Questa distinzione è il motivo fondamentale della differenza di prestazioni e il motivo per cui controllare il candidato LCP è una strategia potente e di livello esperto.

Quindi qual è il caso per le immagini rispetto al testo? Le immagini sono importanti, rendono il tuo sito visivamente attraente. Ma Core Web Vitals non si preoccupa di quale elemento diventa l'LCP. Quando l'elemento LCP è un elemento basato su testo, di solito coincide con il First Contentful Paint.

Quindi dovresti passare a un elemento Largest Contentful Paint basato su testo? Dipende! Le immagini contano e  rendono il tuo sito visivamente attraente. Ciò significa che non mi sentirai sostenere il passaggio a vecchi e noiosi elementi di testo. Ma gli errori accadono! Avrei un dollaro per ogni pagina di categoria caduta vittima del **pattern anti-pattern "LCP accidentale"**. Questo avviene quando una pagina "dimentica" di aggiungere un testo descrittivo di categoria above the fold, causando il caricamento lazy di un'immagine prodotto che diventa l'LCP e ritardando i tempi di caricamento di secondi. Questo accade spesso quando i designer posizionano un grande banner hero in cima al DOM, prima di qualsiasi titolo significativo, lasciando al browser nessuna scelta se non quella di selezionare un candidato LCP più lento.

2. Usa il formato immagine più veloce disponibile

Senza entrare in un acceso dibattito sulla compressione dell'ultimo byte o le impostazioni perfette per WebP vs. AVIF, concordiamo su una cosa: i formati più vecchi come JPEG e PNG sono più grandi e più lenti rispetto ai formati moderni come WebP o AVIF. Se vuoi un approfondimento, questo articolo lo analizza in dettaglio.

Come regola generale, dovresti servire una versione lossy WebP o AVIF della tua immagine LCP (meglio ancora, usa questi formati per tutte le tue immagini, ma qui ci concentriamo sull'LCP). Con il supporto WebP intorno al 95% e il supporto AVIF al 92%, ha ancora senso servire immagini più vecchie come fallback. Per farlo basta usare il 'progressive enhancement' dove serviamo questi formati moderni solo ai browser che li supportano.

Velocità di decodifica vs. compromesso di compressione

Sebbene AVIF offra la migliore compressione (dimensione file più piccola), i suoi algoritmi complessi possono richiedere più potenza CPU per decodificare in un'immagine renderizzabile rispetto a WebP. Questa è un'operazione CPU-bound che avviene sui thread Rasterizer del browser e aumenta direttamente l'Element Render Delay. Un AVIF più piccolo potrebbe scaricarsi più velocemente, ma il suo tempo di decodifica più lungo potrebbe annullare quel beneficio, specialmente sui dispositivi mobili. Puoi diagnosticare questo nel pannello Performance di Chrome DevTools cercando task "Decode Image" di lunga durata associati al tuo elemento LCP. Se lo vedi, è un chiaro segnale che la velocità di decodifica è il tuo collo di bottiglia, non solo il tempo di download.

Approfondimento esperto: il caso di JPEG-XL Una guida veramente esperta deve affrontare JPEG XL. È un formato tecnicamente notevole, specialmente per la sua capacità di ricomprimere senza perdita i JPEG esistenti (un enorme vantaggio per i siti legacy) e il suo supporto per la decodifica progressiva, che AVIF non ha. Tuttavia, il suo svantaggio decisivo è la mancanza di ampio supporto nei browser dopo essere stato abbandonato da Chrome. Questo lo rende non ancora utilizzabile per l'uso web generale, ma lo posiziona come un formato da tenere d'occhio per il futuro.

Usare l'elemento <picture>: L'elemento <picture> permette ai browser di saltare i formati immagine non supportati, selezionando il primo che possono gestire. Ecco come fare:

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

Usare la content negotiation: La content negotiation permette al tuo server di servire formati immagine diversi in base al supporto del browser. I browser annunciano i formati supportati tramite l'header Accept. Ad esempio, in Chrome, l'header Accept per le immagini appare così:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Poi, lato server, leggi l'header accept e in base all'header servi il 'formato migliore' 

3. Usa immagini responsive

Quando si tratta di ottimizzare le immagini LCP, le dimensioni contano davvero. Una delle vittorie più facili è servire immagini con le dimensioni più piccole possibili che siano comunque belle sugli schermi dei tuoi utenti. Le immagini grandi non servono a nulla: sprecano banda & rallentano i tempi di caricamento, specialmente per gli utenti con connessioni più lente o dispositivi mobili.

Per assicurarti di non sprecare pixel, segui questi passaggi:

Immagini responsive:

Usa l'attributo srcset per servire diverse dimensioni di immagine in base al dispositivo dell'utente. In questo modo, i dispositivi più piccoli ottengono immagini più piccole, il che aiuta a velocizzare l'LCP.

Perché l'attributo `sizes` è fondamentale

Usare srcset con i descrittori w ma omettere l'attributo sizes è un errore comune e costoso. Senza l'attributo sizes, il browser è costretto ad assumere un valore predefinito di 100vw (100% della larghezza del viewport). Questo significa che su un grande schermo desktop, il browser scaricherà un'immagine enorme dalla tua lista srcset, anche se l'immagine viene visualizzata solo in una piccola colonna di 500px. Hai fornito gli ingredienti giusti (srcset) ma hai tralasciato la ricetta (sizes), portando a spreco di banda e un LCP più lento. L'attributo sizes fornisce il contesto di layout cruciale, indicando al browser quanto sarà effettivamente larga l'immagine ai diversi breakpoint del viewport, permettendogli di fare una scelta di download intelligente.

Capire i descrittori `w` vs. `x`

L'attributo srcset supporta due tipi di descrittori. Per il design responsive dove la dimensione di un'immagine cambia con il viewport, il descrittore w (width) è la scelta superiore e necessaria. Viene usato con l'attributo sizes per permettere al browser di scegliere l'immagine migliore in base alla sua dimensione renderizzata nel layout. Il più semplice descrittore x (device-pixel-ratio) considera solo la densità di pixel dello schermo, ignorando quanto sia grande l'immagine nel layout, rendendolo adatto solo per immagini a dimensione fissa come le icone.

<img 
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

Evita di servire immagini più grandi del necessario. Se l'elemento LCP è largo solo 600px nel viewport, assicurati che l'immagine non sia più grande di così. Credimi, lo vedo succedere ogni giorno! Per controllare basta fare questo: ispeziona l'immagine cliccando con il tasto destro sull'immagine e seleziona 'Ispeziona elemento'. Ora vedrai i dev-tools e l'html dell'immagine è evidenziato con uno sfondo blu. Ora puoi vedere la dimensione renderizzata dell'immagine (443 x 139px)  è molto più piccola della larghezza intrinseca dell'immagine  (1090x343px). È quasi 3 volte più grande e ridimensionare l'immagine avrebbe potuto risparmiare almeno il 50% della dimensione del file

5. Usa immagini LCP caricate in modo eager

Per ottenere le migliori prestazioni dal tuo LCP, dovresti caricare in modo eager l'elemento LCP visibile (e caricare in modo lazy le immagini che non sono immediatamente visibili).

Eager Loading: L'elemento LCP (solitamente contenuto above-the-fold) dovrebbe sempre essere caricato in modo eager. Questo assicura che appaia il più velocemente possibile, riducendo il tempo necessario per il rendering del tuo Largest Contentful Paint. Per impostazione predefinita, le immagini si caricano in modo eager a meno che non sia specificato diversamente, ma verifica che non hai impostato loading="lazy" sull'immagine LCP. Farlo può ritardare significativamente l'LCP e danneggiare il tuo punteggio Core Web Vitals. È importante capire che loading="eager" è il comportamento predefinito del browser, quindi omettere completamente l'attributo ha lo stesso effetto. L'azione critica è assicurarsi che loading="lazy" non sia presente.

Attenzione geek: le immagini lazy non vengono accodate dal preload scanner. Il preload scanner è uno scanner html secondario super veloce che accoda immediatamente le risorse importanti. Quando il preload scanner viene bypassato il browser dovrà attendere il completamento del motore di rendering prima di accodare le 'immagini visibili'. Affinché il browser valuti il loading="lazy" nativo, deve prima scaricare e analizzare tutto il CSS render-blocking per costruire il render tree. Solo dopo che il layout è stato calcolato il browser può determinare se l'immagine è nel viewport. Questo significa che l'intero CSS diventa una dipendenza bloccante per il download dell'immagine LCP, il che è un disastro prestazionale.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

Per le immagini che appaiono below the fold (quelle non visibili quando la pagina viene caricata per la prima volta), il lazy loading è la strada giusta. Ritardando il caricamento di queste immagini fino a quando l'utente scorre vicino ad esse, liberi banda per contenuti più importanti, come il tuo elemento LCP. In questo modo il lazy loading è un'arma a doppio taglio: se usato correttamente velocizzerà il tuo contenuto LCP, se usato in modo errato lo rallenterà!

<img src="non-visible-image.jpg" 
     alt="Secondary image" 
     
     width="800" height="400">

L'equilibrio? Carica in modo eager il contenuto critico (come la tua immagine LCP) e carica in modo lazy le risorse meno critiche e le immagini below the fold!

6. Fai il preload dell'immagine LCP

Fare il preload dell'immagine Largest Contentful Paint (LCP) è uno dei modi più semplici per velocizzare la sua comparsa sulla pagina. Dice al browser di dare priorità al caricamento di questa immagine, assicurando che sia pronta il prima possibile.

Perché fare il preload dell'immagine LCP?

Quando il browser carica una pagina, elabora HTML, fogli di stile e script in un certo ordine. A volte, l'immagine LCP è referenziata più in basso nella catena, il che significa che il browser la raggiunge più tardi di quanto dovrebbe. Fare il preload dell'immagine LCP permette al browser di sapere in anticipo che questa immagine è critica e dovrebbe essere caricata immediatamente, riducendo il ritardo nel rendering dell'elemento più grande.

Come fare il preload dell'immagine LCP

Usando il tag <link rel="preload">, puoi assicurarti che il browser inizi a scaricare l'immagine LCP il prima possibile nel processo di caricamento.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

Questo assicura che l'immagine LCP sia nella coda del browser dall'inizio, evitando l'attesa che spesso si verifica se l'immagine è nascosta nel CSS o negli script.

<!-- Nel <head> -->
<link rel="preload" as="image" 
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- Nel <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

Ricorda: Fai il preload solo dell'immagine LCP, poiché fare il preload di troppe risorse può sovraccaricare il browser e danneggiare le prestazioni. Concentrati su ciò che conta di più per i tuoi Core Web Vitals.

7. Rimuovi le animazioni fade-in dall'immagine LCP

Le animazioni fade-in possono essere visivamente attraenti, ma quando si tratta del tuo Largest Contentful Paint, sono un collo di bottiglia nascosto. Se l'elemento LCP (spesso un'immagine) usa un effetto fade-in, il browser non conterà l'LCP fino al termine dell'animazione. Questo ritarda la tempistica dell'LCP e può danneggiare significativamente le tue metriche di prestazione.

La tempistica LCP avviene dopo la fine dell'animazione: Il browser considera l'LCP completo solo quando l'elemento è completamente visibile. Se hai un'animazione fade-in, il timer continua a girare fino a quando l'immagine o il contenuto non è completamente apparso, il che può facilmente aggiungere secondi extra al tuo punteggio LCP.

Mantienilo semplice: Per assicurarti che l'elemento LCP appaia il più velocemente possibile, evita di usare effetti fade-in. Lascia che l'immagine si carichi e si visualizzi immediatamente, senza alcuna transizione o animazione.

Eliminando i fade-in dall'immagine LCP, previeni ritardi inutili e migliori i tuoi Core Web Vitals, garantendo un'esperienza più veloce e fluida per gli utenti.

8. Self-hosting dell'elemento LCP

Per ottenere le migliori prestazioni dal tuo Largest Contentful Paint, dovresti sempre considerare il self-hosting dell'elemento LCP, specialmente se è un'immagine o un'altra risorsa critica. Affidarsi a server di terze parti può introdurre ritardi che sono completamente fuori dal tuo controllo, il che può danneggiare il tuo LCP e le prestazioni complessive della pagina.

Pensala così: Non fare il self-hosting del tuo elemento LCP è come prendere sempre in prestito lo zucchero dal tuo vicino. Ogni volta, devi andare là, aspettare alla porta, e sperare che siano a casa. Affidarsi a un server di terze parti per il tuo LCP fa aspettare il tuo sito web per quella risorsa esterna, rallentando i tempi di caricamento. Il self-hosting è come tenere lo zucchero nella tua cucina: "veloce, diretto e affidabile".

Riduci le dipendenze esterne: Quando il tuo elemento LCP (come un'immagine) è ospitato su un server di terze parti, sei alla mercé della velocità di quel server, della disponibilità e di qualsiasi round-trip time (RTT) aggiuntivo. Il self-hosting elimina questa incertezza, permettendoti di servire l'immagine direttamente dal tuo server, garantendo una consegna più veloce e affidabile.

Sfrutta il caching e le ottimizzazioni: Con il self-hosting, puoi sfruttare appieno le strategie di caching e servire l'immagine dal server più vicino all'utente, specialmente se stai usando un CDN. Questo riduce il tempo necessario per caricare l'elemento LCP, risultando in un rendering più veloce.

Controllo sull'ottimizzazione delle immagini: Il self-hosting ti dà il controllo su come l'immagine è ottimizzata, che si tratti di compressione, ridimensionamento o selezione del formato—senza affidarsi alla gestione di terze parti. In questo modo, puoi assicurarti che l'immagine sia perfettamente ottimizzata per un caricamento veloce.

9. Evita il Client-Side Rendering per l'elemento LCP

Il Client-Side Rendering (CSR) può essere un ostacolo importante quando si tratta di ottimizzare il tuo Largest Contentful Paint. Se il tuo elemento LCP (di solito una grande immagine, blocco di testo o video) è renderizzato lato client tramite JavaScript, spesso porta a tempi LCP più lenti poiché il browser deve attendere che gli script vengano scaricati, analizzati ed eseguiti prima di visualizzare il contenuto critico.

Ritardi nel rendering: Con il CSR, l'elemento LCP viene visualizzato solo dopo che il browser ha elaborato JavaScript, il che può ritardare significativamente la sua comparsa. Più tempo ci vuole, peggiore diventa il tuo punteggio LCP. Ogni secondo extra speso nell'elaborazione degli script si traduce in un'attesa più lunga per i tuoi utenti per vedere il contenuto più importante.

Passa al Server-Side Rendering (SSR) o al rendering statico: Renderizzando l'elemento LCP lato server o come parte di una risposta HTML statica, permetti al browser di caricarlo e visualizzarlo immediatamente, senza attendere che JavaScript entri in azione. Questo migliora drasticamente la tempistica dell'LCP, poiché il browser può renderizzare l'elemento LCP subito quando inizia a caricare l'HTML.

Minimizza JavaScript nel percorso critico: Se non puoi evitare alcuni script lato client, assicurati che non blocchino il rendering dell'elemento LCP. Differisci o rendi asincroni gli script non critici per impedire che ritardino la comparsa del tuo LCP.

10. Riserva spazio per prevenire i Layout Shift

Includi sempre attributi espliciti width e height sui tuoi tag <img> . Questa è un'istruzione critica per il browser, che gli permette di calcolare l'aspect ratio dell'immagine e riservare la quantità corretta di spazio nel layout *prima* che l'immagine sia stata scaricata.

Approfondimento esperto: comportamento moderno di width e height

Un malinteso comune è che questi attributi rendano un'immagine non responsive. Questo non è più vero nei browser moderni. Il browser usa questi attributi HTML per calcolare un aspect ratio e mantenere lo spazio, ma l'immagine sarà comunque perfettamente responsive se il suo CSS è impostato su width: 100%; height: auto;. Fornire questi attributi è superiore all'uso della sola proprietà CSS aspect-ratio, poiché il browser può riservare lo spazio *prima* che qualsiasi CSS render-blocking sia stato scaricato e analizzato, dandogli un vantaggio critico.

Gestione delle immagini di sfondo CSS

Questo principio si applica anche agli elementi che fungono da contenitori per un background-image CSS. Una fonte comune di layout shift è un <div> che collassa a zero altezza inizialmente e poi si espande quando l'immagine di sfondo viene applicata. Per prevenire questo, usa la proprietà CSS aspect-ratio direttamente sull'elemento contenitore per riservare lo spazio necessario dall'inizio.

11. Verifica il blocco del Main Thread

Anche se la tua immagine LCP è perfettamente ottimizzata e prioritizzata, il suo rendering finale può essere ritardato se il main thread del browser è occupato nell'esecuzione di JavaScript pesante. Spesso, la fonte di questo blocco sono script di terze parti per analytics, pubblicità o widget di assistenza clienti. Questi script possono monopolizzare la CPU, aumentando l'Element Render Delay. Usa il pannello Performance in Chrome DevTools per identificare task di lunga durata durante il caricamento iniziale, attribuirli alla loro fonte, e differire o rimuovere quelli che non sono critici per il rendering iniziale.