Accueil Blog SEO
SEO

Optimisation des images Shopify

Guide technique d'optimisation des images Shopify : WebP, AVIF, img_url responsive, lazy loading, LCP. Code Liquid réel, correctifs concrets.

Lionel Fenestraz · 20 mai 2026 · 14 min de lecture · Mis à jour : mai 2026
Panneau Lighthouse montrant les métriques Core Web Vitals et l'analyse du poids des images d'une boutique Shopify après application de WebP et du lazy loading
Dans cet article

Si ta boutique Shopify rame, le coupable est presque toujours le même : les images. Je le constate à chaque audit. Le Web Almanac de HTTP Archive indique que les images représentent en moyenne 42,3 % du poids total d’une page mobile, plus que n’importe quelle autre ressource (HTTP Archive Web Almanac, 2024). Sur Shopify, le constat empire : les thèmes modernes chargent hero, collections et fiches produits avec des images lourdes par défaut, et presque personne ne touche au code Liquid pour ajuster tout ça. Voici le guide technique que j’aurais aimé avoir : formats, image_url, lazy loading, alt text à grande échelle, et ce que fait (ou ne fait pas) le CDN de Shopify. Pour le contexte plus large du référencement, mon guide Shopify SEO ecommerce 2026 couvre le reste de l’architecture.

Points clés

  • Les images représentent 42,3 % du poids moyen d’une page mobile (HTTP Archive, 2024)
  • Shopify sert automatiquement WebP quand le navigateur le prend en charge, depuis 2021 (Shopify.dev)
  • Le filtre image_url avec width et le helper image_tag génèrent le srcset responsive pour toi, pas besoin de l’écrire à la main (Shopify.dev)
  • L’attribut natif loading="lazy" est pris en charge par plus de 95 % des navigateurs selon Can I Use (Can I Use, 2025) ; pas besoin d’Intersection Observer sauf cas très spécifiques
  • Le LCP doit se produire en moins de 2,5 secondes au 75ᵉ percentile pour être classé « Bon » (web.dev)

Pourquoi les images sont-elles le goulot d’étranglement numéro un sur Shopify ?

Le Web Almanac de HTTP Archive place les images à 42,3 % du poids moyen d’une page mobile, devant JavaScript et CSS réunis (HTTP Archive, 2024). Sur Shopify, l’effet s’amplifie parce que les thèmes chargent des hero plein écran, des collections denses et des galeries produit sans que le marchand n’ajuste quoi que ce soit.

La cause est double. D’abord, les thèmes arrivent avec des réglages pensés pour « faire joli » dans l’éditeur, pas pour passer les Core Web Vitals. Ensuite, les apps Shopify injectent leurs propres images, widgets et scripts sans demander la permission. Sur une marque de cosmétique 200+ SKUs auditée début 2026, le hero de la home pesait 1,4 Mo en mobile. Ce seul fichier cassait déjà le budget LCP.

Quel impact sur le LCP de ta boutique ?

Le LCP (Largest Contentful Paint) est, dans 72 à 81 % des pages web selon les analyses de Google, une image (web.dev, 2024). Sur une fiche produit Shopify, le LCP correspond presque toujours à la première photo produit. Si ce fichier pèse 800 Ko et n’a pas fetchpriority="high", le LCP grimpe à 4-5 secondes en 4G. Google classe « Bon » uniquement sous 2,5 secondes au 75ᵉ percentile (web.dev).

Capsule de citation : les images représentent 42,3 % du poids moyen d’une page mobile selon le Web Almanac 2024 de HTTP Archive, et dans 72 à 81 % des sites, l’élément LCP est précisément une image (HTTP Archive, 2024 ; web.dev, 2024).


Formats d’image : quand utiliser WebP, AVIF ou JPG sur Shopify ?

Shopify convertit automatiquement tes images en WebP quand le navigateur le prend en charge, et ce depuis 2021 (Shopify.dev). Traduction : si tu uploades un JPG de 2 Mo, Shopify sert un WebP de ~600 Ko sans que tu touches à rien. Mais si tu uploades un PNG non optimisé, la conversion se fait quand même, sauf que tu pars d’un fichier source inutilement lourd.

AVIF n’est pas encore servi nativement par le CDN de Shopify à ce jour. Selon Can I Use, AVIF est pris en charge par 93,9 % des navigateurs début 2026 (Can I Use, 2025), mais Shopify ne le livre pas automatiquement dans la plupart des thèmes. Si tu le veux, il faut passer par des apps externes ou servir depuis un CDN propre, ce qui casse le pipeline standard.

Tableau comparatif : WebP vs AVIF vs JPG

