Corriger l'eager loading de la bannière Hero sur Shopify (2026)

À retenir

• Le filtre image_tag de Shopify applique automatiquement loading="lazy" aux images après les trois premières sections - votre hero a besoin que loading="eager" soit explicitement défini.
• Ajoutez fetchpriority="high" à la balise <img> du hero pour la placer en tête de la file de téléchargement du navigateur.
• Pour les heroes utilisant background-image en CSS, ajoutez un <link rel="preload"> pour l’image en haut du fichier de la section hero. L’URL doit correspondre exactement, sinon le navigateur télécharge l’image deux fois.
• La correction se fait dans sections/image-banner.liquid (ou slideshow.liquid/votre section hero), et non dans theme.liquid.
• Pas développeur ? Fudge peut faire cette correction pour vous : décrivez le changement et il modifie les fichiers de la section sous forme de brouillon que vous pouvez prévisualiser et approuver.

Pour corriger une bannière hero en lazy-loading sur Shopify, définissez loading="eager" et fetchpriority="high" sur l’image hero dans son fichier de section, et ajoutez une indication de preload si le hero est en background CSS. Si un audit a signalé votre hero avec “fetchpriority=high should be applied” ou “This img tag is above the fold and could be eagerly-loaded to improve performance.”, voici les modifications Liquid exactes pour régler le problème.

Pourquoi nous faire confiance

Nous avons travaillé avec des centaines de marques Shopify sur les performances de leur storefront, et nous développons Fudge, l’opérateur IA pour les boutiques Shopify, noté 4.9 sur le Shopify App Store. Les modèles ci-dessous sont ceux que nous appliquons nous-mêmes et recommandons lors de nos audits.

Pourquoi mon image hero Shopify est-elle en lazy-loading ?

Plusieurs choses peuvent en être la cause :

1. Le comportement par défaut de Shopify. Lorsque vous affichez une image avec le filtre image_tag et que vous ne définissez pas l’attribut loading, Shopify applique loading="lazy" à toute image située après la troisième section dans le template¹. Si votre section hero est la quatrième sur la page (à cause d’une barre d’annonce, d’une promo sticky ou d’une section d’app au-dessus), elle passe en lazy-loading par défaut.

2. Le thème a codé loading="lazy" en dur. Certains thèmes plus anciens appliquent loading="lazy" sans distinction à chaque image, y compris le hero.

3. Le hero est un background-image CSS. Lorsque le hero est généré via background-image: url(...) au lieu d’une balise <img>, le navigateur ne le voit pas lors de l’analyse initiale. Il n’y a pas d’attribut loading à définir, et fetchpriority ne s’applique pas.

4. Une app ou une customisation l’a écrasé. Certaines apps injectent des scripts qui remplacent eager par lazy sur toutes les images pour “améliorer les performances”. C’est exactement l’inverse de ce que vous voulez pour l’élément LCP.

Pour mettre en lazy-loading les images situées plus bas sur la page, consultez comment lazy-loader des images sur Shopify.

Comment vérifier si mon image hero est en lazy-loading ?

Faites un clic droit sur l’image hero de votre boutique → Inspecter. Regardez la balise <img> dans le HTML.

• Le problème est loading="lazy". Remplacez-le par loading="eager".
• Sans fetchpriority, le navigateur la traite comme une image de priorité normale et peut la récupérer après les scripts et les polices. Ajoutez fetchpriority="high".
• S’il n’y a aucune balise <img>, cela signifie que c’est un background-image CSS - passez directement à la section preload ci-dessous.

Lancez pagespeed.web.dev sur votre boutique. Sous Insights, ouvrez LCP request discovery et LCP breakdown. Si le hero indique “lazy load not applied” ou “fetchpriority=high should be applied”, ou si son délai de chargement de ressource (resource load delay) est élevé, c’est que l’image est récupérée trop tard.

Pour un ensemble plus large d’optimisations de vitesse, consultez comment accélérer un thème Shopify.

Corriger la balise <img> dans votre section hero

Le hero se trouve généralement dans l’un de ces fichiers de section - et non dans theme.liquid :

• sections/image-banner.liquid (thèmes basés sur Dawn)
• sections/slideshow.liquid
• sections/hero.liquid ou sections/featured-hero.liquid (thèmes sur mesure)

Étape 1. Dupliquez votre thème. Toujours.

Étape 2. Ouvrez le fichier de section correspondant dans l’éditeur de code.

Étape 3. Trouvez la balise <img> ou l’appel au filtre image_tag. Dans les anciens thèmes, cela ressemble à ceci :

