Corriger le Eager Loading des Bannières Hero sur Shopify (2026)

Dernière mise à jour
•
Spécialiste consulté
•
5 min de lecture
Jacques Blom
Jacques Blom
CTO chez Fudge.

Points clés

  • Le filtre image_tag de Shopify applique automatiquement loading="lazy" aux images se trouvant après les trois premières sections - votre image hero doit explicitement avoir un loading="eager" défini.
  • Ajoutez fetchpriority="high" à la balise <img> du hero pour la placer en tête de la file d’attente de téléchargement du navigateur.
  • Pour les images hero configurées en background-image CSS, ajoutez une balise <link rel="preload"> dans le <head> de theme.liquid. L’URL doit correspondre exactement, sinon le navigateur téléchargera l’image en double.
  • Le correctif se fait dans sections/image-banner.liquid (ou slideshow.liquid / la section de votre hero), et non dans theme.liquid lui-même - à l’exception du preload.
  • Pas très technique ? Décrivez le correctif à Fudge et l’outil modifie les fichiers de section pour vous.

Si un audit Lighthouse ou PageSpeed Insights vient de vous signaler que votre image hero est en lazy-loading - ou que l’élément LCP a été préchargé trop tard - vous êtes au bon endroit. Ce guide vous montre exactement quelles modifications Liquid effectuer pour que votre hero se charge rapidement en mode eager, avec un fetchpriority et un preload si nécessaire.

Pourquoi vous pouvez nous faire confiance

Nous avons travaillé avec des centaines de marques Shopify pour améliorer les performances de leur storefront (vitrine), et nous avons créé Fudge - un éditeur de storefront sous IA noté 5.0 sur le Shopify App Store. Les modèles (patterns) ci-dessous sont ceux que nous appliquons nous-mêmes et que nous recommandons lors de nos audits.

Pourquoi votre image hero est en lazy-loading

Il y a plusieurs causes courantes :

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" à n’importe quelle image située au-delà de la troisième section du template1. Si votre section hero se trouve en quatrième position de la page (à cause d’une barre d’annonce, d’une promo sticky ou d’un carrousel d’apps la précédant), elle sera soumise au lazy-loading par défaut.

2. Le thème impose un code en dur loading="lazy". Certains anciens thèmes attribuent aveuglément cette valeur à chaque image, sans que le hero n’y échappe.

3. Le hero est une background-image CSS. Lorsque le hero est généré sous forme de background-image: url(...) plutôt que via une balise <img> classique, le navigateur ne le détecte pas lors de l’analyse initiale (parsing). Il n’y a donc aucun attribut loading applicable et le fetchpriority ne pourra rien y changer.

4. Une application ou une modification l’a supplantée. Certaines applications vont jusqu’à injecter des lignes de code dont le but est de remplacer la valeur eager par lazy sur toutes vos images visant à “améliorer les performances”. Ce qui s’avère être exactement l’inverse du but recherché pour un élément LCP.

Comment le diagnostiquer

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

Lancez pagespeed.web.dev sur votre boutique. Sous l’onglet Diagnostics, l’entrée “Largest Contentful Paint element” (Élément LCP) indique quel élément est mesuré. S’il s’agit de votre hero et que la métrique “Load Delay” est élevée, c’est que l’image est récupérée trop tard.

Article connexe : Accélérer un Thème Shopify.

Corriger la balise <img> dans votre section hero

En général, le composant hero se situe dans l’un de ces fichiers de section - jamais au niveau de theme.liquid :

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

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

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

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

Étape 4. Remplacez loading="lazy" par 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 image_tag plus moderne :

{{ 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 votre hero, cliquez sur Inspecter, et confirmez que les nouveaux attributs sont bien en place.

Un pattern plus propre : section.index

Coder en dur loading="eager" fonctionne bel et bien, mais encore faut-il s’assurer que sa section ne bougera pas de place (soit un cas de figure où on dépose son fameux hero tout en bas dans l’Éditeur de thème). Et tout d’un coup, on n’est plus face à l’élément LCP alors qu’il est toujours chargé de manière eager. Le pattern le plus nomade recourt à 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
}}

En d’autres termes : si je suis placé en guise de première section de page, mon affichage hérite d’une priorité de rendu fixée à high. Si ma position se cantonne au top 3 des sections introduites de prime abord, charge-moi en mode eager. Si aucun de ces critères n’est retrouvé, opte pour le lazy load. C’est le pattern que Shopify recommande à sa communauté dès qu’il s’agit d’insérer une section en mesure de se retrouver en dehors (ou au sein) des frontières propres au LCP1.

