Développement

Comment optimiser les assets images et vidéos pour next.js afin de gagner 40% de performance perçue sur mobile

Comment optimiser les assets images et vidéos pour next.js afin de gagner 40% de performance perçue sur mobile

Sur Esmertec, j’ai testé pas mal de techniques pour améliorer la performance perçue sur mobile — et l’optimisation des assets images et vidéos est souvent le levier le plus rentable. Dans plusieurs projets Next.js, en combinant des bonnes pratiques d’images (formats modernes, lazy-loading adapté, responsive sizes) et une stratégie vidéo allégée, j’ai observé jusqu’à 40% d’amélioration de la performance perçue sur des appareils mobiles courants. Dans cet article je partage mon approche concrète, les erreurs courantes à éviter et les étapes actionnables que vous pouvez appliquer tout de suite.

Pourquoi optimiser images et vidéos d’abord ?

Sur mobile, la majorité du temps de chargement et de rendu est consommée par les ressources multimédias. Une image trop lourde ou une vidéo non adaptée bloque le rendu initial, augmente le LCP (Largest Contentful Paint) et dégrade la sensation de fluidité. Plutôt que d’optimiser d’abord le JavaScript, je priorise les assets parce qu’ils impactent directement la perception utilisateur — ce que Google Page Experience et Core Web Vitals mesurent précisément.

