Ottimizzare l'immagine Largest Contentful Paint

Una guida passo-passo all'ottimizzazione delle immagini LCP

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

Ottimizzare l'immagine Largest Contentful Paint

Questa guida fa parte dell'hub Largest Contentful Paint (LCP). Sulla 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 renderlo veloce.

Secondo Google solo il 65% di tutte le visualizzazioni di pagina su internet (inclusi desktop e mobile) ha un punteggio Largest Contentful Paint 'buono'. Ciò significa che il 35% delle visualizzazioni di pagina sta fallendo, e questo è in parte dovuto agli errori commessi con le immagini. Questo articolo analizza i comuni pattern di buona pratica e gli errori 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 la parte di ottimizzazione delle immagini, dai un'occhiata alla mia sezione 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. Solitamente consiste principalmente nell'attesa del server, ma include anche reindirizzamenti, tempi di connessione, crittografia e altro.
  2. Load Delay: Il divario tra quando l'elemento LCP avrebbe potuto iniziare a caricarsi e quando effettivamente lo fa. Leggi la guida completa su Resource Load Delay.
  3. Resource Load Time: Il tempo necessario per il caricamento della risorsa LCP. Ottimizzare la compressione e la minificazione può accelerare questa fase. Leggi la guida completa su Resource Load Duration.
  4. Render Delay: Anche con risorse ottimizzate, il browser potrebbe essere impegnato con altri task (solitamente il download di fogli di stile o pesanti elaborazioni JavaScript), ritardando il rendering dell'LCP. Leggi la guida completa su Element Render Delay.

Sebbene tutti questi fattori contino, se il tuo elemento LCP è un'immagine (e lo è spesso!), ci sono semplici passaggi 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 fidarti della parola di nessuno. Ci sono troppi 'guru' là fuori che predicano informazioni errate. Ecco perché ho creato un esperimento LCP completamente automatico in cui puoi verificare tu stesso cosa succede quando l'elemento LCP non viene caricato in modo ottimale. Dai un'occhiata al mio LCP Test su github o prova la live demo!

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

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

Il modo più veloce per migliorare il tuo Largest Contentful Paint basato su immagini? Non usare un'immagine! 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 un <p>) fa 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. Ciò 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 il controllo del candidato LCP è una strategia potente e di livello esperto.

Quindi, qual è il caso delle immagini rispetto al testo? Le immagini sono importanti; rendono il tuo sito visivamente accattivante. Ma i Core Web Vitals non si curano di quale elemento diventi l'LCP. Quando l'elemento LCP è un elemento basato sul testo, solitamente coincide 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. Ciò significa che non mi sentirai sostenere il passaggio a vecchi e noiosi elementi di testo. Ma gli errori capitano! Vorrei avere un dollaro per ogni pagina di categoria caduta vittima dell'anti-pattern "Accidental LCP". È qui che una pagina "dimentica" di aggiungere un testo descrittivo della categoria above the fold, facendo sì che un'immagine prodotto caricata in lazy load diventi l'LCP e ritardi i tempi di caricamento di secondi. Ciò accade spesso quando i designer posizionano un grande banner hero in cima al DOM, prima di qualsiasi titolo significativo, 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 un acceso dibattito sullo spremere l'ultimo byte o sulle impostazioni perfette per WebP vs AVIF, concordiamo su una cosa: i formati più vecchi come JPEG e PNG sono più pesanti e 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.

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

Velocità di decodifica vs. Compromesso della compressione

Sebbene AVIF offra la migliore compressione (dimensione del file più piccola), i suoi algoritmi complessi possono richiedere più potenza della CPU per la decodifica in un'immagine renderizzabile rispetto a WebP. Questo è un task CPU-bound che avviene sui thread del Rasterizer 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 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 vedi questo, è un segnale chiaro che la velocità di decodifica è il tuo collo di bottiglia, non solo il tempo di download.