Vous voulez que ce correctif soit fait pour vous en quelques secondes ? Décrivez-le à Fudge.
Try Fudge for Free

Précharger un hero en background-image CSS

Si votre hero est affiché en tant que background-image: url(...) dans le CSS, le navigateur ignore totalement de quoi il est question jusqu’à l’heure où votre feuille de style passe à la loupe et télécharge les informations requises avant la phase d’application concrète des résultats. Auquel moment le compte-gouttes du processus LCP tournera encore en trame de fond.

Le correctif est un preload (un repère de prechargement) dans le module <head> du fichier theme.liquid. Ceci notifie le navigateur de lancer un processus anticipé du téléchargement de la photo concernée de façon expresse, et d’omettre la lecture préliminaire en CSS.

Étape 1. Accédez au sous-dossier de configuration sous l’intitulé layout/theme.liquid.

Étape 2. Localisez le cadre <head>, et insérez un paramètre conditionnel de preload dont l’actionnement ne se manifestera que s’il est question d’une consultation sur la page sur laquelle il opère (cela reste, d’ordinaire, sur la page d’accueil) :

{%- if template.name == 'index' -%}
  {%- assign hero_section = sections['image-banner'] -%}
  {%- if hero_section.settings.image -%}
    <link
      rel="preload"
      as="image"
      href="{{ hero_section.settings.image | image_url: width: 2000 }}"
      fetchpriority="high"
    >
  {%- endif -%}
{%- endif -%}

L’URL dans votre balise de préchargement se doit de correspondre à celle que le navigateur solliciterait, au besoin - à l’extrême justesse. Le même paramètre de largeur width, même mode pour la dimension du crop, même type d’extension au sujet du format. S’il se trouve qu’un désaccord se crée à un seul petit caractère près, le moteur d’interprétation des rendus retéléchargera l’ensemble tout neuf sans pouvoir rien exploiter en aval et en rajoutant ainsi une énième surcharge dont on se passerait sans soucis.

Étape 3. Si l’affichage de votre image change selon la surface d’ancrage (une découpe sur smartphone différente), insérez les lignes de code sous imagesrcset ou bien avec imagesizes si votre but reste de faire correspondre ces repères à sa bonne taille en guise d’adaptation par navigateur :

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

Étape 4. À défaut faire les choses mieux, pourquoi ne pas transposer ladite figure de configuration de style d’image CSS background-image vers les attributions pures d’affichage, encadrées de leur vraie balise <img> de départ à sa section native. Cette transposition offre, le temps de cette petite retouche de position, un vrai mode natif au regard de ses instructions HTTP issues de son éditeur mère (ici Shopify). De l’autre côté de la route, tous composants visuels à travers d’autres paramétrages en background de type CSS, et destinés à illustrer ce que l’on attend à titre d’élément formel encadré, deviennent ici carrément un anti-pattern2.

N’appliquez pas fetchpriority="high" sur toutes vos images

Le terme fetchpriority="high" est reconnu en soi sous une appellation désignant une caractéristique aux ressources restreintes. Qu’on décide d’encadrer de très fortes attentes un groupe composé d’une petite flotte de cinq portraits imagés afin d’instaurer une condition sur son temps d’exposition à son audience - un navigateur web optera sans compromis pour celle à traiter de prime abord au désavantage des dernières (car il lui incombait tout de même du point de vue informatique de réaliser des choix contraignants en matière d’affichage compensatoire sur l’écran des autres cibles, à cause de son absence globale de directives). Indiquez un ciblage limité à une seule image selon la page étudiée : ce sera ici cet élément LCP qui figurera au sein de la ligne choisie.

La méthode ci-présente rejoint sur ses principes de logistique le fonctionnement des requêtes visant l’anticipation lors d’un preload (les directives informatiques destinées aux actions preloading dont nul navigateur web d’ordinaire n’hérite lors de simples instructions routinières sans code approfondi). C’en est une par page. Accumuler un tas de phases chargées d’anticipation visuelle au milieu des compétitions visées à obtenir leurs lots d’interactions vis-à-vis d’un support sous bande passante se traduira toujours par le but qu’il aurait mieux valu contourner au tout départ : ce ne sera qu’un résultat final encore plus lent.

Vérifiez le correctif

1. Inspectez le HTML généré. Assurez-vous que l’affichage de notre repère d’inspection fait référence aux attributions attendues soit loading="eager" sous notre fetchpriority="high", situées correctement au niveau de ce trait particulier <img> du hero.

