Livrer images et vidéos dans le frontend headless : le guide pratique

Le choix du CDN est en général déjà fait au moment où vous lisez ces lignes. Le vrai travail se joue dans la livraison : le bon format selon le navigateur, des jeux de breakpoints qui collent à la mise en page réelle, un lazy-loading qui ne pénalise pas le LCP, et une mesure qui prouve que ça fonctionne. Ce guide entre dans le concret pour Shopware, commercetools et Shopify. Pas de comparatif de fournisseurs, uniquement de la mise en oeuvre.

Matrice de formats : AVIF, WebP, repli JPEG

Trois formats, trois rôles :

• AVIF offre la meilleure compression à qualité perçue équivalente, environ 30 à 50 pour cent plus léger qu'un WebP comparable (ordre de grandeur, pas une garantie, cela dépend du contenu de l'image). Pris en charge par Chrome, Firefox, Edge récents et Safari à partir de la version 16.4.
• WebP reste le repli large, pris en charge depuis des années par tous les navigateurs pertinents, y compris les versions de Safari antérieures à 16.4.
• JPEG demeure le dernier recours pour les clients e-mail, les outils d'export PDF ou les anciens robots qui ne comprennent ni AVIF ni WebP.

En pratique, cela donne un élément <picture> avec trois sources, le navigateur choisissant lui-même :

<picture>
  <source type="image/avif" srcset="/img/sneaker-p-400.avif 400w, /img/sneaker-p-800.avif 800w, /img/sneaker-p-1200.avif 1200w">
  <source type="image/webp" srcset="/img/sneaker-p-400.webp 400w, /img/sneaker-p-800.webp 800w, /img/sneaker-p-1200.webp 1200w">
  <img src="/img/sneaker-p-800.jpg" srcset="/img/sneaker-p-400.jpg 400w, /img/sneaker-p-800.jpg 800w, /img/sneaker-p-1200.jpg 1200w"
       sizes="(min-width: 992px) 660px, 100vw" width="800" height="800" loading="lazy" decoding="async"
       alt="Détail produit sneaker, vue de côté">
</picture>

width/height sont obligatoires même quand srcset propose des largeurs variables : ils réservent l'espace dans la mise en page et évitent le CLS pendant le chargement.

srcset et sizes alignés sur le vrai breakpoint

L'échelle habituelle copiée-collée (320, 640, 960, 1280, 1920) ignore la largeur réellement affichée de l'image. Trois frontends, trois réponses différentes :

• Shopware (thème Storefront construit sur Bootstrap, breakpoints à 576/768/992/1200/1400px) : la galerie de la fiche produit s'affiche pleine largeur du conteneur sous 768px, puis en deux colonnes autour de 660px au-delà de 992px. Largeurs pertinentes : 400, 660, 900, 1200, pas l'échelle générique.
• Frontends commercetools (souvent Next.js avec les breakpoints Tailwind par défaut, 640/768/1024/1280px) : la grille de listing affiche 2 colonnes sur mobile, 3 sur tablette, 4 à partir de 1280px. Avec 4 colonnes et les marges, une vignette individuelle se rend autour de 280px, environ 340px sur mobile. Largeurs à prévoir : 280, 340, 560 (variante 2x pour les écrans haute densité).
• Shopify (thèmes Dawn/Hydrogen, largeur de contenu maximale typique de 1600px) : le hero de catégorie est en pleine largeur (sizes="100vw"), mais n'a pas besoin de dépasser 3200px même sur un écran 4K, la largeur de contenu étant plafonnée. Au-delà, c'est du transfert gaspillé.

En résumé : sizes doit décrire la largeur réellement rendue à chaque breakpoint, pas la largeur du viewport. Mettre sizes="100vw" partout alors que l'image occupe une seule colonne de grille conduit à systématiquement sur-livrer.

Pour la mise en oeuvre elle-même, https://www.laioutr.com/fr/cloud/image-cdn est l'endroit où définir les jeux de largeurs par mise en page, plutôt que de les coder en dur dans le template.

loading et fetchpriority : quand le lazy-loading nuit au LCP

loading="lazy" est devenu la valeur par défaut, souvent appliquée globalement dans le composant image partagé du framework. C'est exactement le mauvais réglage pour une image : le candidat LCP, en général le bandeau hero ou l'image principale de la fiche produit.

