Les images d'arrière-plan sont une plaie
Pourquoi les images d'arrière-plan nuisent aux Core Web Vitals et comment les remplacer
Les images d'arrière-plan sont une plaie
Si vous me connaissez ou m'avez déjà entendu en conférence, vous m'avez sans doute entendu parler des images d'arrière-plan. Pour les autres : je ne les aime vraiment pas. Voici pourquoi, comment repérer rapidement les pages qui en utilisent et comment les corriger.
Dernière révision par Arjen Karel en mars 2026
Pourquoi les images d'arrière-plan nuisent aux Core Web Vitals
Au chargement d'une page web, chaque élément a sa place et son moment. Grâce à des techniques modernes comme le preload, le chargement différé ou asynchrone, la planification ou l'attribut fetchpriority, on maîtrise quasiment toutes les ressources critiques. Sauf les images d'arrière-plan !
Prenons un exemple concret :
Au quotidien, surtout sur les sites WordPress, je vois souvent ce cas de figure. Toutes les images classiques sont en lazy loading et certaines images (ici les icônes de réseaux sociaux dans le footer) sont des images d'arrière-plan. Vous devinez ce qui se passe ?
<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>Vous l'avez deviné : les images d'arrière-plan hors écran sont mises en file d'attente avant l'image bien plus importante « hero.jpg » qui deviendra généralement l'élément largest contentful paint de la page.

Mais ce n'est pas tout !
Comme je le disais, les images d'arrière-plan sont une plaie ! En plus de leur priorité parfois aberrante, elles sont privées des fonctionnalités modernes des images classiques !
- Pas de lazy loading : il n'y a pas d'attribut loading pour les images d'arrière-plan. L'attribut
loading="lazy"des balises<img>(qui affiche 94,9 % de support mondial) n'existe tout simplement pas pour les arrière-plans. - Pas de décodage asynchrone : il n'y a pas d'attribut decoding pour les images d'arrière-plan
- Pas de fetchpriority : il n'y a pas d'attribut fetchpriority pour les images d'arrière-plan. Vous ne pouvez pas indiquer au navigateur quelle image d'arrière-plan est prioritaire. Avec les balises
<img>, 17,3 % des pages mobiles utilisent déjàfetchpriority="high"sur leur image LCP d'après le Web Almanac 2025. - Sources d'images responsives : la fonction image-set() pour les images d'arrière-plan n'offre pas les mêmes possibilités que
srcsetet l'élément<picture>. - Pas d'attributs width et height. L'impossibilité de définir les simples attributs width et height empêche le navigateur de réserver l'espace pour l'image, ce qui provoque du layout shift (CLS). Vous finissez par recourir à des contournements CSS, et à complexité égale, plus de code est toujours plus lent que moins de code !
- Pas de texte alt : les images d'arrière-plan n'ont pas d'attribut alt, ce qui nuit à l'accessibilité et empêche leur indexation par Google Images.
Les images d'arrière-plan chargées via url() sont des candidates valides au LCP. Une image d'arrière-plan lente sera retenue comme LCP, mais vous n'avez aucun des outils précédents pour l'optimiser. Le navigateur doit d'abord télécharger et parser le CSS avant même de savoir que l'image existe. Ce resource load delay ajoute environ 400 ms au LCP médian selon les propres mesures de Google.
D'après le Web Almanac 2025, 9 % des pages mobiles utilisent toujours une image initiée en CSS comme élément LCP. Ce chiffre n'a pas bougé depuis 2022. Sur les sites suivis par CoreDash, remplacer une image hero en arrière-plan par une balise <img> a amélioré le LCP médian de 35 %.
Repérer rapidement toutes les images d'arrière-plan d'une page
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!'); Cela affichera un tableau clair avec le nom de toutes les images d'arrière-plan et leur initiateur.

Comment éviter les images d'arrière-plan
Les images d'arrière-plan s'évitent facilement. La marche à suivre dépend de l'image. Il existe en gros deux méthodes.
Pour les « images classiques »
Aussi surprenant que cela paraisse, dans la majorité des cas où je trouve des images d'arrière-plan, la fonction d'arrière-plan n'a aucune utilité. L'image doit juste « être quelque part sur la page » et background-image:url() est détourné pour cela.
Si c'est le cas, insérez simplement une balise image classique et supprimez l'image d'arrière-plan de la feuille de style.
Pour les images de couverture :
Les images de couverture recouvrent entièrement leur conteneur parent. Utiliser des images d'arrière-plan pour cela a une certaine logique : c'était autrefois la seule méthode possible, et les habitudes ont la vie dure. Heureusement, nous disposons aujourd'hui de bien meilleures solutions. Corrigeons cela !
Pour les images de couverture, supprimez simplement le style background-image: url(hero.jpg); background-size: cover;, placez une image normale dans ce même conteneur et modifiez le CSS comme suit :
<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>
Vous disposez désormais d'une vraie image avec les attributs width, height, loading, decoding, srcset, fetchpriority et alt. Tout ce dont le navigateur a besoin pour la charger efficacement.
Quand vous devez conserver une image d'arrière-plan
Parfois, une image d'arrière-plan CSS reste nécessaire : motifs répétitifs, calques décoratifs ou cas où le CMS ne laisse pas d'autre choix. Dans ces situations, préchargez l'image afin que le navigateur la découvre au plus tôt :
<link rel="preload" href="hero.webp" as="image" type="image/webp" fetchpriority="high">
Placez cette balise le plus tôt possible dans le <head>. Pour les images d'arrière-plan hors écran, vous pouvez les différer avec un IntersectionObserver afin qu'elles ne se chargent que lorsque l'utilisateur s'en approche au défilement.
Pour vérifier que vos modifications améliorent concrètement l'expérience utilisateur réelle, mettez en place du Real User Monitoring. Les scores en lab data vous disent ce qui devrait être plus rapide. La field data des vrais visiteurs montre ce qui l'est réellement.

Besoin d'un site plus rapide ?
Je suis Arjen et je répare des sites lents depuis 17 ans. Si vous rencontrez des problèmes que vous ne pouvez pas résoudre vous-même, envoyez-moi votre URL et parlons-en.
Envoyez-moi votre URL
Pourquoi notre fix ne fonctionne pas ?
Parfois le CDN sert encore l'ancien HTML, ou le fix a été appliqué sur le template desktop alors que le mobile en utilise un autre. Envoyez-moi votre URL et le problème, et je vous réponds avec quelques créneaux. J'analyse d'abord vos field data, puis nous passons une heure sur votre site, et sous 24 heures vous avez mes notes par écrit. 350 € HT.
Envoyez-moi votre URLPas de développeur pour réaliser le fix ? Je fais le travail moi-même, sur une copie de votre site.