Les principes que j’applique systématiquement

  • Servir des formats modernes : AVIF ou WebP plutôt que JPG/PNG quand c’est possible.
  • Adapter la taille à l’écran : images responsives via srcset/sizes ou le composant Image de Next.js.
  • Lazy-loading intelligent : différer les images hors écran mais prioriser celles above-the-fold.
  • Compression équilibrée : réduire le poids sans perdre trop de qualité perçue.
  • Optimiser les vidéos : formats et bitrates adaptés, poster images, chargement progressif et remplacement par GIF/animation légère si nécessaire.
  • Configurer Next.js Image pour de vrais gains

    J’utilise le composant next/image comme point de départ. Il apporte automatiquement le lazy-loading, le responsive et l’optimisation côté serveur si vous utilisez l’Image Optimization API de Next.js. Voici les points clefs à vérifier :

  • Définir correctement width et height pour éviter le layout shift (CLS).
  • Utiliser priority pour les images above-the-fold critiques (logo, hero).
  • Configurer sizes pour que le navigateur choisisse la source la plus adaptée aux breakpoints.
  • Préférer un loader externe (Cloudinary, Imgix, Akamai, ou le propre optimisateur Next.js) pour des transformations on-the-fly et des formats modernes.
  • Exemple de pratique que j’applique : je fournis toujours des tailles cibles dans les props du composant Image et j’ajoute une version AVIF générée par CDN pour les navigateurs qui la supportent. Résultat : la taille moyenne des images peut chuter de 60–80% selon la source initiale.

    Formats d’image : quand utiliser AVIF, WebP, PNG ou SVG

    Le choix du format dépend du type d’image :

  • AVIF : excellent pour les photos, compression très élevée, idéal quand le CDN peut en servir.
  • WebP : très bon compromis de support et performance.
  • PNG : réservé aux images nécessitant de la transparence sans dégradé photo (logos complexes), mais souvent converti en WebP/AVIF pour la livraison.
  • SVG : parfait pour les icônes et illustrations vectorielles, petit poids et rendu parfait sur tous les écrans.
  • Astuce pratique : générez automatiquement AVIF/WebP au build ou via votre CDN, mais gardez une fallback pour les navigateurs anciens. Avec Next.js, on peut déléguer la conversion à un service (Cloudinary, ImageKit) et combiner cela avec un CDN pour latence minimale.

    Responsive et breakpoints — arrêter les images surdimensionnées

    Une erreur fréquente : servir une image desktop 2000px à un mobile 360px. Pour lutter contre ça, je définis un système de breakpoints cohérent et j’utilise srcset ou les props sizes de Next Image. Exemple de stratégie :

  • XS (<= 480px) : max 720px
  • SM (481–768px) : max 1024px
  • MD (769–1024px) : max 1440px
  • LG (>1024px) : max 2048px
  • En pratique, cela signifie que le navigateur ne télécharge que la version réellement utile, réduisant la consommation data et accélérant le rendu initial.

    Lazy-loading : plus intelligent que “toutes les images en lazy”

    Le lazy-loading natif (loading="lazy") est utile, mais il ne suffit pas. J’applique ces règles :

  • Images critiques (hero, éléments above-the-fold) : no lazy ou priority dans next/image.
  • Images de contenu long : lazy-loading avec un seuil (intersection observer rootMargin) pour précharger juste avant que l’utilisateur ne scroll.
  • Remplacer les placeholders lourds par des tiny placeholders : tiny transparent SVG ou base64 tiny blurred placeholder (LQIP) généré automatiquement.
  • Le placeholder flou (blur-up) donne un rendu perçu plus rapide : l’utilisateur voit déjà une forme approximative pendant que le fichier final se charge. C’est un petit détail qui améliore énormément la perception.

    Optimiser les vidéos pour mobile

    Les vidéos sont souvent le pire cauchemar côté poids. Voici les pratiques que j’implémente :

  • Utiliser des formats modernes : MP4 (H.264/AVC) pour compatibilité, mais envisager AV1 pour les navigateurs qui le supportent.
  • Balancer qualité/bitrate : pour mobile, je cible des bitrates bas (200–500 kbps) pour les vidéos de fond ou les thumbnails animés.
  • Poster image : fournissez une image statique optimisée pour éviter le chargement initial de la vidéo.
  • Lecture à la demande : ne pas précharger les vidéos (preload="none") sauf si nécessaire.
  • Utiliser des mini-captures (sprite) ou GIFs optimisés pour de courtes animations, mais converties ensuite en vidéos condensées si l’usage dépasse quelques secondes.
  • En résumé : évitez que la vidéo bloque le LCP et préférez des chargements déclenchés par l’utilisateur ou par le viewport.

    Mise en cache et CDN — des alliés incontournables

    Rien ne remplace un bon CDN pour livrer rapidement les assets sur mobile. Mes conseils :

  • Mettre en place des headers Cache-Control longs pour les assets immuables (images avec hashed filenames).
  • Utiliser un CDN qui gère transformations d’images (Cloudinary, Imgix, Fastly Image Optimizer, Vercel Image CDN).
  • Edge caching et HTTP/2 ou HTTP/3 pour multiplexing des requêtes.
  • En pratique, déployer vos images via CDN + conversion automatique en formats modernes réduit sensiblement le TTFB et la latence de chargement.

    Métriques à suivre pour mesurer l’impact

    Pour justifier les changements, je surveille :

  • LCP (Largest Contentful Paint)
  • FID/INP (interaction)
  • CLS (Cumulative Layout Shift)
  • First Contentful Paint (FCP)
  • Taille moyenne des assets par page
  • Sur plusieurs projets où j’ai appliqué ces optimisations, le LCP mobile est passé de ~3.5–4.5s à ~1.8–2.5s, et la mesure perçue (via WebPageTest filmstrip + Lighthouse) a montré des gains de 30–40% en vitesse perçue. Ces gains se traduisent aussi par une meilleure rétention et taux de conversion.

    Checklist rapide à appliquer dès maintenant

  • Activer next/image et vérifier props width/height + priority pour le hero.
  • Configurer votre CDN pour générer AVIF/WebP et servir automatiquement le meilleur format.
  • Déployer placeholders flous LQIP pour les images principales.
  • Mettre en place lazy-loading intelligent avec intersection observer rootMargin.
  • Réduire les bitrates vidéos pour mobile et utiliser preload="none".
  • Ajouter cache-control long et filenames horodatés/hachés.
  • Si vous voulez, je peux regarder un cas concret de votre site Next.js et vous fournir une liste d’actions priorisées (ce que j’ai fait pour plusieurs lecteurs d’Esmertec avec des résultats rapides). Dites-moi l’URL et je vous envoie un diagnostic rapide.

    Vous devriez également consulter les actualités suivante :