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

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

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 srcset et 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

Comment savoir si une page web contient des images d'arrière-plan ? Vous pourriez ouvrir l'inspecteur réseau, filtrer sur les images, faire un clic droit sur l'en-tête, afficher la colonne Initiateur et vérifier la source. Mais coller ce code dans la console est bien plus rapide.

Ouvrez simplement la console avec Ctrl-Shift-I, allez sur l'onglet Console et collez ce code. Il affichera toutes les images d'arrière-plan de la 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.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Arjen Karel

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
Arjen Karel
Arjen Karel, Consultant en performance web depuis 2009

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 URL

Pas de développeur pour réaliser le fix ? Je fais le travail moi-même, sur une copie de votre site.

Les images d'arrière-plan sont une plaie Core Web Vitals Les images d'arrière-plan sont une plaie