Dernière mise à jour : septembre 2026
Sur la plupart des sites WordPress, les images représentent entre 40 et 70 % du poids total d’une page. Une seule photo uploadée directement depuis un appareil photo — 4000 pixels de large, 3 Mo en JPEG — pèse plus que l’ensemble du HTML, du CSS et du JavaScript réunis. Quand cette image est aussi l’élément le plus grand visible à l’écran, c’est elle qui détermine le score Largest Contentful Paint (LCP) — le premier des trois Core Web Vitals que Google utilise pour évaluer la performance d’un site.
Optimiser les images, ce n’est pas « compresser un peu pour que ça aille plus vite ». C’est maîtriser le format, les dimensions, le nommage, le texte alternatif, le comportement de chargement et l’impact sur le rendu. Chaque décision a des conséquences mesurables — sur la vitesse, sur le référencement, sur l’accessibilité.
Ce que Google voit dans une image
Un moteur de recherche ne « regarde » pas une image comme un humain. Il analyse des signaux techniques et contextuels pour déterminer ce qu’elle représente et si elle mérite d’apparaître dans les résultats de recherche (y compris Google Images, qui reste une source de trafic significative pour beaucoup de sites).
Les signaux pris en compte : le nom du fichier, le texte alternatif (attribut alt), le contexte textuel autour de l’image dans la page, la légende éventuelle, les dimensions déclarées, le format, le poids, et la présence de l’image dans un sitemap dédié. Un fichier nommé IMG_4523.jpg avec un attribut alt vide, inséré sans légende dans une page sans rapport — c’est une image invisible pour Google, quel que soit son intérêt visuel.
Nommage des fichiers et texte alternatif
Le nom de fichier est le premier signal. Il doit décrire le contenu de l’image en termes lisibles, avec des mots séparés par des tirets : audit-securite-wordpress-dashboard.jpg plutôt que capture-ecran-1.png ou DSC_0042.jpg. Ce nommage se fait avant l’upload — une fois le fichier dans la médiathèque WordPress, renommer le fichier source ne change pas l’URL générée.
Le texte alternatif (attribut alt) remplit deux fonctions distinctes. D’abord, l’accessibilité : c’est le texte lu par les lecteurs d’écran pour les personnes malvoyantes. Ensuite, le SEO : c’est l’indice principal que Google utilise pour comprendre le contenu de l’image. Un bon texte alternatif décrit ce que l’image montre, pas ce que la page raconte. Pour une capture d’écran d’un rapport PageSpeed : « Rapport PageSpeed Insights montrant un score LCP de 1.2 secondes » — pas « optimisation des performances WordPress ».
Erreur fréquente : bourrer le texte alt de mots-clés. Google sait reconnaître cette pratique et elle peut déclencher une dévaluation. Le texte alt est une description, pas un champ de mots-clés.
Formats : JPEG, WebP, AVIF — lequel choisir
Le format détermine le ratio entre qualité visuelle et poids du fichier. Trois formats couvrent l’essentiel des besoins d’un site WordPress en production.
JPEG reste le format par défaut pour les photographies. Il offre une bonne compression avec perte et une compatibilité universelle. Son principal défaut : il ne supporte pas la transparence et son algorithme de compression date des années 90 — les formats modernes font mieux à qualité visuelle équivalente.
WebP, développé par Google, réduit le poids des fichiers de 25 à 35 % par rapport au JPEG à qualité visuelle équivalente. Il supporte la transparence et l’animation. WordPress le supporte nativement depuis la version 5.8, et plus de 97 % des navigateurs actuels le lisent. C’est aujourd’hui le format à privilégier pour la majorité des images d’un site WordPress.
AVIF pousse la compression encore plus loin — jusqu’à 50 % de réduction par rapport au JPEG. La compatibilité navigateur progresse rapidement mais reste légèrement en retrait de WebP. Sur un site qui vise la performance maximale, AVIF est le choix optimal pour les photographies ; WebP sert de fallback pour les navigateurs qui ne le supportent pas encore.
Pour les logos, icônes et illustrations avec des aplats de couleur : le SVG (vectoriel) est imbattable — poids minimal, rendu net à toute taille, pas de pixellisation. Le PNG reste pertinent pour les captures d’écran et les images qui nécessitent de la transparence sans perte de qualité.
Compression : réduire le poids sans dégrader la qualité
La compression est l’étape qui a le plus d’impact immédiat sur les performances. Une image de 2 Mo réduite à 150 Ko sans différence visuelle perceptible — c’est courant, et c’est exactement ce que les outils de compression permettent.
Deux approches existent. La compression au moment de l’upload, via un plugin WordPress qui traite automatiquement chaque image ajoutée à la médiathèque. Les solutions les plus fiables : Imagify (bonne intégration avec WP Rocket), ShortPixel (tarification par crédits, support AVIF), EWWW Image Optimizer (compression locale, sans envoi vers un serveur tiers — un point à considérer pour la confidentialité des données).
La compression côté serveur, en amont de WordPress. Sur un stack avec OpenLiteSpeed, le module PageSpeed peut convertir et compresser les images à la volée. L’avantage : aucune dépendance à un plugin, et le traitement s’applique à toutes les images servies, y compris celles qui ne passent pas par la médiathèque WordPress.
Dans les deux cas, viser un niveau de compression « lossy » (avec perte) entre 75 et 85 % de qualité. En dessous de 70 %, les artefacts de compression deviennent visibles. Au-dessus de 90 %, le gain de poids est marginal.
Dimensions : servir la bonne taille
Uploader une image de 4000 × 3000 pixels pour l’afficher dans une colonne de 800 pixels de large, c’est forcer le navigateur à télécharger quatre fois plus de données que nécessaire. WordPress génère automatiquement plusieurs tailles (thumbnail, medium, large, full) lors de l’upload, mais les dimensions par défaut ne correspondent pas toujours à celles réellement utilisées par le thème.
La bonne pratique : vérifier les dimensions maximales d’affichage dans le thème (la largeur de la zone de contenu, typiquement entre 800 et 1200 pixels) et redimensionner les images avant l’upload. Pour les écrans Retina (2x), une image de 1600 pixels de large pour un affichage à 800 pixels offre un bon compromis entre netteté et poids.
WordPress gère les images responsives via l’attribut srcset, qui permet au navigateur de choisir la taille la plus adaptée à l’écran du visiteur. Ce mécanisme fonctionne automatiquement — à condition que les différentes tailles d’image existent. Si les tailles intermédiaires ont été supprimées ou si le thème ne les déclare pas, le navigateur n’a pas le choix et charge la version complète.
Lazy loading et l’exception LCP
Depuis WordPress 5.5, le lazy loading est natif : l’attribut loading="lazy" est ajouté automatiquement à toutes les images. Le principe est simple — ne charger une image que lorsqu’elle s’approche de la zone visible à l’écran. Sur une page longue avec vingt images, seules les deux ou trois premières sont chargées immédiatement ; les autres attendent que le visiteur scrolle.
Le gain de performance est réel, mais il y a un piège. L’image la plus grande visible immédiatement — celle qui détermine le score LCP — ne doit pas être en lazy loading. Si elle l’est, le navigateur attend avant de la charger, ce qui retarde le LCP et dégrade le score Core Web Vitals. Depuis WordPress 6.3, la première image de contenu est automatiquement exclue du lazy loading. Mais si l’image LCP est un arrière-plan CSS ou une image insérée par le thème plutôt que par le contenu, cette exclusion automatique ne s’applique pas — il faut le gérer manuellement.
Pour les images critiques (hero image, image principale d’un article), ajouter un attribut fetchpriority="high" indique au navigateur de les charger en priorité. C’est l’inverse du lazy loading — et c’est ce que l’image LCP nécessite.
Impact direct sur les Core Web Vitals
Les images influencent deux des trois Core Web Vitals de manière directe.
LCP (Largest Contentful Paint) — Si l’élément le plus grand de la page est une image (ce qui est le cas sur la majorité des pages WordPress), le temps de chargement de cette image détermine le score LCP. Format non optimisé, dimensions excessives, absence de preload, lazy loading appliqué par erreur — chacun de ces facteurs ajoute des centaines de millisecondes au LCP. Le seuil Google pour un « bon » LCP est de 2,5 secondes ; une seule image mal optimisée peut le faire dépasser.
CLS (Cumulative Layout Shift) — Une image sans dimensions déclarées (attributs width et height dans le HTML) provoque un décalage de mise en page quand elle se charge : le texte et les autres éléments « sautent » pour lui faire de la place. Ce saut est exactement ce que le CLS mesure. La correction est triviale — déclarer les dimensions dans le HTML — mais WordPress ne le fait pas toujours automatiquement, surtout quand les images sont insérées via des shortcodes ou des page builders.
Un audit de performance sérieux commence presque toujours par les images — c’est là que se trouvent les gains les plus importants avec le moins d’effort.
Checklist avant chaque upload
Avant d’ajouter une image à un site WordPress en production, vérifier systématiquement ces points : le fichier est nommé de manière descriptive (pas de noms génériques ou de codes), les dimensions correspondent à l’affichage réel dans le thème (pas de 4000 px pour un affichage à 800 px), le format est adapté (WebP pour les photos, SVG pour les logos et icônes, PNG uniquement si la transparence sans perte est nécessaire), le poids est raisonnable (sous 200 Ko pour la plupart des images de contenu, sous 500 Ko pour une hero image pleine largeur), et le texte alternatif est rédigé — description factuelle du contenu de l’image, pas de bourrage de mots-clés.
Sur un site avec plusieurs contributeurs, cette discipline ne tient que si elle est documentée et que les outils automatisent ce qui peut l’être. Un plugin de compression automatique à l’upload élimine le risque qu’un contributeur uploade un fichier de 5 Mo sans s’en rendre compte. C’est un élément de la maintenance continue du site — pas un one-shot à la mise en ligne.
FAQ
Faut-il convertir toutes les images existantes en WebP ?
Sur un site avec un catalogue d’images important, la conversion rétroactive de toutes les images en WebP peut représenter un gain de performance significatif. Les plugins comme ShortPixel ou Imagify proposent une conversion en masse avec remplacement automatique des URL dans le contenu. L’opération est transparente pour les visiteurs, mais elle doit être testée sur un environnement de staging avant d’être appliquée en production — certains thèmes ou plugins peuvent mal gérer le changement de format.
Le lazy loading natif de WordPress suffit-il ou faut-il un plugin dédié ?
Le lazy loading natif de WordPress (depuis la version 5.5) fonctionne correctement pour la majorité des cas. Il ajoute l’attribut loading="lazy" aux images et depuis WordPress 6.3, exclut automatiquement la première image du contenu. Un plugin dédié n’est utile que si le site nécessite un contrôle plus fin — par exemple pour exclure spécifiquement certaines images du lazy loading, pour appliquer le lazy loading aux iframes, ou pour ajouter un effet de placeholder pendant le chargement.
Les images ont-elles un impact sur le référencement au-delà de la vitesse ?
Oui. Google Images génère un volume de trafic non négligeable pour certains secteurs (e-commerce, architecture, design, alimentation). Un texte alternatif bien rédigé et un sitemap d’images (généré automatiquement par la plupart des plugins SEO comme Yoast ou Rank Math) permettent à Google d’indexer et de positionner les images dans ses résultats dédiés. C’est une source de trafic organique souvent sous-exploitée.
Vous voulez un audit de performance centré sur les images de votre site WordPress ?