Ottimizza l'immagine del Largest Contentful Paint

Ottimizza l'immagine del Largest Contentful Paint

Questa guida fa parte dell'hub sul Largest Contentful Paint (LCP). Sulla maggior parte dei siti web, l'elemento LCP è un'immagine. Sbaglia l'immagine e il tuo punteggio LCP ne risente. Questo articolo analizza ogni tecnica per renderla veloce.

Secondo Google solo il 65% di tutte le visualizzazioni di pagina su internet (inclusi desktop e mobile) ha un punteggio 'buono' del Largest Contentful Paint. Significa che il 35% delle visualizzazioni fallisce e questo è in parte dovuto agli errori commessi con le immagini. Questo articolo analizza i pattern di buone pratiche e gli errori comuni quando le immagini diventano l'elemento LCP (Largest Contentful Paint).

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

Esperimenti con il Largest Contentful Paint

Dico sempre: ascolta e impara, ma non prendere per oro colato quello che ti dicono. Ci sono troppi 'guru' in giro che predicano informazioni sbagliate. Per questo ho creato un esperimento LCP completamente automatico in cui puoi verificare di persona cosa succede quando l'elemento LCP non è caricato in modo ottimale. Guarda il mio test LCP su github o prova la demo live!

Testerà automaticamente diversi scenari LCP per te e ne mostrerà i risultati. Analizzerò quegli scenari qui sotto e spiegherò come e perché accelerano o rallentano l'elemento immagine del LCP.

1. Controlla il candidato LCP: la strategia text-first

Il modo più rapido per migliorare il tuo Largest Contentful Paint basato su un'immagine? Non usare un'immagine! Aspetta, cosa? Sì, hai sentito bene. Lasciami spiegare.

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

Quindi perché scegliere le immagini invece del testo? Le immagini sono importanti; rendono il tuo sito visivamente accattivante. Ai Core Web Vitals, però, non importa quale elemento diventi il LCP. Quando l'elemento LCP è testuale, in genere si verifica contemporaneamente al First Contentful Paint.

Quindi dovresti passare a un elemento Largest Contentful Paint testuale? Dipende! Le immagini contano e rendono il tuo sito visivamente accattivante. Questo significa che non mi sentirai mai consigliare di passare a vecchi e noiosi elementi di testo. Ma capitano anche degli errori! Vorrei un dollaro per ogni pagina di categoria vittima dell'anti-pattern "LCP accidentale". Questo accade quando una pagina "dimentica" di aggiungere un testo descrittivo per la categoria above the fold, facendo sì che un'immagine del prodotto in lazy loading diventi il LCP e ritardando i tempi di caricamento di svariati secondi. Spesso succede quando i designer posizionano un grande banner hero in cima al DOM, prima di qualsiasi titolo significativo, non lasciando al browser altra scelta se non quella di selezionare un candidato LCP più lento.

2. Usa il formato immagine più veloce disponibile

Senza entrare in dibattiti accesi su come spremere l'ultimo byte o sulle impostazioni perfette per WebP contro AVIF, concordiamo su una cosa: i formati vecchi come JPEG e PNG sono più pesanti e lenti rispetto ai formati moderni come WebP o AVIF. Per una panoramica completa sulle tecniche di ottimizzazione delle immagini, vedi la nostra guida sull'ottimizzazione delle immagini.

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 sul LCP). Con il supporto WebP a circa il 95% e il supporto AVIF al 92%, ha ancora senso servire anche le vecchie immagini di fallback. Per farlo, usa il 'progressive enhancement' dove serviamo questi formati moderni solo ai browser che li supportano.

Velocità di decodifica vs Compressione

Sebbene AVIF offra la migliore compressione (dimensioni del file più piccole), i suoi algoritmi complessi possono richiedere maggiore potenza della CPU per la decodifica in un'immagine renderizzabile rispetto al WebP. Questo è un task limitato dalla CPU 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 questo vantaggio, specialmente sui dispositivi mobili. Puoi diagnosticare il problema nel pannello Performance di Chrome DevTools cercando i task "Decode Image" lunghi associati al tuo elemento LCP. Se li vedi, è un chiaro segnale che la velocità di decodifica è il tuo collo di bottiglia, e non solo il tempo di download.

Approfondimento: il caso JPEG-XL. Una vera guida per esperti deve affrontare il JPEG XL. È un formato tecnicamente notevole, specialmente per la sua capacità di ricomprimere in modo lossless i JPEG esistenti (un enorme vantaggio per i siti legacy) e per il suo supporto alla decodifica progressiva, che manca all'AVIF. Tuttavia, il suo svantaggio decisivo è la mancanza di un ampio supporto tra i browser dopo essere stato abbandonato da Chrome. Questo lo rende non ancora praticabile per l'uso generale sul web, ma lo posiziona come formato da tenere d'occhio per il futuro.

