Commencez votre essai gratuit de 7 joursAucune carte bancaire requise

Performance

Optimiser les images pour le web : WebP, AVIF et taille

Choisissez le bon format, la bonne taille et la bonne stratégie de chargement pour vos images, et comprenez ce que WebP et AVIF changent vraiment.

8 min de lecture

Pour optimiser les images pour le web, servez chaque image dans un format moderne (WebP ou AVIF, avec une solution de repli), à la taille en pixels à laquelle elle est réellement affichée, avec une compression raisonnable, et chargez-la au bon moment : tôt pour l’image principale, en différé pour tout ce qui se trouve sous la ligne de flottaison. Si vous maîtrisez ces quatre points, les images cessent d’être la partie la plus lourde de vos pages. Ce guide détaille chaque étape, ce que WebP et AVIF changent vraiment et comment vérifier le résultat.

Pourquoi les images comptent pour la vitesse

Sur de nombreux sites de contenu et boutiques en ligne, les images représentent la plus grande part des octets téléchargés par une page. Elles déterminent aussi l’un des trois Core Web Vitals : sur beaucoup de pages, l’élément du Largest Contentful Paint est une image, généralement une bannière hero ou une photo produit. L’article sur le LCP de web.dev (en anglais) cite le temps de téléchargement de l’image parmi les quatre composantes de cette métrique.

Les images influencent aussi la stabilité de la mise en page. Une image sans espace réservé pousse le texte vers le bas en arrivant, ce qui pèse sur le Cumulative Layout Shift. Pour une vue d’ensemble de l’interaction entre ces métriques, lisez Core Web Vitals expliqués.

La bonne nouvelle : les problèmes d’images sont généralement faciles à repérer et à corriger, et les corrections ne touchent pas à la logique de votre application.

Choisir le bon format

Chaque format a son rôle. Choisir le mauvais est une cause fréquente de fichiers surdimensionnés.

FormatIdéal pourTransparenceRemarques
JPEGPhotosNonCompatible partout, bonne base
PNGCaptures d’écran, graphismes aux contours nets, transparenceOuiSans perte, souvent très lourd pour les photos
WebPPhotos et graphismesOuiPris en charge par tous les grands navigateurs actuels, généralement plus léger que JPEG ou PNG à qualité comparable
AVIFPhotos et graphismesOuiSouvent plus léger que WebP à qualité comparable, plus lent à encoder, pris en charge par les grands navigateurs actuels
SVGLogos, icônes, illustrations simplesOuiVectoriel, s’adapte à toutes les tailles, minuscule pour les formes simples

Quelques règles pratiques :

  • N’utilisez jamais le PNG pour des photos. Une photo enregistrée en PNG est souvent bien plus lourde que la même photo en JPEG, sans aucun bénéfice visible.
  • Utilisez le SVG pour les logos et les icônes plutôt que des sprites PNG. Assurez-vous que vos SVG proviennent d’une source fiable, car ils peuvent contenir des scripts.
  • Remplacez les GIF animés par de la vidéo. Une courte boucle en MP4 ou WebM est bien plus légère que la même animation en GIF.

Ce que WebP et AVIF changent vraiment

WebP et AVIF sont des formats de compression plus récents. À qualité visuelle égale, ils produisent généralement des fichiers plus légers que JPEG et PNG, et AVIF va souvent plus loin que WebP, surtout sur les photos aux dégradés doux. Le gain dépend de l’image et du réglage de qualité : il n’existe donc pas de chiffre universel fiable.

Ce qu’ils ne changent pas : les dimensions en pixels. Un AVIF de 4000 pixels de large affiché dans une colonne de 600 pixels reste du gaspillage. Le format et les dimensions sont deux problèmes distincts, et il faut résoudre les deux.

Les navigateurs anciens qui ne comprennent pas un format ont besoin d’une solution de repli. Vous pouvez la gérer dans le balisage avec <picture>, ou côté serveur en examinant l’en-tête Accept du navigateur et en choisissant le format à chaque requête.