FormatGain vs JPGSupport navigateursServi automatiquement par Shopify
JPG0 % (référence)100 % (Can I Use, 2025)Oui (source originale)
WebP~25 à 35 % plus léger (web.dev, 2024)97,5 % (Can I Use, 2025)Oui, depuis 2021
AVIF~50 % plus léger que JPG (web.dev, 2023)93,9 % (Can I Use, 2025)Non natif

L’erreur la plus fréquente que je vois : des marchands qui installent des apps « convertisseur WebP » sans savoir que Shopify le fait déjà. Résultat : double conversion, qualité dégradée et un coût mensuel qui n’apporte rien.

Que faire avec les PNG transparents ?

PNG reste le bon format pour les logos, icônes et toute image avec transparence nette. Shopify les convertit aussi en WebP sur les navigateurs modernes, mais si le fichier source pèse 1 Mo, le WebP résultant sera également lourd. Passe le PNG par TinyPNG ou Squoosh avant l’upload.


Le filtre image_url et image_tag en Liquid : responsive sans douleur

Shopify a remplacé l’ancien filtre img_url par image_url en 2022, et le nouveau helper image_tag génère automatiquement le srcset, sizes, loading et les attributs largeur/hauteur (Shopify.dev). Si ton thème utilise encore img_url, tu laisses sur la table l’optimisation la plus simple du stack.

Le pattern moderne est le suivant. Au lieu d’imposer une taille fixe, tu demandes au filtre une liste de largeurs et le navigateur choisit celle qu’il lui faut selon le viewport et la densité d’écran.

Snippet Liquid : hero responsive avec image_tag

{%- comment -%}
  Hero responsive con srcset generado automáticamente.
  Añade fetchpriority="high" solo en el LCP (normalmente el primer hero).
{%- endcomment -%}

{{ section.settings.hero_image | image_url: width: 2000
   | image_tag:
     loading: 'eager',
     fetchpriority: 'high',
     sizes: '100vw',
     widths: '400, 600, 800, 1200, 1600, 2000',
     alt: section.settings.hero_image.alt | default: section.settings.heading
}}

Ce bloc génère un <img> avec srcset complet, width et height automatiques (ce qui évite le CLS), loading="eager" et fetchpriority="high" puisque c’est le LCP. Ne le mets pas sur des images below-the-fold. Google indique explicitement qu’un fetchpriority="high" mal utilisé pénalise les performances (web.dev, 2023).

Snippet Liquid : carte produit en collection

{%- comment -%}
  Imagen de producto en grid de colección.
  Lazy por defecto, con aspect-ratio para prevenir CLS.
{%- endcomment -%}

<a href="{{ product.url }}" class="product-card">
  {{ product.featured_image | image_url: width: 600
     | image_tag:
       loading: 'lazy',
       sizes: '(min-width: 990px) 25vw, (min-width: 750px) 33vw, 50vw',
       widths: '200, 300, 400, 600, 800',
       alt: product.featured_image.alt | default: product.title
  }}
</a>

Les sizes doivent refléter ta grille réelle. Si ta collection affiche 4 colonnes en desktop, 3 en tablette et 2 en mobile, les breakpoints ci-dessus sont corrects. Sinon, ajuste-les. Passer sizes: '100vw' sur une petite vignette revient à télécharger une image énorme pour rien.


Lazy loading sur Shopify : natif ou Intersection Observer ?

L’attribut natif loading="lazy" est pris en charge par 95,7 % des navigateurs selon Can I Use (Can I Use, 2025). La règle est simple : une seule ligne de HTML remplace toute la logique Intersection Observer qu’on écrivait à la main avant. Utilise-le partout en dessous de la ligne de flottaison.

Attention à un anti-pattern très courant. Si tu poses loading="lazy" sur le hero ou sur la première image produit above-the-fold, tu détruis le LCP. La doc web.dev le signale comme erreur fréquente (web.dev, 2023). Règle : le LCP part en eager, tout le reste en lazy.

Quand as-tu vraiment besoin d’Intersection Observer ?

Rarement. Le cas utile, c’est quand tu veux retarder non pas juste l’image mais tout un bloc lourd (un carrousel JavaScript, une carte embarquée, une vidéo). Là, l’Observer permet aussi de reporter les scripts associés. Pour de simples images, loading="lazy" suffit.

Lors de l’audit cosmétique de 2026, il y avait une app de « lazy load avancé » installée. En la désactivant et en utilisant le loading="lazy" natif du thème Dawn, le LCP est passé de 3,8 s à 2,1 s sans rien toucher d’autre. Moins de code, meilleur résultat.


Alt text à grande échelle : le vrai problème avec 200 SKUs

Google et les lecteurs d’écran utilisent l’alt text pour comprendre le contenu visuel, et le guide officiel de Search Central le confirme comme signal SEO des images (Google Search Central). Le problème n’est pas conceptuel. Il est opérationnel : personne n’écrit à la main 800 alt texts pour 200 produits avec 4 images chacun.