Uso dell'elemento <picture>: L'elemento <picture> permette ai browser di saltare i formati immagine non supportati, selezionando il primo che riescono a 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>

Combinare la negoziazione del formato con le dimensioni responsive

Per le massime prestazioni, dovresti combinare la selezione del formato con le dimensioni responsive dell'immagine in un singolo elemento <picture>. Questo assicura che ogni utente riceva il formato ottimale e la dimensione ottimale per il proprio dispositivo. Il browser valuta gli elementi <source> dall'alto verso il basso e seleziona il primo formato che supporta, poi usa gli attributi srcset e sizes per scegliere la risoluzione corretta.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Questo pattern offre al browser la totale libertà di scegliere la migliore combinazione di formato e risoluzione. Un utente mobile su un browser supportato riceverà un piccolo file AVIF, mentre un vecchio browser desktop userà un JPEG di dimensioni corrette come fallback.

Uso della content negotiation

La content negotiation permette al tuo server di fornire diversi formati immagine in base al supporto del browser. I browser annunciano i formati supportati tramite l'header Accept. Ad esempio, su Chrome, l'header Accept per le immagini è simile a questo:

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

Poi, lato server, leggi l'header Accept e in base ad esso 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 le immagini con le dimensioni più piccole possibili, a patto che abbiano ancora un bell'aspetto sugli schermi dei tuoi utenti. Le immagini enormi non servono a nulla: sprecano solo larghezza di banda e rallentano i tempi di caricamento, specialmente per gli utenti con connessioni lente o dispositivi mobili.

Per assicurarti di non sprecare pixel, segui questi passaggi:

Immagini responsive:

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

Perché l'attributo sizes è critico

Usare srcset con i descrittori w omettendo 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 della viewport). Significa che su un grande schermo desktop, il browser scaricherà un'immagine enorme dalla tua lista srcset, anche se l'immagine viene mostrata solo in una piccola colonna da 500px. Hai fornito gli ingredienti giusti (srcset) ma hai tralasciato la ricetta (sizes), portando a uno spreco di larghezza di banda e a un LCP più lento. L'attributo sizes fornisce il contesto di layout necessario: dice al browser quanto sarà larga l'immagine ai diversi breakpoint della viewport, permettendogli di compiere una scelta di download intelligente.

Capire i descrittori w e x

L'attributo srcset supporta due tipi di descrittori. Nel responsive design in cui le dimensioni dell'immagine cambiano con la viewport, il descrittore w (width) è la scelta superiore e necessaria. Si usa con l'attributo sizes per consentire al browser di scegliere l'immagine migliore in base alla sua dimensione renderizzata nel layout. Il descrittore più semplice x (device-pixel-ratio) considera solo la densità dei pixel dello schermo e ignora l'effettiva grandezza dell'immagine nel layout; per questo è 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">

4. Scala le tue immagini alla dimensione dello schermo!

Evita di servire immagini più grandi del necessario. Se l'elemento LCP è largo solo 600px nella viewport, assicurati che l'immagine non sia più grande di così. Fidati, lo vedo succedere ogni giorno! Per controllare, fai così: ispeziona l'immagine facendo clic con il tasto destro su di essa e seleziona 'Ispeziona elemento'. Ora vedrai i DevTools e l'HTML dell'immagine evidenziato con uno sfondo blu. Puoi notare che 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 fatto risparmiare almeno il 50% delle dimensioni del file.

5. Usa immagini LCP con eager loading

Per ottenere le migliori prestazioni dal tuo LCP, dovresti caricare in eager l'elemento LCP visibile (e usare il lazy loading per le immagini non immediatamente visibili). Questo è uno degli errori più comuni nell'ottimizzazione del LCP; ne parliamo nel dettaglio nel nostro articolo su come correggere le immagini LCP in lazy loading.

Eager Loading: L'elemento LCP (solitamente il contenuto above the fold) dovrebbe sempre essere caricato in eager. Questo garantisce che appaia il più rapidamente possibile, riducendo il tempo necessario al rendering del tuo Largest Contentful Paint. Di default, le immagini si caricano in eager se non diversamente specificato, ma verifica di non aver impostato loading="lazy" sull'immagine LCP. Farlo può ritardare significativamente il LCP e danneggiare il tuo punteggio Core Web Vitals. È importante capire che loading="eager" è il comportamento predefinito del browser, quindi omettere del tutto l'attributo ha lo stesso effetto. L'azione fondamentale è assicurarsi che loading="lazy" non sia presente.