<picture>
  <source srcset="/images/team.avif" type="image/avif">
  <source srcset="/images/team.webp" type="image/webp">
  <img src="/images/team.jpg" alt="Notre équipe au bureau" width="1200" height="800">
</picture>

Servir la bonne taille

Téléverser une photo directement depuis un appareil photo ou un téléphone et laisser le CSS la réduire est l’erreur classique. Le navigateur télécharge quand même chaque pixel.

Redimensionner à la taille d’affichage

Déterminez la largeur à laquelle l’image est réellement affichée. Sur une mise en page desktop avec une colonne de contenu de 1200 pixels, une image pleine largeur a rarement besoin de dépasser environ le double de cette valeur pour rester nette sur les écrans haute densité. Les vignettes d’une grille de produits en demandent bien moins.

Utiliser srcset et sizes

Les images responsives permettent au navigateur de choisir le bon fichier pour chaque écran :

<img
  src="/images/product-800.jpg"
  srcset="/images/product-400.jpg 400w,
          /images/product-800.jpg 800w,
          /images/product-1600.jpg 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  alt="Chaussure de course bleue, vue de profil"
  width="800" height="800">

srcset liste les largeurs disponibles, et sizes indique au navigateur la largeur qu’aura l’image dans la mise en page. Le navigateur combine ces informations avec la densité de pixels de l’écran et ne télécharge qu’un seul fichier. La plupart des CMS, WordPress compris, génèrent plusieurs tailles au téléversement et produisent automatiquement le srcset, à condition que le thème utilise les fonctions d’image standard.

Compresser raisonnablement

Pour les formats avec perte, un réglage de qualité situé entre le milieu et le haut de l’échelle est généralement impossible à distinguer de l’original à une taille d’affichage normale. Comparez quelques réglages côte à côte sur un vrai écran plutôt que de vous fier à une seule valeur par défaut. Supprimez aussi les métadonnées comme les données EXIF de l’appareil photo, qui ajoutent des octets et peuvent révéler des informations de localisation que vous n’aviez pas l’intention de publier.

Charger les images au bon moment

Toutes les images ne sont pas aussi urgentes. Le navigateur doit récupérer immédiatement celle qui se trouve au-dessus de la ligne de flottaison et laisser les autres jusqu’à ce que le visiteur fasse défiler la page.

Charger en différé les images sous la ligne de flottaison

Le chargement différé natif ne nécessite aucun JavaScript :

<img src="/images/gallery-3.webp" loading="lazy" alt="..." width="600" height="400">

Ne jamais charger l’image LCP en différé

C’est l’erreur qui annule tout le reste. Si l’image hero porte loading="lazy", le navigateur attend volontairement avant de la récupérer, et le LCP se dégrade. Certaines extensions et certains thèmes chargent toutes les images en différé par défaut : vérifiez donc spécifiquement l’image hero.

Éviter les décalages de mise en page

Donnez toujours aux images des attributs width et height (ou un aspect-ratio en CSS). Les navigateurs modernes s’en servent pour réserver la bonne quantité d’espace avant l’arrivée du fichier, même quand le CSS rend l’image responsive avec width: 100%; height: auto. L’article sur le CLS de web.dev (en anglais) explique pourquoi les images sans dimensions sont l’une des causes les plus fréquentes de décalage de mise en page.

Il en va de même pour les images injectées plus tard, comme les carrousels ou les emplacements publicitaires : réservez leur espace en CSS pour que le reste de la page ne saute pas.

Bien mettre les images en cache

Les images changent rarement : les navigateurs et les CDN doivent donc les conserver longtemps. Envoyez des en-têtes Cache-Control de longue durée et changez le nom du fichier (ou ajoutez un paramètre de version) quand vous remplacez une image. Vous pouvez vérifier ce qu’envoie votre serveur :

curl -I https://www.example.com/images/hero.webp