2. Ouvrez l’interface de ce célèbre outil sur Chrome DevTools → au sein de sa division Network (Réseau) → et assurez un mode réinitialisation des contenus afin d’annuler les cache de sa configuration (reload with cache disabled). Catégorisez ses classements de vue avec le tri Priority. Ce paramètre, visible autour de ce qui touche directement notre balise fixée à son champ hero, se montrera avec force attributions pointant vers des considérations aux priorités extrêmement percutantes (ce Highest de retour d’un de ses indicateurs de réussite d’objectifs) et localisé au sommet de ces colonnes.

3. Retestez depuis l’une de ces analyses proposées sur ce module d’amélioration qu’incarne un pagespeed.web.dev sous contrôle. Notre fameuse mention “Largest Contentful Paint element” dans notre diagnostic se rafraîchira pour désigner de suite le retard lié au délai réduit à recompiler sur nos informations techniques. Des chiffres LCP descendront souvent aux niveaux impressionnants à l’issue d’une baisse, comprise entre les paliers des 500 et 2000 ms dès lors que s’y trouvera rattaché ce lent réseau en téléphonie d’une offre sous forfaits mobiles.

4. Ayant pris un préchargement de mise, lancez son contrôle via sa branche Network en fouillant l’information pour sa recherche vis-à-vis de son adresse relative. Notre vue cible devra s’y nicher et exister d’elle seule (jamais reproduite par 2 ou au-delà d’interrogation de chargements redondants de suite sans justification de ses attributions respectueuses ! ). Tout ce qui affiche sa paire sur une entrée vous mettra simplement à l’appui que sa retransmission échoue sous sa correspondance sur fond d’adresses divergentes en preloading : veillez au grain de le supprimer à temps de ces mauvaises pratiques.

Vous n’avez pas envie de modifier le code Liquid ?

Tout le déroulé au fil de cet exposé part de la supposition que son exécution reste familièrement acquise sans tracas de mise en page manuelle de la modification et tout avec vos encadrements des marqueurs balises. Dans cet esprit de simplicité évidente à la moindre appréhension sur la chose abordée en profondeur sur le Liquid, ce module d’action à distance nommé Fudge exécutera toute sa fonction à travers l’intervention sur une écriture simple en base promptée de mise à jour. C’est à la hauteur d’une description simple du paramétrage comme suivant :

“Sur cette fameuse bannière d’ouverture à partir du hero sise d’accueil liée au fichier theme.liquid, place-moi toutes tes dispositions avec loading=eager accompagné de sa balise sous fetchpriority=high visant l’affichage qui y figure de l’image. Est-ce positionné en sa caractéristique issue d’éléments décors orientés autour d’une écriture sur format dit en ressource vis-à-vis à du code en CSS derrière tout le design à titre unique sans images à ancrage basique ? Intègre en ce cas ton aide de code liée sur les mises au point à configurer de preload de la configuration au nom de tout l’apprêt au coeur des réglages templates et fixée sur ce trait index de l’accueil.”

Au moment attendu face aux changements de requêtes dictés que comprend cette formulation d’intentions exprimée, cet algorithme performant Fudge pondra précisément vos extraits corrigés et présentés pour s’admirer sur sa validation visuelle sur thème de magasin. Seulement par la suite validée en l’action d’une authentification consentie par vos touches interposées ! Zéro casse-tête aux démultiplications sans queue sur cet aperçu Liquid pour la gestion simplifiée (pas besoin de syntaxe à se farcir par l’oubli).

Les pièges courants

Le hero est placé au sein de toute la structure paramétrée d’un diaporama à plusieurs volets de slides. À sa présence sur l’aperçu du chargement originel fixant tout le champ du regard lié avec une disposition initiale de cette structure d’écran partagée, nulle mise au point de perception ne rend au moins cet unique aperçu misant ainsi toutes ses attributions formelles. Exécutez le mode eager loading avec un fetchpriority="high" réservé exclusivement sous paramétrage orienté à propos du point d’entrée dont l’usage premier en est l’unique intérêt de première nécessité (la toute première diapositive !) tout en cantonnant ce volet restant avec des considérations vouées au retrait et limitées de nature par définition dans vos dispositions différées rattachées sous sa désignation liée par principe au niveau dudit chargement.

Ce fameux attrait misant du héros au sein des visuels est amené au renouveau au contact suivant vos bases thématiques pour l’interface de boutique déployées vers une application modulaire. La prise en figure dudit point fixe de cet abord à partir de ce point hero du thème central sur sa vitrine n’y aura toujours à s’y affirmer d’autre titre tel qu’un hero placé tout ce qu’il a à exister du format collection et tout en tant qu’apprêts distinctement formulés en la considération même pour votre base. Réalisez de la sorte un redressement orienté du coup à fond afin de répondre sans faille aux particularités distinctives que posera ce profil du cas, y compris les dispositions qui s’en tiendront à y encadrer le sujet aux recommandations formulant la fonction d’anticipation pour ce modèle au travers des spécificités paramétrables dont les bases en tiendront avec un exemple par des formules en usage telles que if template.name == 'index', et on passe sur ce profil pour le coup.