Deux symptômes fréquents :

1. Le composant image applique loading="lazy" indépendamment de la position dans le viewport. L'image LCP n'est alors demandée qu'après la vérification d'intersection, pas dès l'analyse du HTML initial.
2. L'image est placée derrière data-src plutôt que src parce qu'une librairie JS de lazy-loading gère la résolution. Le scanner de préchargement du navigateur ne peut alors pas la détecter tôt, même si elle est visible sans défilement.

Pour le candidat LCP :

<img src="/img/hero-1200.avif" fetchpriority="high" loading="eager" decoding="async"
     width="1200" height="630" alt="Bandeau catégorie collection été">

Ajoutez un <link rel="preload" as="image"> dans le <head> si l'asset n'est attaché que via un fond CSS ou une hydratation JS. Tout ce qui se trouve sous le premier viewport reste en loading="lazy", où cela fait réellement économiser des octets.

Vidéo : images d'aperçu, stratégie de préchargement, débit adaptatif

Les éléments vidéo demandent la même discipline au-dessus de la ligne de flottaison que les images :

• Image d'aperçu (poster) : une image fixe AVIF/WebP (extraite de la première seconde via ffmpeg), qui réserve l'espace et évite le CLS pendant le chargement de la vidéo.
• Préchargement : preload="none" par défaut pour une vidéo sous la ligne de flottaison, preload="metadata" pour une vidéo visible d'emblée (charge uniquement la durée et les dimensions, pas le flux complet), preload="auto" réservé aux très courtes boucles de moins de 2 Mo.
• Débit adaptatif : pour les vidéos hero, servir un manifeste HLS (.m3u8) avec plusieurs qualités (par exemple 360p/720p/1080p) plutôt qu'un unique MP4 fixe. Le lecteur choisit selon le débit mesuré, au lieu d'imposer la qualité desktop à toutes les connexions.

<video poster="/img/hero-poster.avif" preload="metadata" playsinline muted loop width="1200" height="630">
  <source src="/video/hero.m3u8" type="application/x-mpegURL">
  <source src="/video/hero-720p.mp4" type="video/mp4">
</video>

Comme le montre core-web-vitals-image-video-delivery-lcp-storefront-2026, c'est souvent l'image d'aperçu qui est le véritable candidat LCP, pas la vidéo elle-même, tant que le flux n'est pas prêt.

Mesurer : LCP, CLS, octets transférés

Trois points de mesure, trois outils :

• LCP : données de terrain via la librairie JS web-vitals (callback onLCP) ou le Chrome UX Report. Seuils Google : bon à ≤ 2,5s (75e percentile), à améliorer jusqu'à 4s, médiocre au-delà.
• CLS : callback onCLS, bon à ≤ 0,1. Réserver width/height sur chaque image et vidéo reste le levier principal.
• Octets transférés : panneau réseau des DevTools Chrome filtré sur img/media, ou le résumé des ressources Lighthouse. Exemple de calcul : une fiche produit avec 8 images produit d'environ 120 Ko chacune (AVIF, largeur 800px) au lieu de 8 x 350 Ko (JPEG non compressé en taille d'origine) fait passer le transfert d'images d'environ 2,8 Mo à environ 960 Ko, un exemple d'ordre de grandeur, pas une valeur garantie pour chaque catalogue.

L'article what-is-an-image-cdn-2026 couvre les fondamentaux du CDN d'images ; ce guide reprend là où commence la mise en oeuvre côté frontend.

Autres ressources de la plateforme Laioutr

• Image CDN
• Video CDN
• Composable Headless Frontend

FAQ

Dois-je générer l'AVIF moi-même ? Non, un CDN d'images gère la conversion de format à la volée selon l'en-tête Accept. Le storefront ne livre le fichier source qu'une seule fois.

De combien de breakpoints ai-je vraiment besoin ? En général 3 à 5, alignés sur les vrais breakpoints CSS du thème, pas sur des classes d'appareils.

Prochaines étapes

Pour appliquer la matrice de formats et la logique de breakpoints sur votre propre storefront : Composable Headless Frontend montre comment le CDN image et vidéo s'intègrent dans la couche frontend de Laioutr.

À propos de l'auteur : Marcel Thiesies est Co-Founder de Laioutr et responsable du produit et de l'architecture de la Frontend Management Platform.