Cherchez cache-control avec un max-age élevé. Si vous servez des formats différents depuis la même URL selon le navigateur, la réponse doit aussi varier en fonction de l’en-tête Accept, faute de quoi un cache pourrait livrer un fichier WebP à un navigateur incapable de l’afficher.

Comment fast.site vous aide

fast.site se place devant votre hébergement existant : vos images restent où elles sont et votre CMS continue de fonctionner comme avant. Vous faites pointer les serveurs de noms de votre domaine vers fast.site, et les requêtes passent dès lors par son réseau edge.

L’optimisation des images convertit à la volée les JPEG et PNG en WebP pour les navigateurs compatibles, et le transcodage en AVIF est disponible selon votre offre. Les navigateurs qui ne prennent pas en charge un format reçoivent l’original : vous n’avez donc pas à maintenir des solutions de repli <picture> pour chaque image. Comme les autres fichiers statiques, les images sont mises en cache par Fast Edge Cache™ : un cache HIT est servi depuis l’edge le plus proche du visiteur, sans contacter votre serveur.

L’option d’optimisation HTML précharge l’image hero détectée et ajoute la largeur et la hauteur aux images pour limiter les décalages de mise en page.

Ce que fast.site ne fait pas : redimensionner les fichiers téléversés trop grands ou décider quelles images charger en différé. Cela reste du ressort de votre thème et de votre processus de gestion des contenus.

Mesurez l’effet sur votre propre site avant et après : comparez le volume d’images transféré dans le panneau réseau du navigateur et vérifiez le LCP sur corewebvitals.page. Vous pouvez l’essayer avec un essai gratuit de 7 jours, sans carte bancaire. Consultez les offres pour voir ce que chacune inclut.

Questions fréquentes

Vaut-il mieux utiliser WebP ou AVIF ?

AVIF produit souvent des fichiers plus légers que WebP à qualité comparable, en particulier pour les photos, mais son encodage prend plus de temps. WebP est un choix par défaut sûr, largement pris en charge. De nombreux sites servent de l’AVIF quand c’est possible et du WebP ou l’original en solution de repli.

Quelle taille doivent faire les images d’un site web ?

Alignez-vous sur la plus grande taille à laquelle l’image est affichée, et prévoyez environ le double de cette largeur pour les écrans haute densité. Utilisez srcset pour que les petits écrans téléchargent des fichiers plus petits. Téléverser la pleine résolution de l’appareil photo n’est presque jamais nécessaire.

Le chargement différé nuit-il au SEO ?

Le chargement différé natif avec loading="lazy" est pris en charge par Google et ne cache pas les images aux moteurs de recherche. Le vrai risque concerne la performance : charger en différé l’image principale au-dessus de la ligne de flottaison retarde le LCP. Réservez-le aux images situées plus bas dans la page.

Comment vérifier si mes images sont optimisées ?

Passez la page dans corewebvitals.page et vérifiez le LCP sur mobile et sur desktop. Pour savoir quel élément constitue l’élément LCP, ouvrez le panneau Performance des Chrome DevTools. Dans le panneau réseau du navigateur, filtrez sur les images et comparez les tailles et formats des fichiers. Notre guide pour mesurer la vitesse d’un site montre comment mener un test avant/après fiable.

Ai-je encore besoin d’une extension d’optimisation d’images sur WordPress ?

Cela dépend de votre configuration. Une extension qui redimensionne et compresse les fichiers téléversés reste utile, car la conversion de format ne corrige pas à elle seule des dimensions excessives. Si votre CDN gère déjà la conversion en WebP ou AVIF, vous pouvez généralement désactiver cette partie de l’extension pour éviter de faire le travail deux fois. Consultez le guide pourquoi un site WordPress est lent pour une vue d’ensemble.

Testez fast.site avec votre propre site

fast.site ajoute le cache en edge, l’optimisation des images et la protection DDoS à votre hébergement actuel. Connectez votre domaine et mesurez la différence sur vos propres pages.

Donnez 7 jours à votre site. Laissez les résultats décider.

Commencez avec votre domaine, votre trafic et une vision claire de la suite.