Approfondimento esperto: Il caso di JPEG-XL. Una vera guida per esperti deve affrontare JPEG XL. È un formato tecnicamente notevole, specialmente per la sua capacità di ricomprimere senza perdite i JPEG esistenti (una grande vittoria per i siti legacy) e il suo supporto per la decodifica progressiva, che manca ad AVIF. Tuttavia, il suo svantaggio decisivo è la mancanza di un ampio supporto da parte dei browser dopo essere stato abbandonato da Chrome. Questo lo rende non ancora praticabile per l'uso generale sul web, ma lo posiziona come uno da tenere d'occhio per il futuro.

Utilizzo dell'elemento <picture>: L'elemento <picture> consente 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="Immagine" 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 delle immagini responsive in un unico elemento <picture>. Ciò garantisce 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, 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="Testo alt descrittivo per l'immagine hero"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Questo pattern dà al browser la completa 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 ripiegherà su un JPEG della dimensione corretta.

Utilizzo della negoziazione del contenuto

La negoziazione del contenuto consente al tuo server di servire diversi formati di immagine in base al supporto del browser. I browser annunciano i formati supportati tramite l'intestazione Accept. Ad esempio, in Chrome, l'intestazione Accept per le immagini è simile a questa:

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

Quindi, lato server, leggi l'intestazione accept e, in base ad essa, 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 appaiano comunque bene sugli schermi dei tuoi utenti. Le immagini di grandi dimensioni non servono a nulla: sprecano larghezza di banda e rallentano i tempi di caricamento, specialmente per gli utenti su connessioni 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 ricevono 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). Ciò significa che su un grande schermo desktop, il browser scaricherà un'immagine enorme dalla tua lista 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), portando a uno spreco di larghezza di banda e a un LCP più lento. 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 fare una scelta di download intelligente.

Capire i descrittori w vs. x

L'attributo srcset supporta due tipi di descrittori. Per il responsive design in cui la dimensione di un'immagine cambia con il viewport, il descrittore w (width) è la scelta superiore e necessaria. Viene utilizzato con l'attributo sizes per consentire al browser di scegliere la migliore immagine 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 effettivamente 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="Immagine" width="123" height="123">

4. Adatta le tue immagini alle dimensioni dello schermo!

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. Credimi, vedo succedere questo ogni giorno! Per controllare, fai semplicemente così: ispeziona l'immagine facendo clic con il tasto destro sull'immagine e seleziona 'ispeziona elemento'. Vedrai ora i dev-tools e l'HTML dell'immagine evidenziato con uno sfondo blu. Puoi ora vedere che la dimensione renderizzata dell'immagine (443 x 139px) è molto più piccola della larghezza intrinseca dell'immagine (1090x343px). È quasi 3 volte più grande e il ridimensionamento dell'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 lazy load le immagini che non sono immediatamente visibili). Questo è uno degli errori più comuni nell'ottimizzazione dell'LCP, e lo trattiamo in dettaglio nel nostro articolo sulla correzione delle immagini LCP caricate in lazy load.

Eager Loading: L'elemento LCP (solitamente contenuto above the fold) dovrebbe sempre essere caricato in modo eager. Ciò assicura che appaia il più rapidamente possibile, riducendo il tempo necessario per il rendering del Largest Contentful Paint. Per impostazione predefinita, le immagini vengono caricate in modo eager a meno che non sia specificato diversamente, ma ricontrolla di non aver 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 interamente l'attributo ha lo stesso effetto. L'azione critica è assicurarsi che loading="lazy" non sia presente.

Avviso Geek: Le immagini lazy non vengono messe in coda dal preload scanner. Il preload scanner è un parser HTML secondario super veloce che mette immediatamente in coda le risorse importanti. Quando il preload scanner viene bypassato, il browser dovrà attendere il completamento del motore di rendering prima di mettere in coda 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 aver calcolato il layout il browser può determinare se l'immagine è nel viewport. Ciò significa che l'intero CSS diventa una dipendenza bloccante per il download dell'immagine LCP, il che è un disastro per le prestazioni.