Votre image demeure affichée sans ce format optimal si typique qui a le vent en poupe en tant que disposition sous son label d’attribution à partir du standard WebP à proposer sur un réseau. Vous vous appuyez bien aux forces du fonctionnement propre au CDN sous le giron de l’arsenal lié à ce support qu’octroie si généreusement Shopify ? Tout y relaye en effet dès que vos visiteurs sous naviguent sous ce confort pris en compte - le hic viendrait sous la position inéquivoque dès ces conditions-là dont nos applications visent d’aller vers vos options de image_url ainsi qu’avec de point basique du type img_url. Cette appellation sous base formulée simplement de configuration balise en src="...assets/banner.jpg" affranchie purement des paramétrages poussés du reste n’accordera jamais sa portée orientée sans limites depuis sa version en mode WebP par définition du format en amont sur le port réseau. Les seuls moyens en ligne à cet effet imposent l’incorporation inévitable dont sont issus quelques uns de nos filtres de conception orientés depuis l’outil que propose cet univers par biais mis au sein du monde sur base des instructions formulées en syntaxe aux ressources intégrées (Liquid).

C’est à coup avec ce souci redondant lié par implication provenant d’app du type rajout depuis un menu en magasin, écrasante des modifications. Vous bouclez cette partie dédiée qui vient supplanter votre modification mais de contrôle sous un aperçu visé d’utilisation par affichage de sa part sur Inspect ne trouve de raisonnant aux fins du reste avec un code bloqué là pour faire face de maintien du format avec de ce profil-là sur la page - à titre d’image : du coup il s’agit alors sans surprise aux attributions logicielles sur ce front de DOM d’interrompre vos modifications suite d’instructions depuis l’accès du JavaScript depuis son app au fond des rouages sur l’arrivée à la fin et suite de rechargement final en de son processus d’activation d’affichages que propose l’appli orientée pour écraser en force brute (ainsi elle ne vient appliquer loading="lazy" aveuglément sans crier gare du reste !). Reconsédérez aux bases votre arsenal d’extensions sur vos menus des applis pour dénicher un optimiseur au nom de sa gestion dédiée depuis des questions reliées suivant ces prétendues options de votre site visant du pseudo “traitement des données relatives au chargement du poids final mis en considération sous ses attributs du média”, de quoi vous ruiner cet objectif initial de manière discrète.

Article connexe : Images en Lazy Load sur Shopify.

Article connexe : Compresser vos Images sur Shopify.

Article connexe : Corriger les Scripts Bloquants le Rendu sur Shopify.

Quand s’attendre à une vraie baisse du LCP

Si votre hero était en lazy-loading et plutôt lourd, attendez-vous à une amélioration de l’ordre de 1 à 3 secondes de votre LCP sur une connexion 4G lente. S’il était déjà paramétré pour un rendu en eager mais manquait son attribut fetchpriority, projetez une anticipation sur le registre alloué vers ces 200 à 800 ms de temps libéré à cet égard de traitement lié au gain total de bout en bout de chaîne visuelle lors du lancement de phase d’une telle correction fixée si du moins, par miracle de complément, on rajoute cette dernière considération par les preload ! Le retour est à s’additionner d’un bond spectaculaire superposé par une autre.

Mais s’il vous reste avec un paramètre à son encontre dans le panel mis à profit par un système d’outils PageSpeed dont l’étude aboutit à décerner encore sans ménagement ce LCP dans une fourchette aux proportions de délai en deçà, la question va de surcroît au sujet d’une congestion vers des chemins dont les freins se dirigent sous du format issu des encodages de la page (fameux JavaScript de page et de ce fichier CSS bloquant dans ses résolutions graphiques sans appel de phase de ce temps passé au relais en cours du rendu), la sollicitation vers sa vitesse du délai pour accomplir toutes nos requêtes au-delà du temps serveurs se traduisant de nature vers cette cause de poids accablante sise dans tout ce fatras accablant sans contredit : l’image pèse ce que pèse et ce point l’illustre si sa carrure excède des caractéristiques orientée suivant ces charges de type format lourd insupportables par une résolution mise sur ces fins de connexion mobile. Diminuez votre image en taille puis fouillez ensuite ce côté Scripts de conception dont on aura tant insisté tout d’abord au vu de ses priorités traitées en cours dessus.

