Le immagini di background sono il male
Perché le immagini di background penalizzano i tuoi Core Web Vitals e come sostituirle
Le immagini di background sono il male
Chi mi conosce o mi ha sentito parlare, probabilmente mi ha già sentito parlare delle immagini di background. Per chi non mi conoscesse: non mi piacciono per niente le immagini di background. Ecco perché non mi piacciono le immagini di background, come trovare rapidamente le pagine con immagini di background e come risolvere il problema.
Ultima revisione a cura di Arjen Karel nel Marzo 2026
Perché le immagini di background sono dannose per i Core Web Vitals
Durante il caricamento di una pagina web ogni elemento ha il suo momento e il suo posto. Con alcune tecniche moderne come deferring, preloading, caricamento async, scheduling, definizione della fetchpriority, ecc., possiamo avere praticamente sotto controllo tutte le risorse critiche. Tranne le immagini di background!
Considera questo esempio del mondo reale:
Quotidianamente, soprattutto nei siti WordPress, vedo questo pattern. Tutte le immagini normali vengono caricate tramite lazy loading e alcune immagini (in questo caso le icone social nel footer) sono immagini di background. Indovini cosa succede?
<html>
<head>
<style>
footer {
/* a margin of 100 vh wil make the footer off-screen !*/
margin-top: 100vh;
>.social {
>.facebook {background-image: url('img/facebook.jpg');}
>.instagram {background-image: url('img/instagram.jpg');}
>.linkedin {background-image: url('img/linkedin.jpg');}
>.email {background-image: url('img/email.jpg');}
}
}
</style>
</head>
<body>
<!-- yes this image is lazy loaded, because tiny mistakes happen! -->
<img loading="lazy" src="img/hero.jpg"></img>
<footer>
<div class="social">
<span class="facebook"></span>
<span class="instagram"></span>
<span class="linkedin"></span>
<span class="email"></span>
</div>
</footer>
</body>
</html>
Avrai forse indovinato: le immagini di background fuori schermo vengono messe in coda per il download prima della molto più importante immagine 'hero.jpg' che diventerà solitamente l'elemento Largest Contentful Paint sulla pagina.
Ma non è tutto!
Come ho detto le immagini di background sono il male! Questo perché, a parte la strana priorità che a volte ricevono, le immagini di background non hanno le fantastiche caratteristiche di cui godono le immagini normali!
- Nessun lazy loading: non esiste alcun attributo loading per le immagini di background. L'attributo
loading="lazy"che funziona sui tag<img>(con il 94,9% di supporto globale) semplicemente non esiste per i background. - Nessuna decodifica async: non esiste alcun attributo decoding per le immagini di background
- Nessuna fetchpriority: non esiste alcun attributo fetchpriority per le immagini di background. Non puoi dire al browser quale immagine di background conta di più. Con i tag
<img>, il 17,3% delle pagine mobile utilizza giàfetchpriority="high"per la propria immagine LCP secondo il Web Almanac 2025. - Sorgenti di immagini responsive: La funzione image-set() per le immagini di background non ha le stesse funzionalità che ottieni con
srcsete l'elemento<picture>. - Nessun attributo width e height. Non poter impostare il semplice attributo width e height significa che il browser non può riservare spazio per l'immagine, il che causa Cumulative Layout Shift (CLS). Finisci per usare workaround CSS e più codice è sempre più lento di meno codice a parità di complessità!
- Nessun testo alt: le immagini di background non hanno alcun attributo alt, il che penalizza l'accessibilità e significa che Google Images non può indicizzarle.
Le immagini di background caricate tramite url() sono validi candidati per il LCP. Un'immagine di background lenta si presenterà come il tuo LCP, ma non hai nessuno degli strumenti sopra elencati per ottimizzarla. Il browser deve prima scaricare e parsare il CSS prima ancora di sapere che l'immagine esiste. Questo ritardo nel caricamento delle risorse aggiunge circa 400ms al LCP mediano secondo le misurazioni della stessa Google.
Secondo il Web Almanac 2025, il 9% delle pagine mobile utilizza ancora un'immagine avviata tramite CSS come elemento LCP. Questo numero non è cambiato dal 2022. Sui siti monitorati da CoreDash, sostituire un'immagine hero di background con un tag <img> ha migliorato il LCP mediano del 35%.
Trova rapidamente tutte le immagini di background su una pagina
let bgimg = performance.getEntriesByType('resource')
.filter(rs => rs.initiatorType == 'css')
.map(rs => {
return {
name: rs.name,
initiator: rs.initiatorType
}
}) || [];
(bgimg.length > 0)?
console.table(bgimg):
console.log('No background images on this page!');
Questo ti mostrerà una tabella formattata in modo pulito con tutti i nomi delle immagini di background e gli initiator.
Come evitare le immagini di background
Le immagini di background sono facilmente evitabili. Come farlo dipende dall'immagine stessa. Ci sono all'incirca 2 metodi.
Nel caso di 'immagini normali'
Non ci crederesti se ti dicessi che nella maggior parte dei casi in cui trovo immagini di background la parte di background dell'immagine non ha nemmeno uno scopo. Le immagini devono semplicemente 'stare da qualche parte sulla pagina' e il background-image:url() viene usato in modo improprio per questo scopo.
Se questo è il caso, aggiungi semplicemente un normale tag immagine e rimuovi l'immagine di background dal foglio di stile.
Nel caso di cover images:
Le cover images sono immagini che coprono completamente un contenitore padre. Usare le immagini di background come cover images ha un certo senso perché molto tempo fa questo era l'unico modo per ottenere le cover images e immagino che le persone rimangano legate a ciò che conoscono. Fortunatamente ci sono opzioni migliori a nostra disposizione. Quindi risolviamolo!
Nel caso di cover images rimuovi semplicemente lo stile background-image: url(hero.jpg); background-size: cover; e posiziona un'immagine normale nello stesso contenitore e modifica il CSS in modo che appaia così:
<style>
.img-container {
position: relative;
> img {
width: 100%;
height: 100%;
object-fit: cover;
position: absolute;
z-index: 1;
}
}
</style>
<div class="img-container">
<img
height="500"
width="300"
decoding="async"
loading="lazy"
src="hero.jpg"
srcset="hero-320w.jpg, hero-480w.jpg 1.5x"
alt="alt text"
fetchpriority="low"
>
</div>
Ora hai un'immagine corretta con gli attributi width, height, loading, decoding, srcset, fetchpriority e alt. Tutto ciò di cui il browser ha bisogno per caricarla in modo efficiente.
Quando devi mantenere un'immagine di background
A volte hai davvero bisogno di un'immagine di background CSS: pattern ripetuti, overlay decorativi o casi in cui il CMS non ti offre altre opzioni. In quelle situazioni, usa il preload per l'immagine in modo che il browser la scopra in anticipo:
<link rel="preload" href="hero.webp" as="image" type="image/webp" fetchpriority="high">
Posizionalo il prima possibile nell'<head>. Per le immagini di background fuori schermo, puoi differirle con un IntersectionObserver in modo che vengano caricate solo quando l'utente fa scroll vicino ad esse.
Per verificare che le tue modifiche migliorino effettivamente l'esperienza utente reale, configura il RUM. I punteggi Lab ti dicono cosa dovrebbe essere più veloce. I dati sul campo provenienti dai visitatori reali ti dicono cosa lo è effettivamente.
Pinpoint the route, device, and connection that fails.
CoreDash segments every metric by route, device class, browser, and connection type. Real time data. Not the 28 day average Google gives you.
Explore Segmentation