Geek alert: Le immagini lazy non vengono accodate dal preload scanner. Il preload scanner è un secondo scanner HTML super veloce che mette subito in coda le risorse importanti. Quando il preload scanner viene saltato, il browser deve aspettare che il motore di rendering completi il suo lavoro prima di accodare le 'immagini visibili'. Affinché il browser possa valutare il loading="lazy" nativo, deve prima scaricare e analizzare tutto il CSS render blocking per costruire il render tree. Solo dopo il calcolo del layout il browser può determinare se l'immagine è nella viewport. Questo significa che l'intero CSS diventa una dipendenza bloccante per il download dell'immagine LCP: un disastro in termini di prestazioni.

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

Per le immagini che appaiono below the fold (quelle non visibili al primo caricamento della pagina), il lazy loading è la strada giusta. Ritardando il caricamento di queste immagini finché l'utente non vi scorre vicino, liberi larghezza di banda per contenuti più importanti, come il tuo elemento LCP. Il lazy loading è un'arma a doppio taglio: se usato correttamente accelera i tuoi contenuti LCP; se usato male li rallenta!

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

L'equilibrio? Carica in eager i contenuti critici (come l'immagine LCP) e usa il lazy loading per le risorse meno critiche e le immagini below the fold.

6. Precarica l'immagine LCP

Precaricare l'immagine LCP dice al browser di scaricarla immediatamente, prima ancora di scoprirla naturalmente nell'HTML. Per una guida completa al preload, vedi il nostro articolo dedicato sul preload dell'immagine LCP.

Perché precaricare l'immagine LCP?

Quando il browser carica una pagina, elabora l'HTML, i CSS e gli script in un certo ordine. A volte l'immagine LCP si trova più in basso nella catena, quindi il browser la incontra più tardi del dovuto. Precaricare l'immagine LCP comunica in anticipo al browser che è una risorsa critica e deve essere caricata subito, riducendo il ritardo nel rendering del tuo elemento più grande.

Come precaricare l'immagine LCP

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

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

Così l'immagine LCP entra nella coda del browser fin dall'inizio, evitando l'attesa tipica di quando l'immagine è sepolta tra CSS e script.

<!-- In the <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">

<!-- In the <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: Precarica solo l'immagine LCP, perché precaricare 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 in dissolvenza dall'immagine LCP

Le animazioni in dissolvenza possono essere visivamente accattivanti, ma sono un collo di bottiglia nascosto per il LCP. Se l'elemento LCP (spesso un'immagine) usa un effetto in dissolvenza, il browser non registrerà il LCP finché l'animazione non sarà finita. Questo ritarda le tempistiche del LCP e può danneggiare gravemente le tue metriche di prestazione.

Il conteggio del LCP avviene dopo la fine dell'animazione: Il browser considera il LCP completo solo quando l'elemento è interamente visibile. Se hai un'animazione in dissolvenza, il cronometro continua a scorrere finché l'immagine o il contenuto non sono completamente apparsi, il che può facilmente aggiungere secondi extra al tuo punteggio LCP.

Mantieni le cose semplici: Per assicurarti che l'elemento LCP appaia il più rapidamente possibile, evita di usare effetti in dissolvenza. Lascia che l'immagine si carichi e venga mostrata immediatamente, senza alcuna transizione o animazione.

Evita le dissolvenze sull'immagine LCP. L'effetto visivo non vale il costo in termini di prestazioni.

8. Esegui il self-hosting dell'elemento LCP

Ospita l'immagine LCP sul tuo server. Affidarsi a server di terze parti introduce ritardi che sono completamente fuori dal tuo controllo e possono danneggiare il tuo LCP e le prestazioni generali della pagina.

Pensala così: Non fare il self-hosting del tuo elemento LCP è come chiedere in continuazione lo zucchero in prestito al vicino. Ogni volta devi uscire, aspettare alla porta e sperare che sia in casa. Affidarsi a un server di terze parti per il LCP costringe il tuo sito ad aspettare 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 in balia della velocità e della disponibilità di quel server, oltre a subire tempi di round-trip (RTT) aggiuntivi. Il self-hosting elimina questa incertezza, permettendoti di servire l'immagine direttamente dal tuo server per assicurare una consegna più rapida e affidabile.