Jacques's signature
Corrigez vos problèmes de performance en décrivant ce que vous voulez.
Essayer Fudge gratuitement
See how Fudge edits themes
5.0

1 : L’avis officiel de Shopify sur le filtre image_tag et les configurations de base liés avec de modèle qu’on retrouvera sous la balise code en standard orienté avec un paramètre au format de la racine des instructions par le positionnement d’usage : Announcing new Liquid features for better web performance (Les nouvelles fonctionnalités annoncées de Shopify pour amener plus haut les performances dédiées au web).

2 : Les recommandations fournies à l’initiative du projet d’instructions à consulter et de mise avec toute recommandation issue sur le socle provenant du fameux Web.dev et liées afin d’en tenir vos composants LCP par définition sans contrainte du CSS pour les composantes en base sous format du paramètre en background-image : lire d’office vers Optimizing images for performance on Shopify.

FAQ

Pourquoi Shopify met-il mon hero image en lazy-loading par défaut ?

Le filtre image_tag de Shopify applique loading="lazy" aux images situées après la troisième section de votre template. Si votre hero est la 4ème section (par ex., après la barre d’annonce, une promo sticky, une section d’app), le lazy-loading sera activé dessus. C’est un bon comportement par défaut pour les images qui ne constituent pas le LCP, mais c’est néfaste pour l’image hero — vous devez définir explicitement loading="eager".

Est-ce que chaque image au-dessus de la ligne de flottaison doit utiliser loading="eager" ?

Non. Utilisez loading="eager" uniquement pour l’élément LCP — typiquement votre hero image. Les autres images au-dessus de la ligne de flottaison (logo, icônes du menu de navigation, bannières secondaires) sont suffisamment petites pour que la différence entre lazy et eager loading n’affecte pas votre LCP de manière significative. La règle est aussi de ne mettre fetchpriority="high" que sur une seule image par page.

Est-ce que mettre fetchpriority="high" sur toutes les images accélérera ma page Shopify ?

Non, c’est l’inverse. fetchpriority="high" est un signal relatif. Si plusieurs images sont marquées comme “high”, le navigateur réduit la priorité du véritable élément LCP afin de compenser. Définissez cet attribut sur une seule image (l’élément LCP) par page. C’est la même chose pour les preloads : un seul par page.

Puis-je ajouter un preload sans modifier le fichier theme.liquid ?

Theme.liquid est l’emplacement standard, car la balise <link rel="preload"> doit se trouver dans le <head> et theme.liquid englobe toutes vos pages. Bien que certaines sections supportent un point d’injection via {% layout 'theme' %}, ce n’est pas le cas de la majorité. Si vous ne pouvez pas modifier theme.liquid vous-même, Fudge peut faire la modification pour vous en toute sécurité et sans toucher au code.

Comment vérifier que l’ajout du comportement eager-loading a fonctionné ?

Il existe trois méthodes : (1) Clic droit sur l’image hero → Inspecter → vérifier que les attributs loading="eager" et fetchpriority="high" sont bien présents sur la balise <img>, (2) Chrome DevTools → Onglet Network → rafraîchir la page → trier par Priority (Priorité) → le hero image devrait être sur la valeur Highest (la plus élevée), et (3) relancer un test PageSpeed Insights — le “Load Delay” du LCP devrait avoir drastiquement baissé, entraînant une hausse de votre score LCP global.

Jacques's signature
Optimisez vos performances en décrivant simplement ce que vous voulez.
Essayer Fudge gratuitement
See how Fudge edits themes
5.0

Footnotes

  1. Recommandations officielles de Shopify concernant les nouveautés du filtre image_tag et section.index : Announcing new Liquid features for better web performance. ↩ ↩2 ↩3

  2. Recommandation de Web.dev pour éviter l’usage de background-image en CSS sur les éléments LCP : voir Optimizing images for performance on Shopify. ↩ ↩2

You might also be interested in

Comment minifier le CSS et le JavaScript sur Shopify (2026)
Comment Shopify gère automatiquement la minification du CSS et du JS, quand devez-vous encore le faire manuellement, et quels sont les meilleurs outils pour vos blocs de code custom.
Comment Lazy Loader des Vidéos sur Shopify (2026)
Ajoutez du lazy loading aux vidéos sur Shopify grâce au pattern façade pour les embeds YouTube et Vimeo. Réduisez le poids de la page en différant le chargement des iframes.
Comment corriger les scripts qui bloquent le rendu sur Shopify (2026)
Corrigez les scripts bloquant le rendu sur Shopify. Ajoutez les attributs defer ou async, utilisez le JS au niveau des sections et déplacez les scripts non critiques.