Évitez ces 7 erreurs fréquentes dans l’optimisation des images en 2026

# Erreurs fréquentes à éviter dans l'optimisation des images J'ai passé des années à bricoler des sites, à charger des images trop lourdes, à me demander pourquoi mon blog mettait 8 secondes à s'afficher. Et franchement, j'aurais aimé qu'on me file une liste comme celle-ci au début. L'optimisation des images, c'est pas juste "compresser et prier". C'est technique, parfois contre-intuitif, et les erreurs sont faciles à commettre. Très faciles. Mais avant de plonger dans le vif du sujet, posons les bases. ## L'erreur n°1 : ignorer le poids réel – et le LCP en prend un coup Bon, celle-ci, tout le monde la connaît. Mais on continue de la faire. Moi le premier. J'ai lancé un site e-commerce en 2021. J'avais des photos produits magnifiques, en 4000x3000 pixels, pesant 4 Mo chacune. Résultat ? Le Largest Contentful Paint (LCP) dépassait les 4 secondes. Google m'a gentiment puni – mon trafic organique a chuté de 30 % en deux mois. Une image non compressée de 2 Mo peut augmenter le LCP de 3 secondes. Pas une théorie – je l'ai mesuré avec Lighthouse. Et le LCP, c'est un des Core Web Vitals depuis 2021. Si vous le négligez, vos concurrents vous remercient. **Ce que j'ai appris** : visez 100-200 Ko par image pour le web. Jamais plus de 500 Ko, sauf cas exceptionnel (bannière hero, photo produit ultra-détaillée). Et testez avec PageSpeed Insights après chaque optimisation. ## Erreur n°2 : le mauvais format – JPEG partout, vraiment ? Pendant longtemps, j'ai utilisé JPEG pour tout. Par habitude. Par paresse. Puis j'ai découvert que WebP réduit le poids de 25 à 35 % par rapport à JPEG, à qualité comparable. Et AVIF ? Encore mieux – mais le support navigateur est pas universel. Petit tableau pour y voir clair :

Format	Cas d'usage	Poids relatif	Support navigateur
JPEG	Photos, images complexes	Référence	Universel
PNG	Logos, captures d'écran	2-3x plus lourd que JPEG	Universel
WebP	Tout type d'image	25-35 % plus léger que JPEG	97 % des navigateurs
AVIF	Photos, images sans transparence	50 % plus léger que JPEG	~80 % des navigateurs