Usa caching e ottimizzazioni: Con il self-hosting, puoi sfruttare appieno le strategie di caching e servire l'immagine dal server più vicino all'utente, specialmente se usi un CDN. Questo riduce il tempo di caricamento dell'elemento LCP, garantendo un rendering più veloce.

Controllo sull'ottimizzazione dell'immagine: Il self-hosting ti dà il controllo su come l'immagine viene ottimizzata (compressione, ridimensionamento o selezione del formato) senza dipendere dalla gestione di terze parti. Così, puoi assicurarti che l'immagine sia perfetta per un caricamento veloce.

9. Evita il client-side rendering per l'elemento LCP

Il client-side rendering (CSR) è una delle cose peggiori che puoi fare al tuo LCP. Se il tuo elemento LCP (solitamente una grande immagine, un blocco di testo o un video) viene renderizzato lato client tramite JavaScript, spesso comporta tempi di LCP più lenti, poiché il browser deve aspettare di scaricare, analizzare ed eseguire gli script prima di mostrare il contenuto critico.

Ritardi nel rendering: Con il CSR, l'elemento LCP appare solo dopo che il browser ha elaborato il JavaScript, il che può ritardarne notevolmente la comparsa. Più lungo è questo processo, peggiore diventa il tuo punteggio LCP. Ogni secondo in più impiegato nell'elaborazione degli script si traduce in un'attesa maggiore prima che gli utenti vedano i contenuti più importanti.

Passa al Server-Side Rendering (SSR) o al rendering statico: Renderizzando l'elemento LCP lato server o all'interno di una risposta HTML statica, consenti al browser di caricarlo e mostrarlo immediatamente, senza aspettare l'intervento del JavaScript. Questo migliora drasticamente le tempistiche del LCP, poiché il browser può renderizzare l'elemento LCP non appena inizia a caricare l'HTML.

Minimizza il JavaScript sul percorso critico: Se non puoi evitare alcuni script lato client, assicurati che non blocchino il rendering dell'elemento LCP. Usa defer o async sugli script non critici per evitare 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>. È un'istruzione fondamentale per il browser, che gli permette di calcolare l'aspect ratio dell'immagine e riservare la giusta quantità di spazio nel layout prima che l'immagine venga scaricata.

Approfondimento: Comportamento moderno di width e height

Un'idea sbagliata comune è che questi attributi rendano un'immagine non responsive. Nei browser moderni non è più così. 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'usare solo la proprietà CSS aspect-ratio, poiché il browser può riservare lo spazio prima che qualsiasi CSS render blocking venga scaricato e parsato, ottenendo un vantaggio fondamentale.

Gestione delle immagini di background CSS

Questo principio vale anche per gli elementi usati come contenitori per una background-image CSS. Una causa comune di layout shift è un <div> che all'inizio collassa a un'altezza pari a zero per poi saltare alle dimensioni reali all'applicazione dell'immagine di sfondo. Per evitarlo, usa la proprietà CSS aspect-ratio direttamente sull'elemento contenitore per riservare lo spazio necessario fin dal principio.

11. Controlla i blocchi sul main thread

Anche se l'immagine LCP è perfettamente ottimizzata e con priorità, il suo rendering finale può subire ritardi se il main thread del browser è impegnato ad eseguire JavaScript pesante. Spesso, l'origine di questo blocco sono script di terze parti per gli analytics, la pubblicità o i widget di assistenza clienti. Questi script possono monopolizzare la CPU, aumentando l'Element Render Delay. Usa il pannello Performance in Chrome DevTools per identificare i long task durante il caricamento iniziale, attribuiscili alla loro fonte, e usa defer o rimuovi quelli non critici per il render iniziale. Per approfondire l'argomento, leggi la nostra guida su Element Render Delay.

Guida passo passo: Diagnosticare il LCP con il pannello Performance di Chrome DevTools mostra come registrare una traccia con throttling e individuare questi long task nella traccia Main.

Guide correlate all'ottimizzazione LCP

L'ottimizzazione delle immagini è solo un pezzo del puzzle. Ogni fase del LCP ha la sua guida:

• Risolvi e identifica i problemi del LCP: La metodologia diagnostica completa per trovare e risolvere i problemi del LCP usando field data e strumenti di laboratorio.
• Resource Load Delay: Assicurati che il browser scopra la tua risorsa LCP il prima possibile con preload, fetchpriority e una struttura HTML ottimale.
• Resource Load Duration: Riduci il tempo di download tramite compressione, configurazione del CDN e ottimizzazione di rete.
• Element Render Delay: Libera il main thread per consentire al browser di renderizzare l'elemento LCP subito dopo il download.