Sur la marque de cosmétique 200+ SKUs auditée début 2026, 38 des 212 produits avaient un alt text totalement vide, et 94 autres avaient un alt identique au nom du fichier (IMG_2341.jpg). Ce n’est pas de l’alt text, c’est du bruit.

Comment générer des alt text en masse sans devenir fou ?

Trois tactiques qui marchent :

  1. Fallback intelligent en Liquid : si l’alt text manque, reprends le titre du produit comme valeur par défaut dans le thème. C’est déjà intégré dans les snippets ci-dessus avec | default: product.title.
  2. Export CSV depuis l’admin : Shopify permet d’exporter les produits avec leurs images. Tu édites les alt dans Excel ou Google Sheets et tu réimportes. C’est fastidieux mais ça passe à l’échelle.
  3. Apps d’alt text par IA : certaines apps (Alt Text AI, par exemple) génèrent un alt descriptif à partir du contenu visuel. Vérifie-les toujours, l’IA hallucine des descriptions.

L’alt text idéal en ecommerce est précis : « Sérum vitamine C 30 ml de Marque X en flacon ambré avec pipette », pas « sérum ». Spécifique, pas du keyword stuffing.


Que fait le CDN de Shopify et que ne fait-il pas ?

Le CDN de Shopify est opéré par Fastly et livre les assets depuis des points de présence mondiaux, selon la documentation officielle (Shopify.dev). Il fait quatre choses bien : conversion automatique en WebP, redimensionnement à la volée via le paramètre width de l’URL, cache agressif en edge et HTTPS en HTTP/2.

Mais il y a quatre choses qu’il ne fait pas. Il ne génère pas d’AVIF nativement. Il ne compresse pas agressivement les images sources que tu uploades (si tu envoies 2 Mo, il part de là). Il ne réorganise pas l’ordre de chargement et n’ajoute pas fetchpriority à ta place. Et il ne corrige pas tes sizes mal configurés. Le CDN amplifie ce que tu lui donnes : si tu lui donnes une base saine, il la sert vite ; si tu lui donnes un PNG de 5 Mo, il le livre aussi, mais c’est toi qui payes la note.

Comment savoir si le CDN sert bien du WebP ?

Ouvre les DevTools, onglet Network, filtre « Img ». Regarde la colonne Type ou le header Content-Type de la réponse. Si tu vois image/webp, le CDN fait son boulot. Si tu vois image/jpeg sur un navigateur moderne, c’est probablement que l’URL est codée en dur et court-circuite le filtre Liquid.


LCP et images hero : étude de cas sur une marque de cosmétique

72 à 81 % des éléments LCP sur le web sont des images, selon les analyses Google publiées sur web.dev (web.dev, 2024). Sur la marque de cosmétique 200+ SKUs auditée début 2026, le LCP mobile atteignait 4,2 s au 75ᵉ percentile, zone « Pauvre » selon les seuils officiels.

Le fichier hero d’origine était un JPG de 1,4 Mo, servi sans width passé au filtre Liquid (qui renvoyait donc la taille d’origine), avec loading="lazy" par erreur et sans fetchpriority. Quatre erreurs dans une seule balise.

Résultat après correctif, mesuré avec PageSpeed Insights sur les données de terrain CrUX :

  • LCP mobile : de 4,2 s à 2,0 s (baisse de 52 %)
  • Poids du hero : de 1,4 Mo à 180 Ko (WebP, width 1600, srcset complet)
  • Score Performance mobile : de 42 à 81
  • Classement Core Web Vitals : de « Pauvre » à « Bon »

Le correctif tient en trois changements. Un, réécrire la balise du hero avec image_tag, des widths responsive et fetchpriority="high". Deux, retirer le loading="lazy" du hero. Trois, supprimer une app de « speed optimization » qui injectait un preloader JS bloquant le rendu.


Quels outils j’utilise pour auditer les images sur Shopify ?

Google reconnaît officiellement les Core Web Vitals comme facteur de ranking et publie les seuils dans Search Central (Google Search Central). L’audit doit combiner données de laboratoire et données de terrain, jamais une seule source.

Les quatre outils que j’utilise à chaque audit

  1. Lighthouse (Chrome DevTools) : données de laboratoire. Parfait pour itérer vite quand tu touches au code. Ne reflète pas le vécu réel de tes utilisateurs.
  2. PageSpeed Insights : combine Lighthouse et les données CrUX (Chrome User Experience Report), des données de terrain réelles agrégées depuis Chrome (web.dev). C’est la source utilisée par Google pour le ranking.
  3. Search Console, Core Web Vitals : la vue agrégée au niveau URL, sur 28 jours. C’est là que tu vois les tendances et quelles URLs sont en zone rouge.
  4. Calibre ou SpeedCurve : monitoring continu. Utile seulement si tu es une marque à trafic sérieux qui veut des alertes quand quelque chose casse.