<img src="lcp-image.jpg" alt="Immagine principale" 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 scorre vicino ad esse, liberi larghezza di banda per contenuti più importanti, come il tuo elemento LCP. In questo modo il lazy loading è un coltello 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="Immagine secondaria"
     loading="lazy" 
     width="800" height="400">

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

6. Preload dell'immagine LCP

Il preloading dell'immagine LCP indica al browser di recuperarla immediatamente, prima di scoprirla naturalmente nell'HTML. Per una guida completa al preloading, consulta il nostro articolo dedicato sul preloading 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 è referenziata più in basso nella catena, il che significa che il browser ci arriva più tardi di quanto dovrebbe. Il preloading dell'immagine LCP fa sapere in anticipo al browser che questa immagine è critica e deve essere caricata immediatamente, riducendo il ritardo nel rendering del tuo elemento più grande.

Come eseguire il preload dell'immagine LCP

Utilizzando il tag <link rel="preload">, puoi assicurarti 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">

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

Approfondimento esperto: Preload responsive e fetchpriority

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

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

Includere fetchpriority="high" sul tag <img> fornisce un fallback, assicurando che l'immagine abbia comunque la priorità se il preload non è supportato. È un approccio prudente: il preload avvia il download in anticipo e il fetchpriority assicura che vinca la gara per la larghezza di banda.

Ricorda: Esegui il preload solo dell'immagine LCP, poiché il preloading di troppe risorse può sovraccaricare il browser e danneggiare le prestazioni. Attieniti a 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 accattivanti, ma sono un collo di bottiglia LCP nascosto. Se l'elemento LCP (spesso un'immagine) utilizza un effetto fade-in, il browser non conteggerà l'LCP finché l'animazione non sarà terminata. Ciò ritarda il timing dell'LCP e può danneggiare significativamente le tue metriche di performance.

Approfondimento esperto: Il meccanismo del ritardo dell'animazione

Questo problema non è limitato ai soli fade-in. Si applica a qualsiasi animazione che transita un elemento da uno stato inizialmente invisibile o fuori dallo schermo, come slide-in (ad esempio, iniziando con transform: translateX(-100%)) o effetti zoom (ad esempio, iniziando con transform: scale(0.5)). La logica LCP è progettata per misurare quando l'elemento più grande è visivamente stabile e completo. Un elemento che sta ancora animando non è considerato stabile. Ciò aumenta direttamente la sottoparte Element Render Delay dell'LCP, poiché il browser ha già scaricato l'immagine ma viene artificialmente trattenuto dal dipingere il frame finale fino alla conclusione dell'animazione.

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

Keep It Simple: Per assicurarti che l'elemento LCP appaia il più rapidamente possibile, evita di usare effetti fade-in. Lascia che l'immagine si carichi e venga visualizzata immediatamente, senza alcuna transizione o animazione.

Salta i fade-in sull'immagine LCP. L'effetto visivo non vale il costo in termini di prestazioni.

8. Auto-ospita l'elemento LCP

Ospita tu stesso la tua immagine LCP (self-hosting). Affidarsi a server di terze parti introduce ritardi che sono completamente al di fuori del tuo controllo, il che può danneggiare il tuo LCP e le prestazioni generali della pagina.

Pensala in questo modo: Non ospitare tu stesso il tuo elemento LCP è come chiedere costantemente dello zucchero in prestito al vicino. Ogni volta, devi camminare fino a lì, aspettare alla porta e sperare che sia in casa. Affidarsi a un server di terze parti per il tuo LCP fa sì che il tuo sito web debba aspettare quella risorsa esterna, rallentando i tempi di caricamento. L'auto-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 sua disponibilità e di eventuali tempi di round-trip (RTT) aggiuntivi. L'auto-hosting elimina questa incertezza, consentendoti di servire l'immagine direttamente dal tuo server, assicurando una consegna più rapida e affidabile.

Approfondimento esperto: Il moderno CDN come origine singola

Il principio fondamentale è ridurre al minimo le nuove connessioni all'origine (DNS, TCP, TLS). L'architettura più avanzata ottiene questo risultato utilizzando un moderno CDN come reverse proxy per l'intero dominio. Dal punto di vista del browser, si connette solo a un'unica origine (ad esempio, www.tuodominio.com), eliminando completamente le penalità di connessione. Il CDN instrada quindi intelligentemente le richieste dietro le quinte, recuperando il contenuto dinamico dal tuo server di origine e servendo asset statici come le immagini dalla sua edge cache. Quando questa singola connessione è alimentata da HTTP/3, ottieni il meglio di tutti i mondi: un'origine unificata, tempi di configurazione della connessione ridotti e mitigazione dell'head-of-line blocking.

Usa caching e ottimizzazioni: Auto-ospitando, puoi sfruttare appieno le strategie di caching e servire l'immagine dal server più vicino all'utente, specialmente se stai usando un CDN. Ciò riduce il tempo necessario per caricare l'elemento LCP, con un conseguente rendering più rapido.

Controllo sull'ottimizzazione delle immagini: L'auto-hosting ti dà il controllo su come l'immagine viene ottimizzata, che si tratti di compressione, ridimensionamento o selezione del formato, senza affidarti alla gestione di terze parti. In questo modo, puoi assicurarti che l'immagine sia perfettamente su misura 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) è renderizzato lato client tramite JavaScript, spesso porta a tempi LCP più lenti poiché il browser deve attendere il download, l'analisi e l'esecuzione degli script prima di visualizzare il contenuto critico.

