Correggi le hero image lente e i Core Web Vitals

Come correggere le hero image lente: in breve

Le hero image sono grandi immagini nella parte superiore di una pagina web. Queste hero image causeranno un lungo Largest Contentful Paint se non sono ottimizzate. 9 siti su 10 che mi viene chiesto di ottimizzare hanno problemi con le hero image. In questo articolo ti mostrerò diverse tecniche su come velocizzare le hero image.

Ultima revisione di Arjen Karel nel febbraio 2026

Cos'è una hero image?

Una Hero Image, a volte chiamata 'hero header', è una grande immagine con testo, spesso posizionata nella parte superiore di una pagina web. Una hero image serve come primo sguardo di un utente alla tua azienda e offerta a causa del suo posizionamento prominente verso la parte superiore di una pagina web che di solito si estende per tutta la larghezza.

Un rapido promemoria: le hero image, i Core Web Vitals e il Largest Contentful Paint: 
A causa delle dimensioni della hero image (di solito copre l'intera larghezza della pagina e una buona parte dell'altezza del viewport visibile) questo elemento diventerà l'elemento Largest Contentful Paint in quasi tutti i casi.
Il Largest Contentful Paint è un'importante metrica dei Core Web Vitals. L'elemento largest contentful paint è il più grande elemento che verrà renderizzato nel viewport visibile del browser. Secondo il Web Almanac 2025, sul 76% delle pagine mobile l'elemento LCP è un'immagine. Solo il 62% delle origini mobile supera attualmente l'LCP. Correggi la hero image e correggerai l'LCP per la maggior parte dei siti.
Poiché le immagini non ottimizzate tendono a occupare molta larghezza di banda e quindi impiegano molto tempo a caricarsi, le hero image spesso causeranno metriche di Largest Contentful Paint scadenti.

Ottimizzare la hero image e il Largest Contentful Paint

Ci sono molte tecniche per ottimizzare le hero image e il Largest Contentful Paint. Le spiegherò qui. La maggior parte delle tecniche può essere combinata per risultati ancora migliori!

1. Fai il preload della hero image o invia 103 Early Hints

Quando vuoi che un elemento sia disponibile il prima possibile nel browser, potresti farne il preload. Il preloading implica l'uso di resource hints. I resource hints dicono al browser qualcosa sulla priorità di un elemento e innescheranno un download molto anticipato di quella risorsa. Secondo il Web Almanac 2025, solo il 2,1% delle pagine fa il preload della propria immagine LCP. Questa è un'enorme opportunità persa.

<link
  rel="preload"
  as="image"
  href="wolf.jpg"
  fetchpriority="high"
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w"
  imagesizes="50vw">

I 103 Early Hints consentono ai server di inviare resource hints prima della risposta HTML finale. Il browser può iniziare il preloading della hero image mentre il server sta ancora generando la pagina. Chrome, Edge e Firefox supportano tutti il preloading tramite Early Hints. Safari supporta preconnect ma non ancora il preload tramite Early Hints. Per i dettagli su come configurarlo, leggi la guida completa ai 103 Early Hints.

Nei siti monitorati da CoreDash, le pagine con un'immagine LCP in preload hanno un tasso di LCP 'buono' dell'81% rispetto al 64% senza preloading. Per una panoramica completa di tutte le opzioni di preloading, vedi come fare il preload dell'immagine LCP.

2. Usa fetchpriority="high" sulla hero image

L'attributo fetchpriority dice al browser quali risorse sono più importanti. Impostare fetchpriority="high" sulla tua hero image aumenta la sua priorità di download rispetto ad altre immagini e risorse in competizione come script e font.

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

Secondo il Web Almanac 2025, solo il 17% delle pagine imposta fetchpriority="high" sulla propria immagine LCP. Ciò significa che l'83% dei siti sta rinunciando a facili guadagni in termini di prestazioni.

Puoi anche aggiungere fetchpriority="high" al link di preload mostrato sopra. Usa fetchpriority="high" solo su una singola immagine per pagina. Più immagini ad alta priorità competono tra loro e annullano il vantaggio. Per saperne di più su come i browser danno priorità alle risorse, leggi la guida dei Core Web Vitals alla prioritizzazione delle risorse.

3. Comprimi la hero image e usa formati next-gen

Comprimere le immagini renderà le dimensioni dei loro file più piccole. Dimensioni dei file più piccole occuperanno meno larghezza di banda e saranno disponibili per il browser il prima possibile. La compressione delle immagini può essere eseguita nel tuo editor di foto, nel tuo CMS (suggerimento: il tuo sviluppatore può impostare il livello di compressione di WordPress) o con uno strumento di compressione delle immagini online.

La maggior parte delle hero image lente sono più lente del necessario perché vengono fornite nel formato immagine 'sbagliato' come PNG o JPEG. Ci sono alternative molto più veloci a JPEG e PNG come WebP e AVIF. Secondo il Web Almanac 2025, il 57% delle immagini LCP è ancora servito in JPEG e il 26% in PNG, mentre solo l'11% usa WebP e meno dell'1% usa AVIF.

