Ce que Google regarde sur une image
Une image, pour un moteur de recherche, ce sont deux choses distinctes. Le fichier d'abord : son nom, son format, ses dimensions, son poids. Le contexte ensuite : la balise alt, la légende éventuelle, le texte qui l'entoure, la page qui l'héberge. Vous jouez sur les deux, et les deux se traitent différemment.
Dans la pratique, l'immense majorité du gain se joue sur le poids. Sur les sites de PME que j'audite, les images représentent très souvent la plus grosse part du poids total d'une page, loin devant le texte et les scripts. Un carrousel d'accueil avec cinq photos sorties directement d'un appareil photo, et vous avez votre coupable pour un temps de chargement à rallonge.
Le reste (nom de fichier, alt, format) rapporte moins spectaculairement, mais ne coûte presque rien à faire correctement dès le départ. Autant prendre les bonnes habitudes tout de suite : reprendre 400 images a posteriori, c'est une autre affaire.
Nommer le fichier avant de l'envoyer
Règle simple : on renomme le fichier sur son ordinateur, avant l'upload. Une fois l'image en ligne, changer son nom veut dire changer son URL, donc casser les liens existants et perdre l'historique de la page dans Google Images. Ça se rattrape avec une redirection, mais c'est du travail pour rien.
Ce qui marche : des mots réels, en minuscules, sans accent, séparés par des tirets. IMG_4032.jpg devient chaise-bureau-ergonomique-noire.jpg. Pas d'underscore (Google les lit moins bien que les tirets), pas d'espace, pas de chaîne de trois mots-clés collés. Décrivez ce qu'on voit sur la photo, point.
Choisir le bon format : le WebP a gagné
Il y a quatre formats à connaître, et un seul choix par défaut.
- WebP : votre format standard aujourd'hui. À qualité visuelle équivalente, il produit des fichiers nettement plus légers que le JPEG. Il est supporté par tous les navigateurs actuels et accepté nativement par WordPress.
- JPEG : la roue de secours pour les photos, quand votre chaîne de production ne gère pas le WebP.
- PNG : uniquement quand vous avez besoin de transparence ou d'aplats nets (captures d'écran d'interface). Sur une photo, il est bien plus lourd sans être plus beau.
- SVG : pour les logos, pictogrammes et illustrations vectorielles. Poids ridicule, net à toutes les tailles.
L'AVIF compresse encore mieux que le WebP, mais il reste plus capricieux à générer. Si votre CMS ou votre CDN le propose en automatique, prenez-le. Sinon, ne vous embêtez pas : le WebP suffit largement à régler 90 % du problème.
L'erreur numéro un : envoyer une image trop grande
C'est l'erreur que je retrouve absolument partout, et c'est aussi celle qui coûte le plus cher. Une photo de smartphone fait couramment 4000 pixels de large et plusieurs mégaoctets. Elle est envoyée telle quelle dans un emplacement qui l'affiche sur 800 pixels. Le navigateur télécharge tout, puis réduit à l'écran. Le visiteur, lui, a payé la facture en secondes d'attente.
Avant compression, redimensionnez donc à la taille réelle d'affichage. Une largeur d'environ 1600 à 2000 pixels couvre confortablement une image pleine largeur sur les écrans haute densité. Pour une vignette d'article ou une photo dans le corps du texte, 800 à 1200 pixels suffisent. Et l'ordre compte : on redimensionne d'abord, on compresse ensuite. L'inverse revient à soigner un fichier dont on va de toute façon jeter les deux tiers.
Compresser sans abîmer le visuel
Une fois aux bonnes dimensions, il reste à baisser le poids. Le curseur de qualité entre 75 et 85 % est le point d'équilibre classique : la différence est invisible à l'œil nu sur une photo, et le fichier fond. En dessous, les aplats et les dégradés commencent à baver.
Pour le faire à la main, Squoosh, l'outil gratuit de Google, affiche le avant/après côte à côte avec le poids obtenu : parfait pour se calibrer sur quelques images avant d'industrialiser. Sur WordPress, une extension d'optimisation d'images fait le redimensionnement, la conversion en WebP et la compression au moment de l'upload, en une seule passe. C'est le réglage à activer le jour du lancement, pas deux ans après.
Quel objectif viser ? Sans donner de règle absolue, une image d'illustration en dessous de 150 à 200 Ko et une grande image d'en-tête sous les 300 Ko constituent des repères raisonnables pour un site éditorial. Si vous êtes à plusieurs mégaoctets, il n'y a pas de débat à avoir.

