logo et images d’interface : alléger sans dégrader le SEO
Un logo trop lourd sur une page d’accueil, et c’est tout le rendu qui s’allonge. Le problème ne vient pas du poids en lui-même, mais de l’endroit où il a été créé : un PNG né d’une capture d’écran, un JPEG aplati sur un fond blanc, une icône SVG perdant ses tracés à chaque export. Reprendre le fichier à la source change tout. Voici comment alléger logos et visuels d’interface sans les abîmer, en choisissant le bon format dès le départ et en disant clairement à Google ce qu’il doit indexer.
Le format choisi à la source décide du poids final
Aucun outil de compression ne rattrape un fichier né dans le mauvais format. Google accepte les images référencées dans l’attribut src des balises img en BMP, GIF, JPEG, PNG, WebP, SVG et AVIF, ce qui laisse une vraie marge de manœuvre. Encore faut-il savoir laquelle de ces options correspond à ce que vous mettez dans la page.
Les comparatifs de poids trouvables en ligne s’arrêtent souvent au gain de quelques kilo-octets, sans jamais relier le format à l’usage réel du visuel. Pour aller plus loin sur la manière dont Google traite ces signaux, philippe-larroche.fr détaille les mécanismes d’indexation côté référencement naturel.
Un logo vectoriel exporté en PNG, c’est plusieurs dizaines de kilo-octets pour un résultat qui perd sa netteté dès qu’on agrandit la fenêtre. Le même logo en SVG pèse une fraction de ce poids et reste net sur n’importe quelle résolution d’écran.
La différence ne se voit pas dans un comparateur de fichiers. Elle se voit dans le navigateur, à l’usage, quand l’utilisateur zoome ou change de matériel. C’est là que le choix du format prend tout son sens, et qu’un mauvais export se paie sur la durée.
Les familles de visuels et leurs logiques distinctes
Un logo, une icône d’interface et une capture d’écran ne répondent pas aux mêmes contraintes techniques. Confondre les trois conduit à des choix absurdes, comme compresser un pictogramme en JPEG ou garder une capture d’écran en vectoriel alors qu’elle contient du texte fin et des dégradés. Voici comment trancher pour chaque cas.
- Un logo simple, en aplats de couleur et sans effet, gagne à rester en SVG : le fichier reste léger et s’adapte à toutes les tailles d’affichage.
- Pour une icône d’interface, le choix dépend surtout du rendu attendu sur les écrans à forte densité de pixels.
- Une capture d’écran contenant du texte et des dégradés, vous la gardez en PNG plutôt qu’en JPEG ?
- Le GIF, lui, plafonne à 256 couleurs : pratique pour une petite animation, nettement moins pour un visuel riche.
- Quand le poids d’un PNG devient gênant sur une grande photo, le WebP ou l’AVIF prennent le relais sans perte visible.
Le format à privilégier pour les logos, les icônes et les captures d’écran reste le PNG, précisément parce qu’il gère la transparence et les aplats sans artefacts. Mais dès qu’un logo est purement vectoriel, le SVG fait mieux sur tous les tableaux : poids, netteté, redimensionnement. La règle tient en une phrase : on choisit le format avant de dessiner, pas après avoir constaté que la page rame.
Ce que Google indexe vraiment dans vos images
Un fichier léger ne sert à rien s’il reste invisible aux yeux du moteur. Google peut trouver des images dans l’attribut src de l’élément img, y compris lorsque cet élément est enfant d’un autre conteneur comme picture. En revanche, il n’indexe pas les images appelées en CSS. Autrement dit, un logo posé en background-image dans une feuille de style échappe purement et simplement à l’indexation, quelle que soit sa qualité.
Cette distinction change la façon de construire une interface. Une icône décorative peut rester en CSS sans conséquence. Mais un visuel porteur d’information, un logo de marque, une capture de produit, doit passer par une balise img avec un src propre. Sur ce point, voir aussi notre article sur optimiser le processus dachat.
Le picture et ses sources multiples fonctionnent très bien, tant que le navigateur et le robot tombent sur une image réelle dans le src de la balise finale. Ce détail technique conditionne la visibilité de tout le travail graphique réalisé en amont.
Beaucoup de sites bien optimisés côté texte laissent filer la moitié de leur audience visuelle pour une raison bête : le visuel qui compte est appelé depuis une feuille de style. Le corriger ne demande pas de refonte, juste de remonter le fichier dans le HTML et de lui donner un nom de fichier lisible. Un logo-entreprise.svg vaut mieux qu’un img_final_v3.png pour qui doit comprendre ce que montre l’image.
Le sitemap images, l’étape que presque tout le monde saute
Une fois les visuels placés dans le HTML, reste à les déclarer. Google recommande d’envoyer un sitemap pour images, un fichier séparé ou intégré au sitemap classique, dans lequel les éléments image:loc listent les URL des visuels à indexer. Particularité intéressante : contrairement aux sitemaps classiques, ces balises peuvent pointer vers d’autres domaines. Un visuel hébergé sur un CDN ou un sous-domaine reste donc déclarable sans problème.
Cette étape est rarement mentionnée dans les articles qui comparent le poids des formats. Elle compte pourtant davantage sur le long terme. Un logo allégé mais jamais déclaré restera moins visible qu’un fichier plus lourd correctement référencé. Le travail sur le poids et le travail sur l’indexation se complètent, ils ne se remplacent pas.
Les réglages qui font la différence au quotidien
Au-delà des formats, quelques habitudes de production changent vraiment le résultat. Elles ne demandent pas d’outil particulier, juste de la rigueur au moment de l’export et de la mise en ligne. Ce sont souvent ces détails qui séparent un site rapide d’un site qui rame.
- Exporter chaque visuel à la taille maximale où il s’affichera réellement, jamais plus grand « au cas où ».
- Garder un fichier source propre, pour pouvoir régénérer une version allégée sans repartir de zéro.
- Nommer les fichiers avec des mots qui décrivent l’image, pas avec des suites de chiffres.
- Vérifier après mise en ligne que le visuel apparaît bien dans l’inspection d’URL de la console de recherche.
Franchement, la plupart des problèmes de poids viennent d’un export fait à la va-vite un vendredi après-midi, pas d’un manque d’outils. Reprendre le fichier source et le convertir correctement règle souvent en une heure ce que des semaines de compression après coup n’avaient pas résolu.
Reprendre le fichier avant de toucher au reste
Alléger un logo ou une icône ne se joue pas dans un logiciel de compression, mais dans le choix du format au moment où le fichier est créé. Un SVG pour un logo vectoriel, un PNG pour une icône ou une capture d’écran, du WebP ou de l’AVIF pour les visuels lourds : la bonne décision se prend une fois, à la source.
Ensuite vient la déclaration, dans l’attribut src du HTML et dans un sitemap images correctement rempli. Un visuel léger mais non indexé n’apporte rien au référencement. Un visuel lourd mais bien déclaré fait perdre du temps de chargement sans rien gagner en retour. La vraie question reste celle-ci : sur votre site, combien d’images passent encore par une feuille de style ?