Quelle est la différence entre données de laboratoire et données de terrain ?

Les données de laboratoire (lab data) sont générées dans un environnement simulé et contrôlé (Lighthouse). Les données de terrain (field data, CrUX) viennent d’utilisateurs réels avec leurs réseaux, appareils et connexions réels. Google utilise les données de terrain pour le ranking. Si ton Lighthouse affiche 95 mais que ton CrUX donne un LCP de 4 s, c’est le CrUX qui compte.


Questions fréquentes

Shopify convertit-il automatiquement mes images en WebP ?

Oui. Depuis 2021, le CDN de Shopify sert automatiquement du WebP quand le navigateur de l’utilisateur le prend en charge, selon la documentation officielle (Shopify.dev). Pas besoin d’app externe pour ça. Ce qu’il faut faire, c’est uploader des fichiers sources déjà optimisés : la conversion réduit la taille, mais ne rattrape pas une image de 5 Mo mal exportée.

Dois-je mettre loading="lazy" sur toutes les images de ma boutique Shopify ?

Non. Selon le guide officiel de web.dev, poser loading="lazy" sur l’élément LCP dégrade les performances parce que ça retarde son téléchargement (web.dev, 2023). La règle : la première image visible part en loading="eager" avec fetchpriority="high". Tout ce qui est below-the-fold part en loading="lazy". Le support natif de l’attribut dépasse 95 % des navigateurs (Can I Use, 2025).

Quelle est la taille maximale pour une image produit sur Shopify ?

Ça dépend de l’affichage. Pour une image produit qui occupe tout l’écran en zoom, 2048 px de large suffisent. Shopify sert automatiquement des versions plus petites via srcset si tu utilises image_url avec widths. La règle générale de web.dev dit qu’aucune image servie à l’utilisateur ne devrait dépasser de plus de 30 % la taille qu’elle occupe réellement à l’écran (web.dev, 2024).

De combien le LCP s’améliore-t-il en passant de JPG à WebP sur Shopify ?

Ça dépend du point de départ. Le WebP pèse entre 25 % et 35 % de moins qu’un JPG équivalent à qualité visuelle comparable selon les mesures de web.dev (web.dev, 2024). Sur les boutiques où le LCP est une grosse image non optimisée, passer au WebP combiné à l’ajustement de width et du srcset peut faire baisser le LCP de 30 % à 50 %, comme dans le cas de la marque de cosmétique décrit plus haut.

Faut-il une app pour optimiser les images sur Shopify ?

En général, non. Le trio qui fait bouger l’aiguille, WebP automatique, image_tag avec srcset et loading="lazy" natif, est déjà intégré aux thèmes modernes comme Dawn (Shopify.dev). Les apps de « speed optimization » dupliquent souvent ce que la plateforme fait déjà et ajoutent du JavaScript qui dégrade les performances. Audite d’abord, installe ensuite.


Conclusion

Les images ne sont pas un sujet décoratif. Elles représentent 42,3 % du poids moyen d’une page mobile et, sur la plupart des boutiques Shopify, elles font la différence entre un LCP « Pauvre » et un LCP « Bon ». Bonne nouvelle : le stack de Shopify fait déjà la moitié du travail : conversion automatique en WebP, CDN rapide, image_tag avec srcset généré. L’autre moitié dépend de toi : uploader des fichiers déjà optimisés, utiliser image_tag plutôt que l’ancien img_url, poser loading="lazy" au bon endroit (et eager sur le LCP), et rédiger un alt text précis. Aucune de ces actions ne demande une app payante. Elles demandent de lire le thème, d’éditer du Liquid et de mesurer avant/après avec PageSpeed Insights et Search Console. Si tu veux qu’on regarde ta boutique ensemble, réserve un appel de 30 minutes et on passe tes Core Web Vitals au crible en direct.

Session de 30 min · Sans engagement

Lionel Fenestraz — Consultant Google Ads & Meta Ads Freelance
Lionel Fenestraz
Consultant PPC & CRO Freelance · Google Partner · CXL Certified · Google Ads Search Certified
Plus de 7 ans à gérer des campagnes Google Ads et Meta Ads pour des marques de location saisonnière, B2B et ecommerce. Trilingue ES/EN/FR.
Premier appel gratuit

Vos campagnes publicitaires
pourraient-elles mieux performer ?

30 minutes pour analyser votre situation et vous dire exactement ce que je changerais. Sans pitch, sans proposition commerciale.

Réserver un appel →
30 min · Google Meet · Sans engagement