Guide d'optimisation d'images mobiles pour des pages plus rapides

Mis à jour le : June 28, 2026

L'optimisation des images mobiles commence par une contrainte : un téléphone ne doit pas télécharger de pixels qu'il ne peut afficher. Redimensionnez la source, servez des variantes adaptatives, gardez la plus grande image au-dessus du pli hors du lazy loading, et publiez des fichiers WebP ou AVIF consultables via un CDN.

Réponse rapide : comment optimiser les images pour le mobile ?

Utilisez cet ordre : redimensionner en premier, encoder en second, livrer en troisième, mesurer en dernier. Une photo produit de 4000 px affichée à 390 px de large est un gaspillage même si elle est compressée. Le navigateur doit toujours la récupérer, la décoder et l'adapter avant que la page ne soit considérée comme prête.

Pour la plupart des pages mobiles, diffusez un ensemble de sources WebP ou AVIF avec des largeurs autour de 400, 800 et 1200 px. Conservez une sauvegarde JPEG si votre public comprend d'anciens navigateurs, des clients de messagerie ou des flux partenaires. Pour une décision de format plus approfondie, utilisez la comparaison AVIF vs WebP.

Les directives LCP de Google stipulent que les pages doivent viser un Largest Contentful Paint à 2,5 secondes ou moins au 75e centile, ventilé par mobile et bureau. Les images sont souvent l'élément LCP, donc l'image principale mérite une attention particulière : préchargez-la ou donnez-lui la priorité, définissez des dimensions réelles et ne la lazy-loadez pas.

Ce qui change réellement sur un téléphone ?

Un téléphone modifie trois choses à la fois : la largeur du viewport, la qualité du réseau et la densité de mise en page. Les images de bureau échouent souvent sur mobile car la page conserve le même asset de 1600 px, rogne mal le sujet ou retarde l'image principale derrière JavaScript.

J'ai généré un graphique source de 1600 x 1000 et l'ai encodé en WebP q82 à trois largeurs. Le résultat montre pourquoi le redimensionnement bat les ajustements de qualité :

Ces chiffres sont illustratifs, pas universels. Une photo détaillée sera plus grande que ce graphique épuré, et un logo plat sera plus petit. La règle utile est stable : faire en sorte que le navigateur choisisse parmi des candidats de largeur réels au lieu d'un fichier trop grand.

Quelles tailles d'images mobiles devriez-vous créer ?

Commencez par l'emplacement rendu, pas par le fichier caméra. Inspectez votre modèle aux points de rupture courants et enregistrez la largeur CSS maximale pour chaque type d'image.

Utilisez des descripteurs de largeur lorsque la largeur de mise en page change :

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Bouteille d'eau réutilisable sur un comptoir de cuisine"
>

Le [guide des images adaptatives] de MDN explique le modèle de sélection srcset et sizes. La version courte : srcset liste les candidats, et sizes indique au navigateur quelle sera la largeur de l'emplacement rendu avant que la mise en page ne soit terminée.