Per molti sistemi CMS ci sono plugin di conversione che convertiranno le tue immagini in formati next-gen. Quando la conversione delle immagini è difficile da integrare nel tuo sito web, una CDN con supporto per la conversione delle immagini potrebbe essere la soluzione che stai cercando. Per una panoramica completa delle tecniche di ottimizzazione delle immagini, vedi ottimizzare le immagini per i Core Web Vitals.

4. Non usare immagini di sfondo, usa normali immagini responsive

La tua hero image dovrebbe essere un'immagine normale e mai un'immagine di sfondo. Il modo abituale di creare hero image è aggiungere un'immagine di sfondo al contenitore hero e impostare il background-size di quel contenitore su cover. Questo garantirà che la hero image si adatti allo schermo in tutti i casi.

Le immagini di sfondo sono dannose per i Core Web Vitals. Ricordalo! Leggi di più sul perché le immagini di sfondo sono dannose per le prestazioni. Se non puoi evitare del tutto le immagini di sfondo, puoi almeno differire le immagini di sfondo che sono below the fold.

• Le immagini di sfondo vengono caricate con una priorità inferiore
• Le immagini di sfondo non sono responsive (non a meno che tu non voglia davvero complicare le cose)
• Le immagini di sfondo potrebbero causare problemi ai Core Web Vitals con la maggior parte delle librerie di lazy loading

Il modo in cui lo faccio è aggiungere un'immagine normale in posizione assoluta e impostare la proprietà object-fit di quell'immagine su cover. Una volta che ho cambiato l'immagine di sfondo in un'immagine normale, posso iniziare a usare immagini responsive. Se stai usando Elementor, scopri come correggere le hero image di Elementor.

Immagini responsive significa che per dispositivi diversi (mobile, desktop, tablet) può essere inviata una versione diversa della stessa hero image. Per un dispositivo desktop potrei inviare un'enorme hero image di 1920x1280, mentre per un dispositivo mobile dovrei solo inviare una hero image più piccola di 400x266 pixel. Si tratta di 25 volte meno dati!

• Le hero image ora vengono caricate con una priorità più alta
• Ora posso usare immagini responsive per la hero image

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source
        type="image/webp"
        media="(max-width:540px)"
        srcset="herosm.webp">
    </source>
    <img fetchpriority="high" loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

5. Servi le hero image dal dominio principale e considera una CDN

Troppo spesso vedo l'immagine del largest contentful paint servita da un dominio diverso, per esempio 'static.miodominio.com'. Questi sottodomini spesso puntano a una CDN. Sebbene io incoraggi l'uso di una CDN (vedi sotto), una configurazione come questa non è consigliabile. L'immagine sul sottodominio richiede una nuova connessione a un nuovo server. Le nuove connessioni sono costose e richiederanno tempo prezioso. Quando l'immagine viene servita dal dominio principale (ad esempio www.miodominio.com), le immagini possono essere recuperate molto più velocemente tramite la connessione al server già stabilita.

Se configurata sul dominio principale, una CDN potrebbe offrire un enorme aumento della velocità. Soprattutto quando il tuo sito viene visitato da tutto il mondo. Una CDN ha server posizionati strategicamente in tutto il mondo in cui le tue risorse statiche (come le immagini) vengono memorizzate nella cache per tempi di risposta locali rapidi. Ciò significa che i dati non devono viaggiare in tutto il mondo, ma possono essere serviti da un server edge locale. Per una guida di configurazione completa, vedi come configurare Cloudflare per i Core Web Vitals.

6. Evita il lazy loading della hero image

Assicurati che non venga applicato alcun lazy loading alla tua hero image. Le hero image dovrebbero sempre essere caricate come eager.

Molti siti, specialmente siti WordPress, utilizzano qualche tipo di plugin di pagespeed per WordPress come WP Rocket o WP Core Web Vitals. Questi plugin di solito fanno un ottimo lavoro nel velocizzare i siti lenti ma non possono correggere la stupidità :-)

Questi plugin applicheranno il lazy loading alle immagini che sembrano buone candidate per il lazy load. Se la hero image non è un'immagine eager, questi plugin probabilmente applicheranno il lazy loading anche alla hero image.

Questo, nel migliore dei casi, causerà un piccolo ritardo nelle metriche LCP. Nel peggiore dei casi, specialmente quando è attivato il lazy loading basato su JavaScript, causerà un ritardo maggiore. Secondo il Web Almanac 2025, circa il 17% delle pagine applica il lazy loading alla propria immagine LCP. Si tratta del 17% dei siti che peggiorano attivamente il proprio LCP. Se Lighthouse ti avverte di questo, vedi come correggere l'avviso dell'immagine LCP caricata con il lazy load.

Rendere le immagini eager al caricamento è semplice. Basta aggiungere loading="eager" all'immagine. Nota che eager è in realtà il valore predefinito del browser. Omettere del tutto l'attributo loading ha lo stesso effetto. Il vero obiettivo è assicurarsi che la hero image NON abbia loading="lazy". Aggiungere esplicitamente eager è comunque utile come segnale di intenti, soprattutto su siti in cui un CMS o un plugin potrebbe applicare automaticamente il lazy loading.

