Ottimizza l'immagine del Largest Contentful Paint

Una guida passo-passo all'ottimizzazione dell'immagine LCP

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-07-10

Ottimizza l'immagine del Largest Contentful Paint

Questa guida fa parte dell'hub del Largest Contentful Paint (LCP). Nella maggior parte dei siti web, l'elemento LCP è un'immagine. Se sbagli l'immagine, il tuo punteggio LCP ne risente. Questo articolo copre ogni tecnica per renderla veloce.

Secondo Google, solo il 65% di tutte le visualizzazioni di pagina su internet (inclusi sia desktop che mobile) ha un punteggio di Largest Contentful Paint "buono". Ciò significa che il 35% delle visualizzazioni di pagina fallisce, in parte a causa di errori commessi con le immagini. Questo articolo analizza i pattern di buona pratica più comuni e gli errori commessi quando le immagini diventano l'elemento Largest Contentful Paint.

Suggerimento LCP: Se vuoi davvero padroneggiare tutte le sfumature del Largest Contentful Paint e non solo l'ottimizzazione dell'immagine, dai un'occhiata alla mia sezione dedicata al Largest Contentful Paint. Analizza come ottimizzare i quattro componenti chiave:

  1. Time to First Byte: Il tempo che il browser deve attendere per l'HTML. Di solito consiste principalmente nell'attesa del server, ma include anche reindirizzamenti, tempi di connessione, crittografia e altro.
  2. Load Delay: Il divario tra il momento in cui l'elemento LCP avrebbe potuto iniziare a caricarsi e quando lo fa effettivamente. Leggi la guida completa su Resource Load Delay.
  3. Resource Load Time: Il tempo impiegato dalla risorsa LCP per caricarsi. L'ottimizzazione della compressione e della minimizzazione può velocizzare questa fase. Leggi la guida completa su Resource Load Duration.
  4. Render Delay: Anche con risorse ottimizzate, il browser potrebbe essere impegnato in altre attività (di solito il download di fogli di stile o l'elaborazione pesante di JavaScript), ritardando il rendering dell'LCP. Leggi la guida completa su Element Render Delay.

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

Esperimenti con il Largest Contentful Paint

Lo dico sempre: ascolta e impara, ma non fidarti della parola di nessuno. Ci sono troppi "guru" in giro che diffondono informazioni errate. Per questo ho creato un esperimento LCP completamente automatico in cui puoi verificare di persona cosa succede quando l'elemento LCP non viene caricato in modo ottimale. Prova il mio LCP Test su GitHub o prova la demo live!

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

lcp image test results fast to slow

1. Controlla il candidato LCP: la strategia "Prima il testo"

La via più rapida per migliorare un Largest Contentful Paint basato su immagini? Non usare un'immagine! Come, scusa? Sì, hai capito bene. Lascia che ti spieghi.

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

lcp element distribution codeash 2024

Quindi, qual è la scelta migliore tra immagini e testo? Le immagini sono importanti; rendono il tuo sito visivamente accattivante. But Core Web Vitals non si curano di quale elemento diventi l'LCP. Quando l'elemento LCP è basato sul testo, di solito si verifica in contemporanea con il First Contentful Paint.

Dovresti quindi passare a un elemento Largest Contentful Paint basato su testo? Dipende! Le immagini contano e rendono il tuo sito visivamente accattivante. Non mi sentirai quindi promuovere il passaggio a vecchi e noiosi elementi di testo. Ma gli errori capitano! Vorrei ricevere un dollaro per ogni pagina di categoria vittima dell'anti-pattern "LCP Accidentale". Questo accade quando una pagina "dimentica" di aggiungere un testo descrittivo della categoria above the fold, facendo sì che un'immagine prodotto caricata tramite lazy loading diventi l'LCP e ritardi i tempi di caricamento di secondi. Succede spesso 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 d'immagine più veloce disponibile

Senza entrare in un acceso dibattito su come spremere l'ultimo byte o sulle impostazioni perfette per WebP contro 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. Per una panoramica completa delle tecniche di ottimizzazione delle immagini, consulta la nostra guida sull'ottimizzazione delle immagini.

cat webp jpg avif compare size

Come regola generale, dovresti servire una versione lossy WebP o AVIF della tua immagine LCP (ancora meglio se usi questi formati per tutte le immagini, ma qui ci concentriamo sull'LCP). Con il supporto WebP a circa il 95% e il supporto AVIF al 92%, ha ancora senso servire anche immagini di fallback più vecchie. Per farlo, usa il "progressive enhancement" servendo questi formati moderni solo ai browser che li supportano.

Compromesso tra velocità di decodifica e compressione

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

Parere dell'esperto: il caso di JPEG-XL. Una vera guida esperta deve affrontare il tema di JPEG XL. È un formato tecnicamente notevole, in particolare per la sua capacità di ricomprimere senza perdite (lossless) i JPEG esistenti (un enorme vantaggio per i siti legacy) e per il suo supporto alla decodifica progressiva, di cui AVIF è privo. Tuttavia, il suo svantaggio decisivo è la mancanza di un ampio supporto da parte dei browser dopo essere stato rimosso da Chrome. Questo lo rende non ancora praticabile per l'uso web generale, mas lo posiziona come un formato da tenere d'occhio per il futuro.

Uso dell'elemento <picture>: l'elemento <picture> consente ai browser di saltare i formati di immagine non supportati, selezionando il primo che sono in grado di 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 ottenere il massimo delle 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 supportato, quindi utilizza 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 lascia al browser la piena libertà di scegliere la migliore combinazione di formato e risoluzione. Un utente mobile con un browser supportato otterrà un piccolo file AVIF, mentre un browser desktop più vecchio utilizzerà come fallback un JPEG della dimensione corretta.

Uso della content negotiation

La content negotiation consente al tuo server di fornire diversi formati di immagine in base al supporto del browser. I browser comunicano i formati supportati tramite l'header Accept. Ad esempio, in Chrome, l'header Accept per le immagini si presenta così:

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

Quindi, lato server, leggi l'header Accept e in base ad esso fornisci il formato migliore.

3. Usa immagini responsive

Quando si tratta di ottimizzare le immagini LCP, la dimensione conta davvero. Uno dei modi più semplici per ottenere risultati è servire immagini con le dimensioni minime possibili che appaiano comunque bene sugli schermi degli utenti. Le immagini grandi non hanno alcuna utilità: sprecano larghezza di banda e rallentano i tempi di caricamento, specialmente per gli utenti con connessioni lente o su 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 riceveranno immagini più piccole, il che contribuisce 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 a ipotizzare un valore predefinito di 100vw (il 100% della larghezza del viewport). Ciò significa che su uno schermo desktop grande, il browser scaricherà un'immagine enorme dall'elenco srcset, anche se l'immagine è visualizzata solo in una piccola colonna da 500px. Hai fornito gli ingredienti giusti (srcset) ma hai tralasciato la ricetta (sizes), con il risultato di sprecare larghezza di banda e rallentare l'LCP. L'attributo sizes fornisce il contesto di layout necessario, indicando al browser quanto sarà effettivamente larga l'immagine ai diversi breakpoint del viewport, consentendogli di effettuare una scelta di download intelligente.

Comprendere i descrittori w contro x

L'attributo srcset supporta due tipi di descrittori. Per il design responsive, in cui la dimensione di un'immagine cambia con il viewport, il descrittore w (larghezza) è la scelta migliore e necessaria. Si usa insieme all'attributo sizes per consentire al browser di scegliere l'immagine migliore in base alla sua dimensione renderizzata nel layout. Il descrittore x (device-pixel-ratio), più semplice, tiene conto solo della 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">

4. Ridimensiona le immagini in base allo schermo!

Evita di servire immagini più grandi del necessario. Se l'elemento LCP è largo solo 600px nel viewport, assicurati che l'immagine non superi quella dimensione. Credimi, lo vedo accadere ogni giorno! Per verificare, fai così: ispeziona l'immagine facendo clic con il tasto destro e selezionando "Ispeziona" (o "Ispeziona elemento"). Si apriranno i dev-tools e l'HTML dell'immagine verrà evidenziato con uno sfondo blu. Ora puoi vedere che la dimensione renderizzata dell'immagine (443 x 139px) è molto più piccola della larghezza intrinseca dell'immagine (1090x343px). È quasi tre volte più grande; ridimensionare l'immagine avrebbe fatto risparmiare almeno il 50% del peso del file.

view image intrinsic size in devtools

5. Carica le immagini LCP in modalità Eager

Per ottenere le migliori prestazioni dal tuo LCP, dovresti caricare l'elemento LCP visibile in modalità eager (e applicare il lazy loading alle immagini non immediatamente visibili). Questo è uno degli errori più comuni nell'ottimizzazione dell'LCP, che approfondiamo nel nostro articolo su come risolvere le immagini LCP caricate in modalità lazy.

Caricamento Eager (Eager Loading): l'elemento LCP (di solito contenuto above the fold) deve essere sempre caricato in modalità eager. Questo assicura che appaia il più rapidamente possibile, riducendo il tempo necessario per il rendering del tuo Largest Contentful Paint. Di default, las immagini vengono caricate in modalità eager a meno che non sia specificato diversamente, ma verifica attentamente di non aver impostato loading="lazy" sull'immagine LCP. Farlo può ritardare notevolmente l'LCP e peggiorare il tuo punteggio Core Web Vitals. È importante capire che loading="eager" rappresenta il comportamento predefinito del browser, quindi omettere del tutto l'attributo produce lo stesso effetto. L'azione fondamentale è assicurarsi che loading="lazy" non sia presente.

Allerta geek: le immagini lazy non vengono messe in coda dal preload scanner. Il preload scanner è uno scanner HTML secondario e velocissimo che mette in coda immediatamente le risorse importanti. Quando il preload scanner viene bypassato, il browser deve attendere il completamento del motore di rendering prima di mettere in coda le "immagini visibili". Affinché il browser valuti l'attributo nativo loading="lazy", deve prima scaricare e analizzare tutti i CSS render blocking per costruire il render tree. Solo dopo il calcolo del layout il browser può determinare se l'immagine si trova nel viewport. Ciò significa che l'intero CSS diventa una dipendenza bloccante per il download dell'immagine LCP, il che rappresenta un disastro per le 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 da seguire. Ritardando il caricamento di queste immagini finché l'utente non vi si avvicina scorrendo, si libera larghezza di banda per i contenuti più importanti, come l'elemento LCP. In questo modo il lazy loading è un'arma a doppio taglio: se usato correttamente velocizzerà i tuoi contenuti LCP; se usato in modo errato li rallenterà!

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

Il bilanciamento? Carica in modalità eager il contenuto critico (come la tua immagine LCP) e applica il lazy loading alle risorse meno critiche e alle immagini below the fold!

6. Esegui il preload dell'immagine LCP

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

Perché eseguire il preload dell'immagine LCP?

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

Come eseguire il preload dell'immagine LCP

Utilizzando 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 garantisce che l'immagine LCP sia nella coda del browser fin dall'inizio, evitando l'attesa che spesso si verifica se l'immagine è sepolta nei CSS o negli script.

Parere dell'esperto: preload responsivi e fetchpriority

Un semplice preload non è sufficiente per le immagini responsive. Per evitare doppi download che compromettono le prestazioni, devi utilizzare gli attributi imagesrcset e imagesizes sul link di preload stesso per rispecchiare la logica del tuo tag <img>. Questa è l'implementazione di livello esperto che distingue i siti con le migliori prestazioni dal resto.

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

Includere fetchpriority="high" sul tag <img> fornisce un fallback, assicurando che l'immagine sia comunque prioritizzata se il preload non è supportato. È un approccio prudente ("cintura e bretelle"): il preload avvia il download in anticipo e fetchpriority si assicura che vinca la gara della larghezza di banda.

Ricorda: esegui il preload solo per l'immagine LCP, in quanto 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 gradevoli dal punto di vista visivo, ma rappresentano un collo di bottiglia nascosto per l'LCP. Se l'elemento LCP (spesso un'immagine) utilizza un effetto fade-in, il browser non registrerà l'LCP finché l'animazione non sarà terminata. Questo ritarda la tempistica dell'LCP e può danneggiare in modo significativo le tue metriche di performance.

Parere dell'esperto: il meccanismo del ritardo dell'animazione

Questo problema non è limitato solo ai fade-in. Si applica a qualsiasi animazione che transiti un elemento da uno stato inizialmente invisibile o fuori dallo schermo, come i slide-in (ad esempio, a partire da transform: translateX(-100%)) o gli effetti di zoom (ad esempio, a partire da transform: scale(0.5)). La logica dell'LCP è progettata per misurare quando l'elemento più grande è visivamente stabile e completo. Un elemento che si sta ancora animando non è considerato stabile. Questo aumenta direttamente l'Element Render Delay, una delle sottofasi dell'LCP, poiché il browser ha già scaricato l'immagine ma viene artificialmente trattenuto dall'eseguire il paint del frame finale finché l'animazione non si conclude.

lcp timing fade in

Il timing dell'LCP avviene al termine dell'animazione: il browser considera completato l'LCP solo quando l'elemento è completamente visibile. Se hai un'animazione fade-in, il timer continua a scorrere finché l'immagine o il contenuto non sono completamente visibili, 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 utilizzare effetti fade-in. Lascia che l'immagine si carichi e venga mostrata immediatamente, senza alcuna transizione o animazione.

Evita i fade-in sull'immagine LCP. L'effetto visivo non vale il costo prestazionale.

8. Esegui il self-hosting dell'elemento LCP

Ospita l'immagine LCP sul tuo server (self-hosting). Affidarsi a server di terze parti introduce ritardi completamente al di fuori del tuo controllo, che possono danneggiare l'LCP e le prestazioni complessive della pagina.

Pensa a questo esempio: non fare il self-hosting dell'elemento LCP è come chiedere continuamente dello zucchero in prestito al vicino. Ogni volta devi camminare fino a lì, aspettare alla porta e sperare che sia a casa. Affidarsi a un server di terze parti per il tuo LCP costringe il tuo sito web ad attendere quella risorsa esterna, rallentando i tempi di caricamento. Il self-hosting è come tenere lo zucchero nella propria cucina: rapido, 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à, della disponibilità di quel server e di qualsiasi round-trip time (RTT) aggiuntivo. Il self-hosting elimina questa incertezza, consentendoti di servire l'immagine direttamente dal tuo server per garantire una consegna più rapida e affidabile.

Parere dell'esperto: la CDN moderna come origine singola

Il principio cardine consiste nel ridurre al minimo le nuove connessioni all'origine (DNS, TCP, TLS). L'architettura più avanzata ottiene questo risultato utilizzando una CDN moderna come reverse proxy per l'intero dominio. Dal punto di vista del browser, questo si connette sempre a un'unica origine (ad esempio, www.yourdomain.com), eliminando completamente le penalità di connessione. La CDN instrada quindi le richieste in modo intelligente dietro le quinte, recuperando i contenuti dinamici dal tuo server di origine e servendo gli asset statici come le immagini dalla sua edge cache. Quando questa singola connessione è supportata da HTTP/3, si ottiene il meglio da ogni aspetto: un'origine unificata, tempi di configurazione della connessione ridotti e mitigazione del head-of-line blocking.

Usa caching e ottimizzazioni: con il self-hosting puoi trarre pieno vantaggio dalle strategie di caching e servire l'immagine dal server più vicino all'utente, specialmente se usi una CDN. Questo riduce il tempo necessario per caricare l'elemento LCP, con un conseguente rendering più rapido.

Controllo sull'ottimizzazione dell'immagine: il self-hosting ti offre il controllo su come ottimizzare l'immagine, che si tratti di compressione, ridimensionamento o selezione del formato, senza dipendere dalla gestione di terze parti. In questo modo puoi assicurarti che l'immagine sia perfettamente su misura per un caricamento rapido.

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 si verificano tempi di LCP più lenti, poiché il browser deve attendere che gli script vengano scaricati, analizzati ed eseguiti prima di mostrare 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 notevolmente la sua comparsa. Più tempo richiede questo processo, peggiore sarà il tuo punteggio LCP. Ogni secondo in più speso per elaborare gli script si traduce in un'attesa più lunga prima che i tuoi utenti vedano il contenuto più importante.

Parere dell'esperto: perché il CSR danneggia l'LCP

La principale penalità prestazionale del CSR per l'LCP consiste nel fatto che nasconde l'immagine LCP al preload scanner ad alta velocità del browser. Il compito di questo scanner è trovare le risorse nell'HTML iniziale e scaricarle immediatamente. Quando un'immagine viene renderizzata con JavaScript, risulta invisibile a questo scanner, creando un lungo e non necessario ritardo di scoperta.

Passa a Server-Side Rendering (SSR) o al Rendering Statico: eseguendo il rendering dell'elemento LCP lato server o all'interno di una risposta HTML statica, consenti al browser di caricarlo e mostrarlo immediatamente, senza attendere l'attivazione di JavaScript. Questo migliora drasticamente il tempo di LCP, poiché il browser può renderizzare l'elemento LCP da subito quando inizia a caricare l'HTML.

Riduci al minimo JavaScript sul critical path: 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 lo spazio per prevenire i layout shift

Includi sempre attributi width e height espliciti nei tuoi tag <img>. Si tratta di un'istruzione fondamentale per il browser, che gli consente di calcolare l'aspect ratio dell'immagine e riservare la quantità corretta di spazio nel layout prima del download dell'immagine.

Parere dell'esperto: il comportamento moderno di width e height

Un malinteso comune è che questi attributi rendano un'immagine non responsiva. Questo non è più vero nei browser moderni. Il browser utilizza questi attributi HTML per calcolare un aspect ratio e occupare lo spazio, ma l'immagine rimarrà perfettamente responsiva se il suo CSS è impostato su width: 100%; height: auto;. Fornire questi attributi è preferibile rispetto all'utilizzo della sola proprietà CSS aspect-ratio, poiché il browser può riservare lo spazio prima che qualsiasi CSS render blocking sia stato scaricato e analizzato, ottenendo un vantaggio fondamentale in termini di tempo.

Gestione delle immagini di sfondo CSS

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

11. Analizza i blocchi 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 a eseguire JavaScript pesante. Spesso, la causa di questo blocco risiede negli script di terze parti per analisi, annunci pubblicitari 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 i long task durante il caricamento iniziale, attribuirli alla loro origine e differire (defer) o rimuovere quelli non critici per il rendering iniziale. Per saperne di più su questo argomento, consulta la nostra guida su Element Render Delay.

Guide correlate all'ottimizzazione dell'LCP

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

  • Risolvi e identifica i problemi di LCP: la metodologia diagnostica completa per trovare e risolvere i problemi di LCP utilizzando field data e lab data.
  • Resource Load Delay: assicura che il browser scopra la risorsa LCP il prima possibile grazie a preload, fetchpriority e a una struttura HTML ottimale.
  • Resource Load Duration: riduci il tempo di download attraverso compressione, configurazione della CDN e ottimizzazione della rete.
  • Element Render Delay: libera il main thread in modo che il browser possa eseguire il paint dell'elemento LCP immediatamente dopo il download.

Porto i siti a passare i Core Web Vitals.

Oltre 500K pagine per grandi editori e piattaforme e-commerce in Europa. Scrivo io il fix e lo verifico con dati reali dal campo.

Come lavoro
Ottimizza l'immagine del Largest Contentful PaintCore Web Vitals Ottimizza l'immagine del Largest Contentful Paint