Ritardi nel rendering: Con il CSR, l'elemento LCP viene visualizzato solo dopo che il browser ha elaborato il JavaScript, il che può ritardarne significativamente l'apparizione. Più tempo ci vuole, peggiore diventa il tuo punteggio LCP. Ogni secondo extra speso a elaborare gli script si traduce in una attesa più lunga affinché i tuoi utenti vedano il contenuto più importante.

Approfondimento esperto: Perché il CSR danneggia l'LCP

La principale penalità prestazionale del CSR per l'LCP è 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 recuperarle immediatamente. Quando un'immagine è renderizzata con JavaScript, è invisibile a questo scanner, creando un lungo e non necessario ritardo di scoperta.

Passa al Server-Side Rendering (SSR) o al Rendering Statico: Renderizzando l'elemento LCP lato server o come parte di una risposta HTML statica, consenti al browser di caricarlo e visualizzarlo immediatamente, senza attendere l'avvio di JavaScript. Ciò migliora drasticamente il timing LCP, poiché il browser può renderizzare l'elemento LCP subito quando 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. Differisci (defer) o rendi asincroni (async) gli script non critici per evitare che ritardino l'apparizione del tuo LCP.

10. Riserva spazio per prevenire i Layout Shift

Includi sempre attributi width e height espliciti sui tuoi tag <img>. Questa è un'istruzione critica per il browser, che gli consente di calcolare il rapporto d'aspetto dell'immagine e riservare la corretta quantità 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 utilizza questi attributi HTML per calcolare un rapporto d'aspetto 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, ottenendo un vantaggio critico.

Gestione delle immagini di sfondo CSS

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

11. Audit per 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 a eseguire JavaScript pesanti. 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 i 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. Per saperne di più su questo argomento, consulta la nostra guida su Element Render Delay.

Guide correlate all'ottimizzazione LCP

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

  • Identificare e Risolvere i Problemi LCP: La metodologia diagnostica completa per trovare e risolvere i problemi LCP usando dati sul campo 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 attraverso la compressione, la configurazione CDN e l'ottimizzazione della rete.
  • Element Render Delay: Libera il main thread in modo che il browser possa dipingere l'elemento LCP immediatamente dopo il download.

17 years of fixing PageSpeed.

I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.

View Services
Ottimizzare l'immagine Largest Contentful PaintCore Web Vitals Ottimizzare l'immagine Largest Contentful Paint