<img
  src="{{ section.settings.image | image_url: width: 2000 }}"
  alt="{{ section.settings.image.alt }}"
  width="2000"
  height="1000"
  loading="lazy"
/>

Étape 4. Changez loading="lazy" en loading="eager" et ajoutez fetchpriority="high" :

<img
  src="{{ section.settings.image | image_url: width: 2000 }}"
  alt="{{ section.settings.image.alt }}"
  width="2000"
  height="1000"
  loading="eager"
  fetchpriority="high"
/>

Si votre thème utilise le filtre moderne image_tag :

{{ section.settings.image
  | image_url: width: 2000
  | image_tag: loading: 'eager', fetchpriority: 'high', alt: section.settings.image.alt
}}

Étape 5. Sauvegardez et rechargez. Faites un clic droit sur le hero, Inspecter, et confirmez que les nouveaux attributs sont bien en place.

La méthode plus propre : section.index

Coder loading="eager" en dur fonctionne, mais la section peut être déplacée (un marchand la glisse plus bas sur la page d’accueil dans l’éditeur de thème) et soudainement, elle n’est plus l’élément LCP tout en continuant à se charger de manière eager. Le modèle plus flexible utilise section.index :

{%- liquid
  assign loading = 'eager'
  assign fetchpriority = 'auto'
  if section.index == 1
    assign fetchpriority = 'high'
  elsif section.index > 2
    assign loading = 'lazy'
  endif
-%}

{{ section.settings.image
  | image_url: width: 2000
  | image_tag: loading: loading, fetchpriority: fetchpriority, alt: section.settings.image.alt
}}

Cela veut dire : si je suis la première section de la page, récupérez-moi avec une priorité élevée. Si je suis dans les deux premières, chargez-moi en eager. Sinon, passez en lazy load. C’est le modèle que Shopify lui-même recommande pour toute section d’image qui pourrait se retrouver dans ou hors de l’emplacement LCP¹.

Précharger un hero en background-image CSS

Si votre hero est généré avec un background-image: url(...) en CSS, le navigateur ignore l’existence de l’image jusqu’à ce qu’il analyse votre feuille de style, la télécharge et l’applique à l’élément. À ce stade, le chrono du LCP a déjà bien tourné.

La solution est une indication de préchargement (preload). Cela indique au navigateur de commencer à récupérer l’image pendant qu’il analyse le HTML, avant que la feuille de style ne soit téléchargée et appliquée.

Placez cette indication dans le fichier de la section hero, et non dans theme.liquid. Les fichiers de layout ne peuvent pas lire les paramètres d’une section, donc theme.liquid n’a aucun moyen de savoir quelle image le marchand a choisie pour le hero. Une balise <link rel="preload"> est autorisée dans le body, et le navigateur la trouve quand même tôt dans le HTML.

Étape 1. Ouvrez le fichier de la section hero, par exemple sections/image-banner.liquid.

Étape 2. En haut du code de la section, ajoutez un preload qui ne s’affiche que lorsque la section est la première sur la page :

{%- if section.index == 1 and section.settings.image -%}
  <link
    rel="preload"
    as="image"
    href="{{ section.settings.image | image_url: width: 2000 }}"
    fetchpriority="high"
  >
{%- endif -%}

Si vous préférez placer cette indication dans la balise <head>, codez l’URL de l’image en dur dans layout/theme.liquid (copiez-la depuis la page générée) et mettez-la à jour chaque fois que l’image du hero change.

L’URL dans votre balise de préchargement doit correspondre à l’URL que le navigateur demanderait par ailleurs - exactement. Même paramètre width, même crop, même format. S’il y a la moindre différence, le navigateur récupérera les deux et vous aurez aggravé la situation.

Étape 3. Si votre image varie selon le viewport (le mobile a un recadrage différent), utilisez imagesrcset et imagesizes pour que le navigateur précharge la bonne image :

<link
  rel="preload"
  as="image"
  imagesrcset="{{ section.settings.image | image_url: width: 800 }} 800w,
               {{ section.settings.image | image_url: width: 1200 }} 1200w,
               {{ section.settings.image | image_url: width: 2000 }} 2000w"
  imagesizes="100vw"
  fetchpriority="high"
>

Étape 4. Mieux encore : convertissez le background-image CSS en une vraie balise <img> à l’intérieur de la section. Vous bénéficiez ainsi de fetchpriority, d’un srcset automatique, et du comportement de préchargement via en-tête HTTP propre à Shopify. Utiliser des backgrounds CSS pour l’élément LCP est un anti-pattern².

