SVG inline : parfait pour une icône, poison pour une illustration

On vous a dit que le SVG est léger et parfaitement net, alors vous le mettez partout et vous collez le code directement dans la page. Cet instinct est juste, pour une loupe de recherche ou une petite flèche. Il devient un piège de performance dès que l'image se complexifie, et une vraie erreur quand ce que vous avez collé n'est même pas un vrai vecteur.

À la fin de ce guide, vous saurez regarder n'importe quel bloc de code SVG et dire, d'un coup d'oeil : celui-là passe très bien en inline, celui-là a sa place dans un fichier externe, ou celui-là n'est même pas un SVG. Ce simple réflexe évite à des pages de doubler de poids pour rien.

Ce que « SVG inline » veut vraiment dire

Il y a deux façons de mettre une image sur une page. D'abord, une balise image qui pointe vers un fichier, comme <img src="logo.svg">. Le navigateur lit la balise, puis va chercher le fichier séparément. Ensuite, un SVG inline : le dessin est écrit en entier, à l'intérieur du code de la page lui-même, chaque trait devenant une ligne de code.

Une analogie. Une balise image est un mot qui dit « la photo est dans le tiroir ». Un SVG inline, c'est recopier toute la recette de la photo, trait par trait, en plein milieu de votre texte.

Donc « inline » n'est ni bon ni mauvais en soi. Tout dépend de la taille de la recette.

Pourquoi une petite icône en inline est exactement ce qu'il faut

Le cas légitime : une loupe de recherche, une flèche, une coche, un petit pictogramme. Quelques traits, une poignée de noeuds. L'inline brille ici.

• Zéro requête réseau supplémentaire. Pas d'aller-retour pour récupérer un fichier de 300 octets, le dessin est déjà là.
• Stylable en CSS. Changez la couleur au survol avec currentColor, animez-le, tout ça gratuitement.
• Visible dès le tout premier rendu, rien à attendre.

Le point de bascule, quand l'inline devient un problème

C'est le coeur du sujet. Trois coûts cachés s'accumulent dès que le dessin cesse d'être une simple icône et devient une véritable illustration.

1. Le DOM explose

Le DOM (Document Object Model) est la liste de chaque élément que le navigateur doit garder en mémoire et recalculer à chaque interaction. Voyez-le comme l'inventaire courant de la page.

Une icône simple ajoute quelques noeuds. Une illustration détaillée exportée depuis un outil de design, c'est des centaines de tracés, donc des centaines de noeuds, pour une seule image. Un outil de mesure comme Lighthouse alerte au-delà d'environ 800 éléments dans la page et considère cela comme excessif au-delà d'environ 1 400. Une illustration mal placée peut ajouter 300 noeuds à elle seule, une grande part du budget, pour rien.

Plus le DOM est gros, plus chaque recalcul de style et de mise en page est lent, plus le scroll et les clics saccadent. Cela touche directement l'interactivité, la métrique INP (Interaction to Next Paint, la vitesse à laquelle la page réagit à un clic ou un toucher).

2. Le temps d'analyse grimpe

Avant de pouvoir afficher quoi que ce soit, le navigateur doit lire et interpréter chaque trait du SVG inline. Multiplié par des centaines de tracés, cela retarde le premier rendu.

Et ce coût est payé sur le thread principal, le même qui répond aux clics. Il se ressent donc partout, pas seulement au chargement.

3. Zéro cache, rechargé sur chaque page

Un SVG inline vit à l'intérieur du code de la page. Il n'est pas mis en cache tout seul. S'il apparaît sur cinq pages, il est re-téléchargé et re-analysé cinq fois. Un fichier .svg externe, en revanche, est téléchargé une seule fois, puis servi depuis le cache sur toutes les autres pages. Il ne bloque pas le rendu, et il peut être chargé en différé quand il se trouve plus bas.

L'analogie : recopier la même recette complète dans chaque chapitre d'un livre, au lieu d'un simple marque-page pointant vers une seule annexe.

Le piège dans le piège, un raster déguisé en SVG

Le pire cas, et étonnamment courant : un PNG ou JPG encodé en base64, collé dans une balise SVG. De l'extérieur, cela se lit comme « un SVG ». En réalité, c'est une photo compressée transformée en texte.

L'indice : si le « SVG » pèse des centaines de kilo-octets et contient une longue chaîne comme data:image/png;base64,iVBOR..., ce n'est pas un SVG. C'est une image raster dans le mauvais tiroir.

<svg width="1200" height="800" ...>
  <image href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...
     ...tens of thousands of characters of encoded photo...
     ...kSuQmCC" width="1200" height="800"/>
</svg>

La correction : ré-exporter un vrai fichier image, idéalement WebP (un format d'image moderne, plus léger que le JPEG ou le PNG), dans une simple balise image, avec largeur et hauteur définies, chargement différé s'il est hors écran, et versions responsives. Ces versions ne sont rentables qu'avec un attribut sizes correct : voir notre guide srcset et sizes.

Un cas réel, anonymisé

Nous avons audité une page d'un site (un build Divi). Rien ne semblait anormal dans l'éditeur, elle « avait juste deux ou trois images » vers le bas.

La correction : le pictogramme en fichier .svg externe (ou un WebP à sa taille réelle), le visuel du podcast en WebP dans une balise image. Page attendue : environ 400 Ko, la moitié du code à télécharger et analyser. Le point clé, c'est que c'est exactement le genre de dérive qu'un audit automatisé fait remonter, alors qu'à l'oeil, dans l'éditeur, « ça ressemble juste à une image ».

La règle de décision, la partie à garder

Une question, trois réponses.

1. Est-ce une photo, une capture d'écran, un rendu réaliste ? Pas un travail pour le SVG. Balise image en WebP, responsive, différée si hors écran.
2. Est-ce du vectoriel, mais grand ou complexe (une grosse illustration, beaucoup de tracés, plus de ~4 Ko une fois optimisé) ? Un fichier .svg externe, référencé par une balise image, préchargé s'il est important et visible tôt.
3. Est-ce une petite icône, peu de noeuds, que vous voulez colorer ou animer en CSS ? L'inline est parfait.

En résumé

Un SVG n'est ni bon ni mauvais. Ce qui compte, c'est le bon format au bon endroit. Les trois mêmes lettres peuvent être une plume ou une enclume selon ce qu'il y a à l'intérieur.

Le réflexe de diagnostic : regarder le poids du bloc et le nombre de tracés, pas seulement son apparence. Un logo qui s'affiche net à l'écran peut tout de même être un raster de 300 Ko déguisé.