Tant qu'on parle de poids, sachez que les images sont rarement le seul frein d'une page lente. Si le vôtre tourne sous WordPress, la marche à suivre complète est détaillée dans notre guide pour rendre un site WordPress plus rapide en s'y prenant dans l'ordre.
La balise alt : décrire, pas bourrer
L'attribut alt sert d'abord à l'accessibilité. C'est ce que lit à voix haute un lecteur d'écran pour une personne malvoyante, et c'est ce qui s'affiche quand l'image ne charge pas. Google s'en sert ensuite pour comprendre le sujet de l'image, notamment dans Google Images. Les deux usages vont dans le même sens : décrivez sobrement ce qu'on voit.
Quelques garde-fous appris à la dure :
- Pas besoin de commencer par « image de » ou « photo de », le contexte est déjà donné.
- Une phrase courte et concrète vaut mieux qu'une accumulation de mots-clés. « Chaise de bureau ergonomique noire avec appui-tête » plutôt que « chaise bureau ergonomique pas cher achat chaise ».
- Si l'image est purement décorative (un séparateur, un fond, un pictogramme sans information), laissez l'alt vide avec
alt="". Le lecteur d'écran la passera au lieu de bavarder pour rien. - Le mot-clé de la page peut apparaître dans l'alt de l'image principale s'il décrit vraiment la photo. Le répéter sur les vingt images de la page, non.
La documentation officielle de Google Search Central sur les images insiste d'ailleurs sur le même point : le texte autour de l'image, la légende et le titre de la page comptent autant que l'attribut alt pour situer le sujet.
Les trois réglages techniques qui restent
Une fois les fichiers propres, trois détails de code font le reste du travail sur la vitesse.
Le lazy loading d'abord : loading="lazy" retarde le chargement des images situées plus bas dans la page jusqu'à ce que le visiteur y arrive. WordPress l'ajoute tout seul depuis plusieurs versions. Attention au piège classique : ne lazy-loadez jamais la grande image visible en haut de page. C'est souvent elle qui détermine le LCP, et la retarder volontairement dégrade la mesure que vous cherchez justement à améliorer. Si le sigle ne vous parle pas, on a expliqué ce que mesurent précisément les Core Web Vitals et ce que Google en fait.
Les dimensions déclarées ensuite : les attributs width et height dans le code HTML réservent la place de l'image avant qu'elle n'arrive. Sans eux, le texte saute au moment du chargement, et ce saut se paie en CLS.
Le srcset enfin : il permet au navigateur de choisir une version adaptée à l'écran, une petite sur mobile, une grande sur un écran de bureau. La plupart des CMS le génèrent automatiquement. Vérifiez juste qu'il est bien là en regardant le code source d'une page.
Dans quel ordre s'y prendre sur un site existant
Si vous héritez d'un site déjà rempli d'images non optimisées, ne reprenez pas tout à la main. Voilà l'ordre que je déroule :
- Passer la page d'accueil et deux ou trois pages stratégiques dans PageSpeed Insights, onglet mobile, et lire la section sur les images. Elle liste les fichiers fautifs avec le gain estimé.
- Traiter en priorité les cinq à dix images les plus lourdes : redimensionnement, conversion WebP, compression. C'est là que se trouve l'essentiel du gain.
- Activer une extension d'optimisation qui traitera automatiquement tout ce qui sera envoyé ensuite, et lancer son traitement en masse sur la médiathèque existante.
- Reprendre les balises alt manquantes uniquement sur les pages qui comptent, celles qui reçoivent du trafic ou qui vendent.
- Prendre l'habitude, pour tout nouveau contenu, de renommer le fichier avant l'upload et de remplir l'alt dans la foulée.
Si vous ne devez retenir qu'une chose : le redimensionnement et la compression rapportent 80 % du résultat, le nommage et l'alt sont la finition.
Le nommage et l'alt des vieilles images d'archive ? Franchement, laissez tomber si vous en avez des centaines. Le rapport temps passé sur résultat obtenu est mauvais, et vous avez mieux à faire ailleurs, à commencer par les dix contrôles techniques à passer en revue quand on démarre.