<img src="hero.webp" loading="eager" fetchpriority="high" width="800" height="400">

7. Evita i layout shift causati dalla hero image

Un altro problema comune che vedo con gli hero banner e le hero image è che causano un enorme layout shift. Questi layout shift possono verificarsi per diversi motivi.

• L'elemento hero è creato con JavaScript. È noto che alcuni plugin per hero e page builder come Elementor si basano su JavaScript per renderizzare il contenuto hero. Sebbene non ci sia nulla di sbagliato in JavaScript, assicurati che l'elemento hero si renderizzi allo stesso modo senza JavaScript.
• I font nell'elemento hero causano un layout shift. L'elemento hero di solito contiene del testo grande con una call to action e una tagline. Assicurati che questi font grandi non causino un layout shift.
• Dimensioni dell'immagine mancanti. Quando la hero image non è un'immagine cover (sia come immagine di sfondo o immagine posizionata in modo assoluto), le dimensioni dell'immagine mancanti (larghezza e altezza) causeranno certamente un grande layout shift.

Sebbene correggere il layout shift non migliorerà il Largest Contentful Paint, migliorerà i Core Web Vitals della pagina. Per maggiori informazioni su come correggere il layout shift, ti prego di leggere la guida approfondita su come correggere il Cumulative Layout Shift!

8. Usa il caricamento in 2 fasi per migliorare i Core Web Vitals della hero image

Il caricamento in 2 fasi è una tecnica veloce che applichiamo a tutte le nostre immagini. Serviamo prima un'immagine di qualità estremamente bassa che si prevede venga scaricata molto prima dell'immagine di alta qualità più grande. Una volta che l'immagine di bassa qualità è stata renderizzata sullo schermo, il browser viene attivato per recuperare l'immagine di alta qualità in background. Una volta che l'immagine di alta qualità è stata scaricata, l'immagine di bassa qualità verrà sostituita dall'immagine di alta qualità.

Esistono 3 metodi di caricamento in 2 fasi. I primi due sono metodi che dovresti prendere in considerazione. L'ultimo è uno che non dovresti fare.

1. Caricamento completo in 2 fasi

Con il caricamento completo in 2 fasi, la prima immagine di bassa qualità ha le stesse identiche dimensioni (larghezza e altezza) dell'immagine originale di alta qualità.

Il risultato di questo caricamento in 2 fasi è che l'elemento largest contentful paint sarà l'immagine molto più veloce e di bassa qualità (che verrà poi sostituita in modo lazy). Lo scambio dell'immagine avverrà così velocemente che un visitatore occasionale probabilmente non se ne accorgerà mai. Il risultato di questa tecnica è che l'LCP viene renderizzato molto prima, la pagina appare 'pronta' molto prima, il che contribuisce a una migliore esperienza utente e a Core Web Vitals migliorati.

2. Placeholder inline più piccoli

Il placeholder più piccolo è una tecnica piuttosto interessante che ha un inconveniente: non migliora i Core Web Vitals. Rimane comunque un'ottima tecnica perché migliora l'esperienza utente.

L'idea di base è la stessa della tecnica di caricamento in 2 fasi, ma invece di un'immagine di bassa qualità con le stesse dimensioni, un'immagine molto più piccola con dimensioni inferiori viene inserita inline tramite un data URI. La hero image finale, che sarà l'immagine del largest contentful paint, viene comunque scaricata in background. Questo trucco non migliorerà il Largest Contentful Paint ma farà apparire la pagina pronta ancora più velocemente rispetto alla tecnica di caricamento in 2 fasi.

3. Placeholder trasparenti

Una tecnica comune di caricamento in 2 fasi e un metodo per ingannare il browser facendogli inviare una metrica Largest Contentful Paint anticipata consiste nell'utilizzare elementi SVG trasparenti. Quegli elementi sono piccoli e possono essere inseriti inline, proprio come il placeholder inline più piccolo.

L'uso di un elemento SVG inline e la sua sostituzione è in realtà una tecnica di lazy loading. Il vantaggio di questa tecnica è che funziona su vari browser. 

Il lazy loading, ovviamente, dovrebbe essere applicato solo ad elementi all'esterno del viewport. In questo caso l'elemento SVG trasparente ritarderà solo la vera hero image e non ha alcun valore aggiunto per il tuo visitatore. Sebbene le metriche di paint potrebbero essere ottime, l'UX della pagina in realtà peggiorerà.

Ecco perché la hero image dovrebbe sempre essere caricata in modo eager senza trucchi che causano una cattiva UX.

Mettendo tutto insieme

Ecco come appare una hero image ottimizzata quando si combinano preloading, fetchpriority, immagini responsive ed eager loading:

<!-- In the <head> -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw">

<!-- In the <body> -->
<img src="hero-800.webp"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="Descriptive alt text">

Dopo aver apportato le modifiche, verifica il miglioramento con il Real User Monitoring. Lighthouse ti fornisce un'istantanea di laboratorio, ma Google classifica in base ai field data degli utenti reali raccolti negli ultimi 28 giorni.