Les images d'arrière-plan sont mauvaises
Pourquoi les images d'arrière-plan nuisent à vos Core Web Vitals et comment les remplacer
Les images d'arrière-plan sont mauvaises
Ceux d'entre vous qui me connaissent ou qui m'ont entendu parler m'ont peut-être déjà entendu aborder le sujet des images d'arrière-plan. Pour ceux qui ne me connaissent pas : je n'aime vraiment, mais alors vraiment pas les images d'arrière-plan. Voici pourquoi je ne les aime pas, comment trouver rapidement les pages contenant des images d'arrière-plan et comment les corriger.
Dernière révision par Arjen Karel en mars 2026
Pourquoi les images d'arrière-plan sont mauvaises pour les Core Web Vitals
Lors du chargement d'une page web, chaque élément a son moment et sa place. Avec certaines techniques modernes comme le report (deferring), le préchargement (preloading), le chargement asynchrone, la planification, la définition de la fetchpriority, etc., nous pouvons garder toutes les ressources critiques sous contrôle. À l'exception des images d'arrière-plan !
Considérez cet exemple concret :
Au quotidien, principalement sur des sites WordPress, je vois ce modèle. Toutes les images normales sont chargées en différé (lazy loaded) et certaines images (dans ce cas, les icônes sociales dans le pied de page) sont des images d'arrière-plan. Pouvez-vous deviner ce qui se passe ?
<html>
<head>
<style>
footer {
/* une marge de 100 vh rendra le pied de page hors écran !*/
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>
<!-- oui cette image est chargée en différé, car de petites erreurs arrivent ! -->
<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 peut-être deviné : les images d'arrière-plan hors écran sont mises en file d'attente pour le téléchargement avant l'image 'hero.jpg' beaucoup plus importante qui deviendra généralement l'élément Largest Contentful Paint de la page.
Mais ce n'est pas tout !
Comme je l'ai dit, les images d'arrière-plan sont mauvaises ! C'est parce que, mis à part la priorité étrange qu'elles obtiennent parfois, les images d'arrière-plan n'ont pas les fonctionnalités géniales que les images normales possèdent !
- Pas de chargement différé (lazy loading) : il n'y a pas d'attribut loading pour les images d'arrière-plan. L'attribut
loading="lazy"qui fonctionne sur les balises<img>(avec 94,9 % de support global) 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 la plus importante. Avec les balises
<img>, 17,3 % des pages mobiles utilisent déjàfetchpriority="high"sur leur image LCP selon le Web Almanac 2025. - Sources d'images responsives : la fonction image-set() pour les images d'arrière-plan n'a pas les mêmes fonctionnalités que celles que vous obtenez avec
srcsetet l'élément<picture>. - Pas d'attribut width et height. Ne pas pouvoir définir les simples attributs de largeur (width) et de hauteur (height) signifie que le navigateur ne peut pas réserver d'espace pour l'image, ce qui provoque un décalage de mise en page (CLS). Vous finissez par utiliser des solutions de contournement CSS, et plus de code est toujours plus lent que moins de code avec la même complexité !
- Pas de texte alternatif (alt text) : les images d'arrière-plan n'ont pas d'attribut alt, ce qui nuit à l'accessibilité et signifie que Google Images ne peut pas les indexer.
Les images d'arrière-plan chargées via url() sont des candidats LCP valides. Une image d'arrière-plan lente apparaîtra comme votre LCP, mais vous n'avez aucun des outils ci-dessus pour l'optimiser. Le navigateur doit d'abord télécharger et analyser le CSS avant même de savoir que l'image existe. Ce délai de chargement des ressources (resource load delay) ajoute environ 400 ms au LCP médian selon les propres mesures de Google.
Selon le Web Almanac 2025, 9 % des pages mobiles utilisent encore une image initiée par CSS comme élément LCP. Ce chiffre n'a pas changé depuis 2022. Sur les sites surveillés par CoreDash, le remplacement d'une image d'arrière-plan héros par une balise <img> a amélioré le LCP médian de 35 %.
Trouver rapidement toutes les images d'arrière-plan sur 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('Aucune image d\'arrière-plan sur cette page !');
Cela vous montrera un tableau proprement formaté avec tous les noms des images d'arrière-plan et les initiateurs.
Comment éviter les images d'arrière-plan
Les images d'arrière-plan sont facilement évitables. La manière de procéder dépend de l'image elle-même. Il y a grosso modo 2 méthodes.
Dans le cas d'« images normales »
Vous ne le croiriez pas si je vous le disais, mais dans la majorité des cas où je trouve des images d'arrière-plan, la partie arrière-plan de l'image n'a même pas d'utilité. Les images « doivent simplement être quelque part sur la page » et la propriété background-image:url() est mal utilisée à cette fin.
Si c'est le cas, ajoutez simplement une balise d'image normale et supprimez l'image d'arrière-plan de la feuille de style.
Dans le cas d'images de couverture (cover images) :
Les images de couverture sont des images qui recouvrent complètement un conteneur parent. L'utilisation d'images d'arrière-plan comme images de couverture a un certain sens car, il y a longtemps, c'était la seule façon d'obtenir des images de couverture et je suppose que les gens s'en tiennent à ce qu'ils connaissent. Heureusement, il existe de meilleures options à notre disposition. Alors, corrigeons cela !
Dans le cas d'images de couverture, supprimez simplement le style background-image: url(hero.jpg); background-size: cover; et placez une image normale dans ce même conteneur, puis modifiez le CSS pour qu'il ressemble à ceci :
<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="texte alternatif"
fetchpriority="low"
>
</div>
Vous disposez maintenant d'une image appropriée 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, vous avez réellement besoin d'une image d'arrière-plan CSS : motifs répétitifs, superpositions décoratives ou cas où le CMS ne vous laisse pas d'autre choix. Dans ces situations, préchargez (preload) l'image pour que le navigateur la découvre tôt :
<link rel="preload" href="hero.webp" as="image" type="image/webp" fetchpriority="high">
Placez ceci le plus tôt possible dans la balise <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 fait défiler la page près d'elles.
Pour vérifier que vos modifications améliorent réellement l'expérience utilisateur, configurez le Real User Monitoring. Les scores de laboratoire (Lab scores) vous indiquent ce qui devrait être plus rapide. Les données de terrain (Field data) provenant de vrais visiteurs vous indiquent ce qui l'est réellement.
Find out what is actually slow.
I map your critical rendering path using real field data. You get a clear answer on what blocks LCP, what causes INP spikes, and where layout shifts originate.
Book a Deep Dive