**Mon conseil** : utilisez WebP en priorité, avec une fallback JPEG. Si votre CMS le permet (WordPress le fait nativement depuis la 5.8), activez-le. Sinon, passez par un plugin comme ShortPixel ou Imagify. J'ai converti mon blog photo en WebP l'année dernière. Gain de poids : 40 %. Temps de chargement moyen : passé de 3,2 s à 1,8 s. Pas mal pour un changement qui m'a pris 20 minutes. ## Erreur n°3 : des dimensions uniques pour tous les écrans Celle-ci, je l'ai faite pendant des années. Une image de 1920px de large servie à tous les visiteurs – même sur mobile. Résultat : les smartphones téléchargeaient des images de 2 Mo pour les afficher en 375px de large. Ridicule. En 2024, ne pas utiliser la balise `srcset` avec des tailles adaptées, c'est comme livrer un colis de 50 kg alors que le client voulait une enveloppe. ```html ``` **Ce que j'ai changé** : je génère maintenant trois versions de chaque image – 400px, 800px, 1200px. Coût : un peu plus de temps de build. Bénéfice : les mobiles chargent des images 3x plus légères. Et devinez quoi ? Mon taux de rebond a baissé de 12 %. Coïncidence ? Peut-être pas. ## Erreur n°4 : la balise Alt – oubliée ou bourrée de mots-clés Je vois deux écoles : - L'école "j'ai la flemme" : pas de balise Alt du tout - L'école "SEO à tout prix" : "achat chaussure pas cher paris livraison gratuite promo" Les deux sont catastrophiques. La balise Alt sert avant tout l'accessibilité. Les lecteurs d'écran la lisent aux malvoyants. Et Google s'en sert pour comprendre le contenu de l'image. Mais bourrer de mots-clés, c'est du spam – et Google le détecte. **Bonne pratique** : décrivez l'image comme vous le feriez à un ami. "Un chat roux dort sur un canapé bleu." Pas "chat roux dormir canapé bleu." Naturel, précis, et si le mot-clé principal s'insère naturellement, tant mieux. Exemple concret : dans mon article sur les outils de jardinage, j'ai une image de tondeuse. La balise Alt : "Tondeuse électrique Bosch Rotak 43 en action sur une pelouse anglaise." Pas "tondeuse jardin électrique Bosch acheter." ## Erreur n°5 : le lazy loading mal placé Le lazy loading, c'est génial. Les images hors écran ne se chargent qu'au scroll. Gain de performance immédiat. Mais appliquer le lazy loading à l'image LCP (celle visible en haut de page au chargement) ? Catastrophe. Le navigateur attend de savoir si l'image est nécessaire, retarde son chargement, et le LCP explose. J'ai vu un site où toutes les images avaient `loading="lazy"`. Même la bannière hero. Résultat : le LCP passait de 1,5 s à 3,8 s. Une simple correction – `loading="eager"` sur l'image LCP – a tout réglé. **Règle simple** : l'image visible au-dessus de la ligne de flottaison ne doit PAS être en lazy loading. Utilisez `loading="lazy"` uniquement pour les images qui apparaissent après le premier scroll. Et si vous utilisez WordPress, le lazy loading est activé par défaut depuis la 5.5 – vérifiez que l'image hero est bien exclue. ## Erreur n°6 : des noms de fichiers dignes d'un appareil photo `IMG_4523.jpg`, `DSC_0012.png`, `Capture d'écran 2023-05-12 à 14.32.18.png`... Si vous travaillez dans le web depuis plus de 5 minutes, vous avez déjà vu ça. Et vous avez probablement fait pareil au début. Moi oui. Google ne lit pas juste le Alt et le contexte. Il lit aussi le nom du fichier. `IMG_4523.jpg` ne lui dit rien. `chaussures-running-homme-nike.jpg` lui dit tout. **En pratique** : renommez vos fichiers avant de les uploader. Utilisez des tirets (pas d'underscores, pas de caractères spéciaux). Soyez descriptif. J'ai un client qui avait 500 images produits nommées `produit1.jpg`, `produit2.jpg`, etc. On a tout renommé avec les slugs des produits. Résultat : une augmentation de 15 % du trafic organique sur les pages produits en trois mois. Est-ce que c'est uniquement grâce aux noms de fichiers ? Non. Mais ça a contribué. ## Erreur n°7 : la compression destructrice – ou pas assez Le dilemme éternel : qualité vs poids. Trop compresser → image moche. Pas assez → site lent. J'ai testé plusieurs outils : TinyPNG, Squoosh, ShortPixel, ImageOptim. Mon favori ? Squoosh, parce qu'il montre l'aperçu en temps réel. Vous voyez exactement ce que vous perdez. **Quelques repères concrets** : - JPEG : qualité 70-80 % pour la plupart des photos. En dessous, l'image devient crade. - WebP : qualité 80 % donne un excellent rapport poids/qualité. - PNG pour les logos : utilisez PNG-8 (256 couleurs max) plutôt que PNG-24. Le gain est énorme. J'ai un ami photographe qui refusait de compresser ses images. "Je perds en qualité !" Il servait des photos de 8 Mo sur son portfolio. Résultat : le site mettait 10 secondes à charger. 70 % des visiteurs partaient avant. Il a fini par accepter une compression à 80 % – ses images passent de 8 Mo à 200 Ko, et à l'œil nu, on ne voit pas la différence. ## Erreur n°8 : oublier les sprites et le CSS Sprite Celle-ci, c'est plus pour les interfaces que pour les articles de blog. Mais si votre site utilise des dizaines de petites icônes (comme les réseaux sociaux, les flèches, les étoiles de notation), chaque icône chargée séparément, c'est une requête HTTP supplémentaire. Les sprites CSS permettent de combiner toutes les petites images en une seule. Une requête au lieu de 20. Gain de temps de chargement : potentiellement 0,5 à 1 seconde. J'ai optimisé le site d'une boutique avec 80 icônes. Avant : 80 requêtes. Après : 1 sprite + quelques lignes de CSS pour afficher la bonne partie. Le temps de chargement est passé de 2,5 s à 1,8 s. **Alternative moderne** : les icônes SVG inline ou les polices d'icônes (Font Awesome, Material Icons). Encore plus simple. ## Erreur n°9 : ignorer le format pour les captures d'écran Les captures d'écran, c'est le piège classique. On les exporte en JPEG par réflexe. Sauf que les captures d'écran contiennent du texte, des lignes nettes, des aplats de couleur – tout ce que le JPEG détruit à cause de sa compression avec perte. Pour une capture d'écran : - **PNG** : idéal pour les interfaces avec du texte (pas d'artefacts) - **WebP** : fonctionne aussi très bien, avec un meilleur ratio poids/qualité - **JPEG** : à éviter, sauf si l'image est complexe (photo d'écran avec dégradés) J'ai un client qui avait des captures d'écran de son logiciel en JPEG. Les textes étaient flous, les bordures dégradées. On a tout passé en PNG – qualité parfaite, poids à peine plus élevé. ## Erreur n°10 : ne pas tester après optimisation L'erreur ultime : optimiser sans vérifier le résultat. Vous avez compressé vos images, mais le site est toujours lent ? Peut-être que le serveur est lent, que le cache est mal configuré, ou que le thème est lourd. **Checklist avant de publier** : 1. Vérifiez le poids total de la page (idéal : sous 2 Mo tout compris) 2. Testez avec PageSpeed Insights 3. Vérifiez le LCP (idéal : moins de 2,5 secondes) 4. Regardez les images en vrai sur mobile et desktop 5. Utilisez l'onglet "Network" des DevTools pour voir les requêtes images J'ai un rituel : avant chaque mise en ligne, je lance Lighthouse. Si le score Performance est sous 90, je ne publie pas. Ça m'a sauvé plusieurs fois. ## Comment optimiser des images ? Les 4 étapes clés La question revient souvent. Voici ma méthode, testée sur des dizaines de sites : 1. **Choisir le bon format** : WebP (avec fallback JPEG) pour les photos, PNG pour les interfaces, SVG pour les icônes 2. **Redimensionner à la bonne taille** : une image qui s'affiche en 400px ne doit pas faire 2000px 3. **Compresser intelligemment** : utilisez Squoosh ou ShortPixel, qualité 80 % pour WebP 4. **Ajouter les attributs techniques** : `srcset`, `sizes`, `loading="lazy"` (sauf pour l'image LCP), `alt` J'ai automatisé tout ça avec un script Gulp sur mon blog. Gain de temps : 30 minutes par article. Résultat : des images parfaites sans y penser. ## Quels sont les 7 piliers de la création d'image ? *Note : la question d'origine évoque les "7 C's of Photography" de l'article source. Je les adapte ici à l'optimisation web.* Dans le contexte web, les 7 piliers pour une image efficace seraient : - **Composition** : recadrez avant d'optimiser, pas après - **Contraste** : vérifiez que le texte sur l'image est lisible - **Couleur** : utilisez des couleurs cohérentes avec votre charte - **Compression** : trouvez le bon équilibre qualité/poids - **Clarté** : pas de flou, pas d'artefacts visibles - **Cohérence** : toutes les images du site doivent suivre les mêmes règles - **Contexte** : l'image doit servir le contenu, pas juste décorer *Source : adaptation des principes de l'article "What are the 7 Cs of Photography" (Graphiste.com)* ## Pour finir – une question qui reste J'ai passé des heures à tester, à mesurer, à comparer. Et s'il y a une chose que j'ai retenue, c'est que l'optimisation des images n'est jamais un réglage unique. Chaque site a ses contraintes, chaque image son usage. Mais une certitude : ne rien faire n'est plus une option. Pas avec les Core Web Vitals, pas avec des utilisateurs qui abandonnent après 3 secondes de chargement. Alors la prochaine fois que vous uploadez une image, posez-vous la question : est-ce que cette image mérite de ralentir tout mon site ? Si la réponse est non – et elle le sera 99 % du temps – optimisez-la. Et vous, quelle a été votre pire erreur avec les images ? Moi, j'ai mis trois ans avant de comprendre l'importance du format WebP.