Ne mettez pas fetchpriority="high" sur toutes les images

Le fetchpriority="high" est une ressource limitée. Si vous marquez cinq images comme étant de haute priorité, le navigateur devra faire un choix – et il déclassera les autres pour compenser. Appliquez-le sur une seule image par page : l’élément LCP.

Il en va de même pour les préchargements (preload). Un seul par page. De multiples preloads en compétition pour la bande passante ralentissent précisément ce que vous essayez d’accélérer.

Vérifier la correction

1. Inspectez le HTML rendu. Vérifiez que loading="eager" et fetchpriority="high" sont bien présents sur la balise <img> du hero.

2. Ouvrez les Chrome DevTools → onglet Network → rechargez avec le cache désactivé. Triez par Priorité. L’image de votre hero devrait être tout en haut ou presque, avec la priorité “Highest”.

3. Relancez pagespeed.web.dev. L’analyse LCP breakdown devrait afficher un délai de chargement de ressource plus faible, et le LCP global devrait baisser.

4. Si vous avez ajouté un preload, ouvrez l’onglet Network et cherchez l’URL de l’image. Elle doit apparaître une seule fois, pas deux. Si vous voyez deux entrées, c’est que l’URL du preload ne correspond pas à l’URL de l’image rendue - corrigez cette différence.

Corrigez-le sans coder : utilisez Fudge

Si vous n’êtes pas développeur, l’éditeur de boutique de Fudge peut faire cette correction. Vous décrivez le changement avec des mots simples - Fudge modifie les fichiers de la section, vous montre un aperçu sur votre thème en direct, et n’applique les modifications à votre boutique que lorsque vous les approuvez.

Pas besoin de dupliquer le thème ni de toucher à la syntaxe Liquid.

Utilisez un prompt du type :

“Dans la section hero de la page d’accueil, définis loading=eager et fetchpriority=high sur l’image de la bannière. Si c’est un background CSS, ajoute un preload pour l’image de la bannière.”

Fudge s’occupe à la fois de modifier image_tag et d’ajouter le <link rel="preload"> - la même correction en deux étapes décrite ci-dessus - sous forme de brouillon que vous prévisualisez avant de publier, sans que vous n’ayez à toucher au code. Si vous n’êtes pas sûr que le hero soit votre seul problème, demandez d’abord à Fudge de faire un audit de vitesse : il listera ce qui ralentit vos pages et préparera chaque correction sous forme de brouillon pour que vous l’approuviez.

Pièges courants

Le hero est dans un carrousel avec plusieurs slides. Seule la première slide est visible lors du rendu initial. Appliquez le chargement eager et fetchpriority="high" uniquement à l’image de la première slide - chargez les autres en lazy load.

Le hero change selon le template. Un hero de page d’accueil et un hero de page de collection sont des sections différentes. Appliquez la correction à chacun, et gardez l’indication de préchargement dans la section qui se trouve en premier sur ce template.

Votre image n’est pas servie en WebP. Le CDN de Shopify sert du WebP ou de l’AVIF automatiquement quand le navigateur le supporte - mais uniquement si vous utilisez image_url ou img_url. Un simple src="...assets/banner.jpg" n’aura pas de WebP. Utilisez les filtres Liquid.

Une app annule vos modifications. Si vous corrigez la section mais que l’Inspecteur montre toujours loading="lazy", c’est que le JavaScript d’une app modifie le DOM après le chargement de la page. Vérifiez vos apps installées pour des outils de “performance” ou “d’optimisation d’image” - certaines d’entre elles réappliquent loading="lazy" partout sans faire de distinction.

Un hero qui se charge tardivement sans espace réservé va aussi décaler tout ce qui se trouve en dessous. Pour ce problème, consultez Cumulative Layout Shift sur Shopify.

Quand s’attendre à une baisse significative du LCP

Si votre hero était en lazy-loading et lourd, attendez-vous à une amélioration du LCP de 1 à 3 secondes sur une connexion 4G lente. S’il était déjà en eager mais sans fetchpriority, attendez-vous à gagner de 200 à 800ms. Si vous corrigez aussi un background-image CSS avec un preload, les gains se cumulent.

Si vous faites ces modifications et que PageSpeed signale toujours le LCP comme lent, c’est que le goulot d’étranglement a bougé ailleurs - CSS ou JavaScript bloquant le rendu (render-blocking), temps de réponse du serveur, ou une image hero qui est tout simplement trop lourde. Compressez l’image d’abord, puis penchez-vous sur les scripts bloquant le rendu.

FAQ