Pour un flux de travail par lots, générez des largeurs à partir du même fichier maître. Le [guide de redimensionnement par lots] couvre le modèle ligne de commande, et la [plongée dans la compression d'images] explique pourquoi le redimensionnement doit avoir lieu avant la compression finale.

Quand devriez-vous utiliser picture pour les recadrages mobiles ?

Utilisez <picture> lorsque l'image mobile nécessite un recadrage différent, pas seulement un fichier plus petit. Une image principale de bureau large peut devenir inutile sur un téléphone si le sujet est situé à l'extrême gauche ou que la zone de texte couvre le produit.

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Chaussure de trail running avec la semelle visible"
  >
</picture>

Utilisez l'art direction pour :

1. Les images principales de produits où le produit devient minuscule sur mobile.
2. Les bannières éditoriales où un visage ou un objet doit rester centré.
3. Les listes de marché qui nécessitent des vignettes carrées et des images détaillées larges.
4. Les images avant/après où les deux côtés doivent rester lisibles.
5. Les captures d'écran avec un petit texte qui nécessite un recadrage plus serré.

N'utilisez pas <picture> comme substitut aux largeurs adaptatives normales. Si la composition est la même, srcset plus sizes est plus simple.

Comment WebP, AVIF et JPEG s'intègrent-ils dans les performances mobiles ?

Utilisez WebP comme format mobile de base lorsque vous avez besoin d'un fichier moderne qui fonctionne largement. Utilisez AVIF lorsque votre pipeline peut le générer et que vous pouvez conserver une sauvegarde WebP ou JPEG. Gardez JPEG pour les e-mails, les anciens systèmes partenaires et les archives sources que d'autres outils doivent ouvrir.

La liste de contrôle complète d'optimisation d'images couvre la séquence de publication plus large. Si vous devez comparer des outils qui produisent WebP et AVIF, consultez alternatives à TinyPNG.

Utilisez une pile <picture> lorsque vous pouvez :

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Mug en céramique bleu à côté d'un carnet de notes">
</picture>

Comment le lazy loading doit-il fonctionner sur mobile ?

Lazy-loadez les images qui commencent sous le premier viewport. Ne pas lazy-loader l'image LCP. Le lazy loading au niveau du navigateur est utile, mais ce n'est pas un plan de performance en soi.

Le [guide de lazy loading au niveau du navigateur] de Google recommande loading="lazy" natif pour les images hors écran. Les mêmes directives mettent en garde contre le lazy-loading des images immédiatement visibles car cela peut retarder le contenu que les utilisateurs attendent.

Utilisez cette liste de contrôle :

1. Donnez à l'image principale (hero) loading="eager" ou omettez loading.
2. Ajoutez fetchpriority="high" à l'image LCP la plus probable.
3. Ajoutez loading="lazy" aux images après le premier écran.
4. Définissez width et height sur chaque image.
5. Utilisez CSS aspect-ratio lorsque le ratio rendu change par point de rupture.
6. Évitez l'injection d'images uniquement via JavaScript pour l'image principale.
7. Vérifiez que les URL d'images CDN incluent des en-têtes de cache longs.
8. Testez sur un profil mobile limité, pas seulement sur Wi-Fi de bureau.
9. Surveillez l'élément LCP dans PageSpeed Insights.
10. Relancez après des changements de conception, car l'élément LCP peut changer.

La [documentation LCP] de Google liste les éléments d'image, les posters vidéo et les images de fond parmi les candidats LCP possibles. C'est pourquoi une image principale de fond peut toujours nuire au LCP même si ce n'est pas un <img>.

Que devrait faire un CDN d'images pour le mobile ?

Un CDN d'images doit supprimer le travail manuel répétitif : redimensionner en périphérie, négocier le format, mettre en cache les variantes et maintenir des URL publiques stables. Le CDN ne remplace pas l'hygiène de la source. Télécharger une photo produit floue de 900 px vers un CDN d'images ne créera pas de vrais détails de 1600 px.

Recherchez ces contrôles :

• Transformations de largeur pour les emplacements mobiles et de bureau courants.
• Sortie WebP et AVIF avec le Content-Type correct.
• Clés de cache qui incluent la largeur, la qualité et le format.
• Un moyen de préserver les téléchargements originaux séparément des dérivés publics.
• Des URL publiques stables que Google Images peut explorer.
• Une surveillance des 404 après déploiement et migration.

Pour le SEO, les meilleures pratiques SEO pour images de Google mettent l'accent sur des images utiles et visibles près du texte pertinent, des noms de fichiers et des textes alt descriptifs, et des URL d'images consultables. Une URL CDN est acceptable lorsqu'elle est indexable, stable et référencée depuis la page.

Que devriez-vous tester avant de publier ?

Testez la page comme un visiteur mobile le reçoit. Une seule exécution Lighthouse propre est utile, mais elle peut masquer les manques du CDN, les candidats adaptatifs trop grands et les changements de mise en page qui n'apparaissent que dans des modèles réels.

Une commande pratique pour un audit local :

curl -I https://cdn.example.com/images/product-card-480.webp

Puis vérifiez la page rendue sur un viewport étroit. Si un tableau ou une image déborde de l'écran, corrigez la mise en page avant de célébrer les économies d'octets.

Liste de contrôle SEO des images mobiles et GEO

Les moteurs de recherche et les moteurs de réponses ont besoin de ce que veut un humain : un contexte direct. Ne pas enterrer les images dans un carrousel sans explication proche et s'attendre à ce que l'asset porte lui-même un sens.

Avant de publier, confirmez :

1. La page a une réponse claire près du haut.
2. Chaque image importante possède un texte alt descriptif.
3. Les noms de fichiers décrivent le sujet visible, pas IMG_9021.
4. L'URL de l'image est consultable sans cookies.
5. Le paragraphe environnant explique pourquoi l'image est présente.
6. L'image principale mobile n'est pas plus grande que ce dont l'emplacement rendu a besoin.
7. Les images de corps utilisent loading="lazy" uniquement lorsqu'elles sont en dessous du premier viewport.
8. Les tableaux résument des décisions qu'un lecteur peut réutiliser.
9. Les affirmations externes renvoient à des sources faisant autorité.
10. Les liens internes pointent vers le prochain flux de travail réel, pas un cluster page aléatoire.

Pour le passage spécifique au SEO après compression, utilisez la liste de contrôle d'optimisation SEO pour images. Pour le travail sur fichiers ponctuels, Image Compressor, Image Converter et Image Resizer couvrent les étapes manuelles courantes.

Crédits des images

• La couverture, le graphique de largeur adaptative, le recadrage par art direction et le graphique de priorité de chargement ont été générés pour cet article avec ImageMagick et exportés en WebP. Le graphique de largeur adaptative utilise la sortie mesurée WebP q82 du même graphique source 1600 x 1000.