Optimisation des images sur votre site : compression automatique, WebP/AVIF, lazy loading et CDN
1. Pourquoi les images sont le premier fléau de performance d’un site indépendant
Les statistiques de HTTP Archive montrent que les images représentent plus de 50 % du poids total transféré d’une page moyenne. Sur un site indépendant B2B, où les photos de produits, les visuels de cas clients et les images d’usine sont nombreux, cette part atteint souvent 60 à 70 %. Le texte et le CSS réunis pèsent peut-être 100 Ko, mais une seule bannière produit non compressée peut faire 2 à 3 Mo.
L’erreur la plus fréquente des équipes de sites indépendants : le designer exporte l’original depuis le PSD et l’envoie tel quel dans WordPress, sans redimensionner à l’upload, et le thème ne génère pas de WebP. Résultat : une page produit affiche 8 grandes images de 2 Mo. En 3G sur mobile, rien que les images demandent 30 secondes de chargement, et le visiteur a déjà quitté la page avant qu’elles s’affichent. Pour gérer vos médias, voir Gouvernance des actifs médias. Pour définir le seuil Core Web Vitals, voir Optimiser les Core Web Vitals.
| Problème d’image courant | Impact sur la performance | Priorité de correction |
|---|---|---|
| Original envoyé sans redimensionnement | Image de 2 à 3 Mo, LCP hors seuil | Priorité maximale, à traiter cette semaine |
| JPEG uniquement, pas de WebP | 30 à 50 % de poids en plus à qualité égale | Élevée, sous deux semaines |
| Bannière du premier écran en lazy loading | LCP retardé de 1 à 2 secondes | Priorité maximale, à corriger immédiatement |
| Attributs width/height absents | CLS (Cumulative Layout Shift) | Moyenne, lors de la mise à jour du thème |
| Images hors CDN | 1 à 3 secondes de latence sur le retour à l’origine | Élevée, avec la configuration CDN |
2. Compression automatique : quatre règles appliquées dès l’upload
Ne comptez pas sur l’équipe pour compresser les images une par une à la main : la compression doit se faire automatiquement à l’upload. L’écosystème WordPress propose trois solutions prêtes à l’emploi : Smush, ShortPixel et Imagify, qui compressent automatiquement à l’upload et génèrent du WebP, pour un abonnement annuel de 50 à 100 dollars. Si votre site indépendant publie moins de 500 images par an, l’offre la moins chère suffit.
Réglage de la qualité de compression : pour le JPEG, une qualité entre 75 et 82 représente le meilleur compromis entre rendu visuel et poids du fichier. En dessous de 70, des blocs et des crénelages apparaissent ; au-dessus de 85, le gain de poids devient marginal. Pour un PNG avec canal alpha, une quantification vers une palette de 16 à 32 couleurs peut réduire le poids de plus de 60 %. Exemple concret : une photo d’atelier en JPEG qualité 78, largeur 1920, pèse généralement entre 150 et 220 Ko à l’export. Au-delà de 300 Ko, c’est qu’il y a encore un problème de recadrage ou de niveau de qualité. Pour choisir votre CDN, voir Comparatif des CDN.
| Type d’image | Format conseillé | Poids cible | Largeur maximale |
|---|---|---|---|
| Bannière/hero en haut de page | WebP + repli JPEG | 150 à 200 Ko | 1920px |
| Visuel produit principal | WebP + repli JPEG | 80 à 120 Ko | 1200px |
| Vignette produit | WebP | 15 à 30 Ko | 300 px |
| Illustration de cas/article | WebP | 80 à 150 Ko | 1200px |
| Icône/logo | SVG ou petit PNG | Moins de 5 Ko | 2 fois la taille d’affichage |
| Capture d’écran/image avec texte | PNG sans perte | Jusqu’à 200 Ko | 2 fois la largeur d’affichage |
3. Configurer WebP/AVIF : balise picture et négociation automatique par le CDN
WebP est pris en charge par Chrome, Edge, Firefox et Safari 14 et versions ultérieures, soit plus de 95 % de couverture. AVIF compresse encore 20 à 30 % mieux que WebP, mais son support Safari n’arrive qu’à partir de la version 16.4 et son encodage est lent : réservez-le à la pré-génération par lots d’images statiques. Pour un site e-commerce indépendant, inutile d’écrire du AVIF en natif : laissez le CDN le convertir automatiquement à l’origine selon l’en-tête Accept, c’est plus simple.
Deux approches possibles. La première, la négociation automatique au niveau du CDN : Cloudflare, Cloudinary et Fastly savent renvoyer du WebP ou de l’AVIF selon l’en-tête Accept de la requête. Votre serveur d’origine ne stocke que du JPEG/PNG, aucune modification côté exploitation. La seconde, la déclaration explicite via la balise picture côté front-end, adaptée aux petits sites sans CDN. Un constat contre-intuitif :ne réencodez pas toutes vos images pour courir après l’AVIF. L’encodage AVIF prend 5 à 10 fois plus de temps que le WebP ; à moins d’avoir moins de 500 images, le coût n’en vaut pas la peine. Pour configurer l’accélération mondiale, voir Accélération mondiale par CDN.
| Approche | Mise en œuvre | Couverture navigateurs | Coût annuel | Cas d’usage |
|---|---|---|---|---|
| Transcodage automatique par CDN | Cloudflare/Cloudinary renvoient le format selon l’en-tête Accept | 95 %+ avec repli automatique | Inclus dans les frais de CDN | Premier choix pour la plupart des sites indépendants |
| Double format via balise picture | <picture> écrit à la main + WebP/JPEG | Contrôle manuel | 0 dollar | Petits sites sans CDN |
| Génération automatique par extension WordPress | ShortPixel/Smush génèrent une copie WebP | 95 %+ | 50 à 100 dollars/an | Sites WordPress indépendants |
| Pré-génération AVIF pour tout le site | Conversion AVIF par lots au build | Environ 85 % | Coût d’encodage élevé | Sites de marque avec moins de 500 images |
| JPEG uniquement | Aucun format moderne | 100 % | 0 dollar | Toujours déconseillé, poids pénalisant |
4. srcset et images responsives : ne faites pas télécharger la version desktop au mobile
La compression ne suffit pas : il faut aussi que le navigateur choisisse l’image selon la taille de l’écran. Une bannière de 1920 px de large ne s’affiche qu’en 375 px sur mobile, mais pèse quand même 200 Ko, soit 70 % de trafic gaspillé. La bonne méthode : déclarer plusieurs tailles avec srcset et sizes ; le navigateur sélectionne automatiquement la plus adaptée selon la densité de pixels de l’appareil et la largeur du viewport.
WordPress génère automatiquement plusieurs tailles intermédiaires à l’envoi (thumbnail, medium, large), mais le thème ne les affiche pas forcément via srcset dans son template. Méthode de vérification concrète : ouvrez l’onglet Network de Chrome DevTools et regardez l’URL de l’image réellement téléchargée pour la bannière de la page d’accueil. Si c’est toujours celle en 1920px, c’est que srcset ne fonctionne pas. La correction la moins coûteuse consiste à activer add_image_size dans le functions.php du thème et à laisser the_post_thumbnail générer le srcset, sans écrire les balises à la main.
| Point de rupture | Largeur conseillée | Utilité |
|---|---|---|
| Mobile portrait | 640px | Listes et articles sur mobile |
| Tablette portrait | 1024px | Tablettes et petits écrans |
| Ordinateur | 1920px | Bannières et images larges |
| Retina 2x | Largeur d’affichage ×2 | Net sur écran haute densité |
5. Lazy loading : tout en lazy hors du premier écran, images du premier écran en eager
Le lazy loading natif est mature : Chrome, Firefox et Safari 15.4+ le prennent en charge. La règle est simple : les images visibles dans le premier écran (en général la bannière et la première image produit) doivent être en loading=”eager”, toutes les autres en loading=”lazy”. Depuis WordPress 5.5, les images du contenu passent en lazy par défaut, mais une bannière codée en dur dans le thème doit être passée manuellement en eager.
L’erreur la plus fréquente : mettre la bannière du premier écran en lazy au nom de la “performance”. Le navigateur attend alors d’avoir analysé la balise image dans le HTML pour lancer la requête, et l’élément LCP est retardé d’une à deux secondes. La bonne méthode : précharger la bannière du premier écran avec <link rel=”preload” as=”image”>, tout en conservant les attributs width/height pour éviter le CLS. Exemple concret : ajoutez <link rel=”preload” as=”image” href=”hero.webp” fetchpriority=”high”> dans le head pour l’image hero de la page d’accueil, et vous gagnez encore 0,5 seconde sur le LCP. Pour la stratégie de cache du site, voir Stratégie de cache du site.
| Emplacement de l’image | Attribut loading | fetchpriority | preload |
|---|---|---|---|
| Hero/bannière du premier écran | eager (pas de lazy) | high | rel=preload obligatoire |
| Image produit principale du premier écran | eager | high ou auto | preload selon le cas |
| Images d’articles sous le premier écran | lazy | low ou rien | non |
| Vignettes de page liste | lazy | Non précisé | non |
| Pied de page/logo/images décoratives | lazy | low | non |
6. Validation : croiser Lighthouse et les données RUM
Une fois l’optimisation des images terminée, ne vous fiez pas au seul score Lighthouse : les données de laboratoire et les données utilisateurs réelles divergent. Lighthouse vérifie surtout trois audits : images non optimisées, images aux bonnes dimensions et images au format moderne. Pour les données réelles, consultez le 75e percentile du LCP dans CrUX (Chrome User Experience Report) ou Cloudflare RUM, pas la moyenne : la moyenne est tirée vers le bas par quelques utilisateurs rapides, alors que le 75e percentile reflète l’expérience de la majorité des visiteurs.
Une checklist de validation applicable : image LCP de la page d’accueil ≤ 200 Ko, 100 % des images hors premier écran en lazy sur tout le site, attributs width/height sur toutes les images, couverture WebP/AVIF ≥ 90 %, poids total des images ≤ 1 Mo par page. Si vous n’y arrivez pas, revenez au chapitre correspondant. L’optimisation PHP et base de données est un autre chantier, voir Mise à niveau de la version PHP et Optimisation des requêtes SQL lentes.
| Objectif de validation | Seuil de qualification | Outil de mesure | Que faire en cas d’échec |
|---|---|---|---|
| Poids des images LCP | ≤ 200 Ko | Lighthouse/DevTools | Compresser ou recadrer |
| Taux de couverture WebP / AVIF | ≥ 90 % | Vérifier les en-têtes de réponse dans DevTools Network | Activer la conversion automatique sur le CDN |
| Taux de couverture du lazy loading | 100 % hors premier écran | Vérifier l’attribut loading dans le code source | Remplacer en masse dans les templates |
| Déclaration des dimensions d’image | 100 % avec width / height | Audit CLS dans Lighthouse | Ajouter les attributs en masse dans le thème |
| Poids total des images d’une page | ≤ 1 Mo | DevTools Network | Supprimer les images redondantes ou fusionner en sprite |
| LCP au 75e percentile | ≤ 2,5 s | CrUX/Cloudflare RUM | Voir si le problème vient des images ou des polices |
FAQ — Questions fréquentes
WebP ou AVIF : lequel choisir ?
Peut-on mettre la bannière du premier écran en lazy loading ?
Jusqu’où compresser la qualité d’image sans différence visible ?
Quel plugin de compression automatique choisir pour WordPress ?
Quelle différence entre servir les images via un CDN ou non ?
Comment valider qu’une optimisation d’images est conforme ?
Pour conclure
L’optimisation des images n’est pas un projet ponctuel, c’est un pipeline qui traite chaque image dès l’upload. La vraie solution pour se simplifier la vie : figer les règles au moment de l’upload — largeur maximale 1920, qualité JPEG 80, génération automatique du WebP, lazy loading automatique hors premier écran, négociation de format automatique par le CDN. Ensuite, l’équipe n’a plus qu’à glisser-déposer ses images : aucune règle à retenir. Une fois ce pipeline en place, chaque nouvelle image est conforme automatiquement, sans vérification manuelle à chaque fois.
Trois étapes pour passer à l’action : d’abord, cette semaine, lancez Lighthouse sur la page d’accueil et regardez les deux audits « images non optimisées » et « formats modernes » ; ensuite, installez l’extension de compression automatique ShortPixel ou Smush et activez la génération WebP ; enfin, ajoutez un preload sur la bannière du premier écran, puis appliquez en lot le lazy loading et les width/height aux autres images. Refaites le test du LCP au 75e percentile deux semaines plus tard.
Une phrase à retenir : l’objectif de l’optimisation des images n’est pas d’être « léger », mais de faire afficher l’image clé du LCP en moins de 2,5 secondes — les autres peuvent bien attendre.