Optimiser un fichier SVG sans altérer son rendu

Un fichier SVG peut paraître minuscule à l’écran et pourtant contenir des centaines de lignes de code, des coordonnées à huit décimales, des groupes imbriqués, des métadonnées d’éditeur et des identifiants générés automatiquement. À l’inverse, quelques chemins bien construits peuvent suffire à représenter un logo parfaitement net à toutes les tailles.

Optimiser un SVG consiste donc à chercher une représentation plus simple du même résultat, sans transformer l’optimisation en destruction aveugle.

Le bon objectif n’est pas :

« obtenir le fichier le plus petit possible ».

C’est plutôt :

« obtenir le fichier le plus simple et le plus léger possible tout en conservant exactement ce dont le projet a besoin ».

Cette nuance est essentielle. Un SVG peut dépendre de son viewBox, de références internes, de currentColor, de styles CSS externes, d’un <title> accessible ou d’informations de licence invisibles dans l’aperçu. Une optimisation qui supprime l’un de ces éléments peut produire un fichier plus léger mais moins correct.

Avant d’aller plus loin, si les notions de viewBox, <path>, fill, stroke, <defs> ou SVG inline ne vous sont pas familières, commencez par SVG : comprendre le format vectoriel.

Pourquoi optimiser un SVG ?

Il existe plusieurs raisons, et le poids réseau n’est que la première.

Un SVG optimisé peut être :

• plus léger à transférer ;
• plus rapide à analyser ;
• moins complexe à rendre ;
• plus simple à versionner ;
• plus facile à inspecter ;
• moins encombré de données propres au logiciel de création ;
• plus cohérent avec une chaîne de publication automatisée.

Mais tous les SVG n’ont pas besoin du même niveau d’intervention.

Une icône de 1,8 Ko parfaitement propre ne mérite probablement pas une heure de travail manuel pour gagner 150 octets.

Une illustration de 700 Ko exportée depuis un logiciel graphique, contenant plusieurs milliers de points et une image PNG intégrée, mérite au contraire une véritable analyse.

Commencer par comprendre ce que contient le fichier

L’extension .svg ne vous dit pas si le document est simple.

Ouvrez-le dans un éditeur de texte.

Vous pouvez découvrir quelque chose de très compact :

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path d="..." fill="currentColor"/>
</svg>

Ou au contraire :

<svg ...>
  <metadata>...</metadata>
  <defs>...</defs>
  <g id="Layer_1">
    <g transform="...">
      <path d="..." />
      <path d="..." />
      ...
    </g>
  </g>
</svg>

Le second fichier n’est pas nécessairement mauvais. Il peut réellement avoir besoin de cette structure.

L’optimisation consiste à distinguer :

1. ce qui produit le rendu ;
2. ce qui produit un comportement ;
3. ce qui transmet une information accessible ;
4. ce qui documente ou attribue l’œuvre ;
5. ce qui est uniquement un résidu de production.

Toujours conserver une source maître

Ne faites pas de la version optimisée votre seul exemplaire.

Un fichier de création peut contenir :

• noms de calques ;
• groupes logiques ;
• informations d’éditeur ;
• guides ;
• objets masqués ;
• métadonnées ;
• précision utile à une modification ultérieure.

Une optimisation de diffusion peut supprimer ou réorganiser ces informations.

Adoptez plutôt une séparation :

source de travail
      ↓
SVG exporté
      ↓
optimisation
      ↓
SVG de production

Dans un projet versionné, la source de travail peut vivre ailleurs que dans le bundle Web. L’important est de pouvoir revenir à une version complète.

Cette logique est identique à celle d’une photographie : on conserve l’original et l’on publie une dérivée optimisée. Voir Comment compresser une image sans perdre en qualité ?.

Établir une mesure de référence

Avant de modifier quoi que ce soit, mesurez.

Notez au minimum :

• taille brute ;
• dimensions ou viewBox ;
• nombre approximatif d’éléments ;
• contexte d’intégration ;
• tailles d’affichage ;
• comportement attendu.

Puis ouvrez le fichier :

• seul dans un navigateur ;
• dans le composant réel ;
• sur fond clair ;
• sur fond sombre si nécessaire ;
• à petite taille ;
• à grande taille.

Conservez si possible une capture de référence.

Sans état initial, vous savez que le fichier final est plus petit, mais vous ne savez pas précisément ce que vous avez changé.

Taille brute et taille transférée

Un SVG est du texte XML. Les serveurs modernes peuvent généralement le compresser efficacement lors du transfert.

Supposons :

SVG source : 40 Ko
SVG minifié : 28 Ko

La différence réseau après compression HTTP peut être moins spectaculaire, car les balises et attributs répétitifs se compressent déjà bien.

Cela ne rend pas la minification inutile.

Un document plus simple peut également réduire :

• le parsing ;
• la taille du HTML lorsqu’il est inline ;
• la complexité du DOM ;
• la maintenance.

Mais lorsque vous évaluez un gain de performance, mesurez aussi les octets réellement transférés.

Le futur guide Optimiser les images pour les performances Web replacera ces gains dans une stratégie complète.

Première catégorie : supprimer les commentaires inutiles

Un commentaire XML :

<!-- Created with Example Designer 12 -->

ne modifie pas le dessin.

Dans une version de production, il peut généralement disparaître.

Même chose pour des commentaires de travail :

<!-- TODO: revoir la couleur -->

Mais attention aux mentions importantes.

Un commentaire peut contenir :

• attribution ;
• copyright ;
• licence ;
• instruction de maintenance.

Avant de supprimer automatiquement tous les commentaires, assurez-vous que les informations nécessaires sont conservées ailleurs.

Le frontmatter, un fichier LICENSE, une base de crédits ou une page de mentions peut être plus robuste qu’un commentaire interne, mais la migration doit être volontaire.

Deuxième catégorie : examiner <metadata>

Un SVG peut contenir :

<metadata>
  ...
</metadata>

Ces données peuvent provenir :

• du logiciel graphique ;
• d’un standard de métadonnées ;
• d’une licence ;
• d’informations d’auteur.

Pour le rendu visuel, elles sont souvent inutiles.

Pour la documentation ou les obligations juridiques, elles peuvent être importantes.

Ne posez donc pas la question :

« Puis-je supprimer <metadata> ? »

Posez plutôt :

« Ai-je encore besoin des informations contenues dans <metadata> après publication ? »

Si oui, conservez-les dans le fichier ou migrez-les vers un système approprié avant nettoyage.

Cette question rejoint le futur article Métadonnées d’image : les lire, les conserver ou les supprimer.

Données propres aux logiciels graphiques

Les logiciels de création cherchent à préserver l’éditabilité.

Ils peuvent ajouter :

• espaces de noms spécifiques ;
• noms de calques ;
• identifiants internes ;
• attributs de document ;
• guides ;
• informations de version ;
• données de grille.

Ces éléments peuvent être précieux dans la source maître mais inutiles dans le fichier livré.

Un optimiseur peut en supprimer une partie.

La bonne pratique est donc :

• source complète conservée ;
• version de production nettoyée.

Ainsi, l’optimisation Web n’endommage pas le workflow créatif.

Minifier le XML

La minification supprime notamment :

• indentation ;
• retours à la ligne inutiles ;
• espaces superflus.

Un fichier :

<svg viewBox="0 0 24 24">
  <path
    d="..."
    fill="#000000"
  />
</svg>

peut devenir :

<svg viewBox="0 0 24 24"><path d="..." fill="#000"/></svg>

Le rendu est identique.

Mais le fichier devient moins agréable à lire.

Pour un SVG généré lors du build, ce compromis est généralement acceptable.

Pour un SVG maintenu manuellement dans le code source, conserver une version lisible puis minifier à la construction peut être préférable.

Ne pas confondre lisibilité source et efficacité de production

Il n’est pas nécessaire que le fichier versionné soit illisible pour que le navigateur reçoive une version compacte.

Une chaîne de build peut produire :

SVG lisible
   ↓
optimiseur
   ↓
SVG minifié de production

Cette approche permet :

• revue de code plus claire ;
• diffs Git compréhensibles ;
• production optimisée.

C’est souvent préférable à la modification manuelle d’une longue chaîne de coordonnées minifiées.

Réduire la précision numérique

Les exports vectoriels contiennent parfois des coordonnées telles que :

24.000137
18.999846
31.452816

Cette précision peut venir des calculs internes du logiciel.

À l’échelle d’une icône, elle est souvent excessive.

Une version réduite pourrait devenir :

24
19
31.45

Sur des milliers de coordonnées, le gain peut être important.

Mais contrairement à la suppression d’un commentaire, cette opération modifie les données géométriques.

Elle doit donc être testée.

Pourquoi une décimale peut-elle changer le rendu ?

Imaginez deux formes censées se toucher exactement.

L’une termine à :

10.004

et l’autre commence à :

10.006

Une transformation peut arrondir différemment les coordonnées.

À certaines tailles, cela peut créer :

• une fente ;
• un chevauchement ;
• une ligne parasite.

Les petites icônes sont particulièrement sensibles parce qu’un déplacement minuscule dans le repère peut affecter la rasterisation sur quelques pixels seulement.

Quelle précision choisir ?

Il n’existe pas de chiffre universel.

Une stratégie raisonnable consiste à tester progressivement :

4 décimales
3 décimales
2 décimales
1 décimale

et à s’arrêter avant que le rendu ne soit affecté.

Pour une illustration simple, deux décimales peuvent être largement suffisantes.

Pour :

• dessin technique ;
• courbes précises ;
• géométrie complexe ;
• petites icônes ;
• formes imbriquées ;

une précision supérieure peut être nécessaire.

Le bon nombre est celui validé sur votre fichier, pas celui trouvé dans une règle générique.

Tester la précision à plusieurs tailles

Un piège fréquent consiste à comparer uniquement le SVG agrandi.

Une petite erreur peut être invisible à 800 px mais produire un mauvais alignement à 16 px.

Testez donc :

• taille minimale réelle ;
• taille habituelle ;
• grande taille.

Pour une icône :

16 px
24 px
32 px
64 px

peut être une série pertinente.

Pour un logo, utilisez les dimensions réellement prévues dans l’interface.

Simplifier les chemins

Les chemins sont souvent la partie la plus volumineuse d’un SVG.

Un tracé peut contenir :

• points redondants ;
• segments presque alignés ;
• commandes répétées ;
• coordonnées exprimées de manière peu compacte.

Un optimiseur peut essayer de représenter le même dessin avec moins d’informations.

Le gain peut être considérable.

Mais la simplification des paths est une opération géométrique : elle doit être considérée comme plus risquée que la suppression de métadonnées.

Commandes absolues et relatives

Un chemin peut utiliser des coordonnées absolues :

M10 10 L20 10 L20 20

ou des déplacements relatifs :

M10 10 l10 0 v10

Selon les coordonnées, l’une des représentations peut être plus courte.

Les optimiseurs peuvent convertir entre elles.

Pour un fichier de production, cette réécriture est généralement acceptable si le rendu est strictement préservé.

Pour un fichier édité manuellement, elle peut rendre le path plus difficile à comprendre.

Encore une fois, source et artefact de production n’ont pas forcément les mêmes besoins.

Courbes de Bézier et simplification

Les courbes de Bézier utilisent des points de contrôle.

Une modification légère peut changer :

• tension ;
• tangente ;
• forme d’un arrondi.

Sur un logo, ce changement peut être inacceptable même s’il est difficile à voir au premier coup d’œil.

Pour une identité graphique, ne validez donc pas une simplification uniquement parce qu’un aperçu rapide semble correct.

Comparez précisément :

• contours ;
• intersections ;
• symétries ;
• angles ;
• extrémités.

Supprimer les points inutiles

Une vectorisation automatique d’un dessin peut produire une quantité excessive de points.

C’est fréquent lorsque l’on vectorise :

• dessin scanné ;
• signature ;
• silhouette ;
• photographie simplifiée.

Dans ce cas, l’optimisation automatique du XML ne suffit pas toujours.

Le meilleur gain peut venir d’une simplification du dessin dans l’outil vectoriel avant export.

Une courbe avec 200 points n’a peut-être besoin que de 30 points pour paraître identique.

Cette étape demande davantage de jugement graphique, mais peut transformer radicalement le fichier.

Convertir certaines formes en chemins ?

Un optimiseur peut convertir :

<rect>
<circle>
<polygon>

en <path> lorsque cela produit moins de caractères.

Cela peut réduire légèrement le poids.

Mais les primitives ont des avantages :

• elles sont lisibles ;
• faciles à modifier ;
• sémantiquement explicites pour un développeur.

Pour quelques octets, la conversion n’est pas toujours souhaitable dans la source.

Dans un artefact minifié généré automatiquement, le compromis peut être différent.

Fusionner des chemins

Deux paths partageant les mêmes styles peuvent parfois être fusionnés.

Cela réduit :

• nombre d’éléments ;
• répétition d’attributs.

Mais une fusion peut affecter :

• ordre de peinture ;
• règles de remplissage ;
• interaction ;
• ciblage CSS ;
• animation.

Si des chemins possèdent des identifiants ou sont manipulés séparément, ne les fusionnez pas aveuglément.

Groupes <g> inutiles

Un logiciel peut générer :

<g>
  <g>
    <g>
      <path ... />
    </g>
  </g>
</g>

Si les groupes :

• n’appliquent aucun style ;
• n’appliquent aucune transformation ;
• ne portent aucun identifiant utile ;
• ne servent pas à l’interaction ;

ils peuvent être supprimés.

Mais un groupe apparemment inutile dans le fichier isolé peut être ciblé par CSS ou JavaScript lorsque le SVG est inline.

Le contexte d’intégration doit donc être connu avant optimisation.

Héritage des styles

Au lieu de répéter :

<path fill="#2457D6" ... />
<path fill="#2457D6" ... />
<path fill="#2457D6" ... />

on peut parfois écrire :

<g fill="#2457D6">
  <path ... />
  <path ... />
  <path ... />
</g>

Cela réduit la duplication.

À l’inverse, certaines optimisations peuvent déplacer des styles du groupe vers les enfants.

Le résultat visuel peut rester identique, mais les règles de cascade et les possibilités de surcharge externe doivent être vérifiées.

currentColor : ne pas casser la personnalisation

Une icône peut utiliser :

<path fill="currentColor" d="..." />

et recevoir sa couleur depuis :

.icon {
  color: #2457D6;
}

Si un optimiseur remplace currentColor par une couleur fixe issue du contexte de test, vous perdez la capacité de personnalisation.

C’est particulièrement problématique pour :

• boutons ;
• composants ;
• thèmes clair/sombre ;
• états interactifs.

L’optimisation ne doit pas transformer une propriété fonctionnelle en valeur figée.

Pour travailler sur les couleurs, le convertisseur de couleurs peut aider à vérifier les équivalences.

Raccourcir les couleurs

Certaines couleurs peuvent être représentées plus brièvement.

Par exemple :

#ffffff

peut devenir :

#fff

sans modifier la couleur.

D’autres conversions peuvent choisir une syntaxe plus courte.

Ces gains sont modestes individuellement mais faciles à appliquer automatiquement.

Ils doivent toutefois respecter :

• compatibilité ciblée ;
• variables ;
• currentColor ;
• styles externes.

Supprimer des valeurs par défaut

SVG possède des valeurs par défaut.

Certains attributs explicitement écrits peuvent donc être inutiles.

Un optimiseur peut les retirer lorsque leur absence produit exactement le même comportement.

Mais la prudence s’impose si le fichier :

• est intégré inline ;
• hérite de styles ;
• est manipulé dynamiquement.

Une valeur qui paraît redondante dans un document autonome peut protéger le SVG contre l’héritage du contexte.

viewBox : l’attribut à protéger

Un SVG :

<svg viewBox="0 0 120 80">

définit son repère interne.

Supprimer ou modifier incorrectement le viewBox peut provoquer :

• mauvais redimensionnement ;
• contenu coupé ;
• changement de ratio ;
• perte du comportement responsive.

Une optimisation de quelques caractères ne justifie presque jamais de casser ce mécanisme.

Le fonctionnement détaillé du viewBox est expliqué dans SVG : comprendre le format vectoriel.

width et height : ne pas appliquer une règle automatique

Certaines recettes recommandent de supprimer systématiquement :

width="..."
height="..."

lorsqu’un viewBox existe.

Cela peut être utile dans certains composants fluides.

Mais ce n’est pas une règle universelle.

Les dimensions peuvent participer :

• à la taille intrinsèque ;
• au comportement lorsque CSS n’est pas chargé ;
• à certains usages autonomes.

Et lorsque le SVG est chargé avec <img>, les dimensions du HTML peuvent aider à réserver l’espace et éviter les décalages de mise en page.

Décidez donc selon l’intégration réelle.

preserveAspectRatio

Cet attribut contrôle la manière dont le viewBox s’adapte à une zone dont le ratio diffère.

Une optimisation qui le supprime parce qu’elle considère sa valeur comme « habituelle » doit garantir que le comportement par défaut est réellement celui recherché.

Pour des SVG utilisant :

preserveAspectRatio="none"

le retrait changerait clairement le dessin en rétablissant la conservation des proportions.

Les identifiants : petits caractères, grandes conséquences

SVG utilise id pour de nombreux mécanismes.

Exemple :

<linearGradient id="brand-gradient">
  ...
</linearGradient>

puis :

<path fill="url(#brand-gradient)" ... />

Un optimiseur peut vouloir raccourcir :

brand-gradient

en :

a

C’est possible si toutes les références sont mises à jour.

Mais les identifiants peuvent également être utilisés depuis :

• CSS ;
• JavaScript ;
• ARIA ;
• fragments d’URL ;
• code externe.

Un renommage purement local peut alors casser l’intégration.

Collisions d’identifiants inline

Supposons deux SVG inline :

<linearGradient id="a">...</linearGradient>

dans chacun.

Une fois insérés dans le même document HTML, les identifiants ne sont plus nécessairement aussi isolés qu’ils l’étaient dans deux fichiers distincts.

Les références peuvent devenir ambiguës ou pointer vers la mauvaise définition.

Ce problème touche souvent les exports contenant des noms génériques :

clip0
mask0
gradient0

Si votre build inline plusieurs SVG, prévoyez :

• préfixes ;
• identifiants uniques ;
• transformation contrôlée au build.

Ne raccourcissez pas tous les identifiants de tous les fichiers de la même manière sans réfléchir au DOM final.

<defs> : ne pas supprimer une définition utilisée indirectement

Les éléments de <defs> ne sont généralement pas visibles directement.

Un outil naïf pourrait donc les considérer comme inutiles.

Mais ils peuvent être référencés par :

• fill="url(#...)" ;
• stroke ;
• clip-path ;
• mask ;
• filter ;
• <use> ;
• marqueurs.

Une analyse correcte doit suivre ces références.

Supprimer une définition parce qu’elle ne dessine rien directement peut détruire une partie du rendu.

Dégradés

Les dégradés peuvent contenir plusieurs <stop>.

Un optimiseur peut parfois :

• supprimer des attributs redondants ;
• raccourcir des couleurs ;
• fusionner certaines informations.

Mais attention aux héritages et références.

Un changement minime de position d’un stop peut être visible sur une grande surface.

Les gradients de marque doivent être comparés avec soin.

Masques et clipPath

Les masques et chemins de découpe sont des zones sensibles.

Une optimisation géométrique agressive peut produire :

• bord différent ;
• débordement ;
• halo ;
• artefact à certaines tailles.

Testez particulièrement :

• zoom ;
• haute densité ;
• fond contrasté.

Un défaut presque invisible sur fond blanc peut devenir évident sur fond sombre.

Filtres

Les filtres SVG peuvent être coûteux et leurs zones de calcul dépasser la forme visible.

Une ombre peut être coupée si une optimisation modifie :

• cadrage ;
• région du filtre ;
• coordonnées ;
• dimensions.

Avant de supprimer ou modifier des attributs liés aux filtres, vérifiez le rendu sur les bords.

Si un filtre complexe n’apporte qu’une ombre simple, il peut parfois être remplacé par une technique plus légère, mais cela devient alors une refonte graphique, pas une optimisation strictement équivalente.

Supprimer les éléments invisibles

Un fichier peut contenir des formes :

• display:none ;
• masquées ;
• hors du cadrage ;
• recouvertes ;
• utilisées uniquement pour l’édition.

Certaines peuvent être supprimées.

Mais « invisible dans l’aperçu » ne signifie pas nécessairement « inutile ».

Un élément peut servir :

• à une animation ;
• à un état interactif ;
• à un masque ;
• à un <use> ;
• à JavaScript.

La suppression automatique doit donc connaître le contexte.

Images raster intégrées

Voici un cas particulièrement important :

<image
  href="data:image/png;base64,..."
/>

Le SVG contient alors une image matricielle encodée.

Le fichier peut peser des centaines de kilo-octets ou plusieurs mégaoctets.

Supprimer les commentaires n’aura presque aucun effet.

Il faut traiter la cause principale.

Posez-vous les questions suivantes :

• cette image doit-elle être intégrée ?
• peut-elle être servie séparément ?
• peut-elle être compressée ?
• faut-il utiliser WebP ou AVIF ?
• le document devrait-il finalement être raster ?

Le convertisseur d’images et PNG, JPEG, WebP ou AVIF : quel format choisir ? sont alors plus pertinents qu’une optimisation purement XML.

Base64 et poids

Encoder un fichier binaire en base64 augmente sa représentation textuelle.

La compression HTTP peut récupérer une partie de ce coût, mais l’intégration empêche également de gérer la ressource de manière totalement indépendante.

Si la même photographie apparaît dans plusieurs SVG, vous risquez de répéter les données.

Pour une ressource raster volumineuse, un fichier externe est souvent plus flexible.

Accessibilité : <title> n’est pas du déchet

Un SVG inline informatif peut contenir :

<svg
  role="img"
  aria-labelledby="chart-title"
>
  <title id="chart-title">
    Évolution des ventes de janvier à juin
  </title>
  ...
</svg>

Si l’optimiseur supprime <title>, il peut casser le nom accessible.

Si l’optimiseur renomme son id sans mettre à jour aria-labelledby, même problème.

La réduction de poids ne doit jamais primer sur l’information accessible.

Et <desc> ?

<desc> peut apporter une description complémentaire.

Son utilité dépend :

• du contenu ;
• du contexte ;
• de la stratégie d’accessibilité.

Ne conservez pas automatiquement des descriptions inutiles générées par un logiciel.

Mais si elles ont été écrites volontairement pour transmettre une information, leur suppression doit être considérée comme une modification fonctionnelle.

SVG chargé via <img>

Lorsqu’un SVG est utilisé ainsi :

<img src="/images/chart.svg" alt="...">

l’alternative principale est fournie par alt.

Un <title> interne peut donc ne pas jouer le même rôle que dans un SVG inline.

C’est pourquoi l’optimiseur ne peut pas déterminer la bonne politique d’accessibilité uniquement en regardant le fichier.

Il doit connaître le mode d’intégration.

SVG décoratif

Un SVG inline décoratif peut être marqué :

aria-hidden="true"

Dans ce cas, un <title> généré automatiquement par l’éditeur peut être inutile et même contre-productif.

L’optimisation peut donc aussi améliorer la propreté sémantique, à condition que la décision soit volontaire.

Contraste : vérifier après optimisation des couleurs

Si une optimisation réécrit des couleurs, le résultat doit rester strictement équivalent.

Pour un élément fonctionnel ou informatif, vérifiez également son contraste dans le contexte final.

L’outil de contraste WCAG permet de tester deux couleurs et le guide Contraste WCAG : comment rendre les couleurs accessibles ? explique les principes.

L’optimisation ne doit pas devenir une excuse pour modifier légèrement une teinte de marque afin de gagner quelques caractères.

Sécurité : optimisation ≠ assainissement

C’est l’une des distinctions les plus importantes.

Un optimiseur cherche à :

• supprimer des données inutiles ;
• simplifier ;
• minifier.

Un sanitizer cherche à appliquer une politique de sécurité à un document potentiellement hostile.

Ce n’est pas le même objectif.

Un SVG provenant d’un utilisateur inconnu ne devient pas fiable parce qu’il a été minifié.

Pourquoi supprimer <script> ne suffit pas ?

SVG est un langage documentaire riche.

Une politique de sécurité peut devoir contrôler :

• éléments ;
• attributs événementiels ;
• URL ;
• ressources externes ;
• styles ;
• namespaces ;
• références ;
• contenus actifs.

Une expression régulière cherchant :

<script

n’est donc pas une stratégie d’assainissement complète.

Pour un SVG non fiable, utilisez une solution spécifiquement conçue et maintenue pour ce contexte.

L’optimiseur SVG de Bethemesh

L’optimiseur SVG permet de travailler sur un SVG localement et d’expérimenter plusieurs transformations.

Le principe recommandé est :

1. conserver l’original ;
2. charger une copie ;
3. commencer par les transformations les moins risquées ;
4. observer le poids ;
5. comparer le rendu ;
6. augmenter progressivement l’agressivité si nécessaire ;
7. tester le fichier obtenu dans le composant réel.

Un outil d’optimisation doit être considéré comme une aide au workflow, pas comme une autorisation à valider automatiquement tout résultat plus petit.

Ordre recommandé des optimisations

Pour limiter les risques, procédez du plus sûr au plus sensible.

Niveau 1 — nettoyage documentaire

Commencez par :

• commentaires inutiles ;
• métadonnées non nécessaires ;
• données d’éditeur inutiles ;
• espaces superflus.

Risque généralement faible.

Niveau 2 — simplification syntaxique

Ensuite :

• valeurs raccourcies ;
• attributs réellement redondants ;
• couleurs compactes ;
• structures XML simplifiables.

Risque faible à modéré selon l’intégration.

Niveau 3 — optimisation structurelle

Puis :

• groupes inutiles ;
• styles factorisés ;
• paths fusionnés ;
• identifiants raccourcis.

Risque modéré.

Niveau 4 — optimisation géométrique

Enfin :

• réduction de précision ;
• simplification des tracés ;
• transformations géométriques.

Risque plus élevé.

Cette progression facilite le diagnostic : si le rendu casse, vous savez à quelle famille de transformations revenir.

Comparaison visuelle côte à côte

Placez l’original et la version optimisée dans les mêmes conditions :

original | optimisé

Comparez :

• contours ;
• angles ;
• courbes ;
• couleurs ;
• transparence ;
• ombres ;
• alignements.

Utilisez les tailles réelles.

Une comparaison à 1000 % peut révéler des différences techniquement présentes mais totalement invisibles dans l’usage. À l’inverse, une petite icône doit absolument être testée à sa taille réelle.

Superposition des rendus

Pour les ressources sensibles, une technique efficace consiste à superposer :

• original ;
• optimisé.

En alternant rapidement leur visibilité ou en utilisant un mode de différence dans un outil graphique, les écarts deviennent plus faciles à détecter.

Cette méthode est particulièrement utile pour :

• logos ;
• icônes ;
• illustrations de marque.

Elle permet de distinguer une vraie différence d’une simple impression visuelle.

Tester sur fond clair et sombre

Un artefact de bord peut être invisible sur un fond proche de sa couleur.

Testez donc un SVG transparent sur plusieurs arrière-plans.

Par exemple :

blanc
gris
noir
couleur de marque

Cela permet de repérer :

• halos ;
• contours ;
• fentes ;
• pixels issus de la rasterisation.

Même un document vectoriel est finalement rasterisé par l’écran.

Tester le zoom

Le zoom navigateur peut révéler des problèmes de :

• contours ;
• alignement ;
• clipping.

Testez plusieurs niveaux, sans rechercher une perfection artificielle à chaque facteur fractionnaire : la rasterisation peut produire de petites variations normales.

Ce qui compte est l’absence de dégradation significative introduite par l’optimisation.

Tester le contexte final

C’est indispensable.

Un SVG parfait lorsqu’il est ouvert seul peut casser lorsqu’il est :

• inline ;
• dans un bouton ;
• coloré avec currentColor ;
• animé ;
• intégré dans un thème sombre ;
• dupliqué plusieurs fois.

Le test final doit donc se faire dans l’application, pas seulement dans l’outil d’optimisation.

Automatiser sans perdre le contrôle

Sur un site contenant quelques SVG, une optimisation manuelle peut suffire.

Sur un projet contenant des centaines d’icônes, il vaut mieux automatiser.

Un pipeline peut :

1. prendre les SVG source ;
2. appliquer une configuration versionnée ;
3. produire les fichiers de distribution ;
4. exécuter des tests ;
5. comparer les résultats.

L’intérêt est la reproductibilité.

Chaque développeur n’optimise pas les fichiers avec des réglages différents.

Versionner la configuration

Si vous utilisez un optimiseur dans le build, sa configuration fait partie de votre architecture.

Versionnez :

• options ;
• précision ;
• politique d’identifiants ;
• plugins actifs ;
• exceptions.

Une mise à jour de l’outil peut modifier son comportement.

Les changements doivent donc être traités comme une évolution de dépendance susceptible d’affecter les assets.

Tests visuels automatisés

Pour une bibliothèque d’icônes importante, des tests de captures peuvent détecter les régressions.

Le principe :

SVG source / référence
        ↓
rendu
        ↓
capture
        ↓
comparaison

Un seuil de tolérance peut être nécessaire à cause des différences de rasterisation.

L’objectif n’est pas d’obtenir zéro pixel différent dans toutes les circonstances, mais de détecter les modifications visuelles significatives.

Tests structurels

En complément, des tests peuvent vérifier :

• présence du viewBox ;
• absence de certaines métadonnées ;
• absence d’images base64 au-delà d’une politique donnée ;
• unicité des identifiants ;
• poids maximal ;
• absence de dimensions interdites selon votre convention.

Ces tests sont particulièrement efficaces pour éviter le retour de mauvaises pratiques.

Définir un budget

Plutôt que de chercher à optimiser chaque fichier au maximum, fixez des budgets.

Exemple fictif :

icône simple       < 5 Ko
logo               < 20 Ko
illustration       < 100 Ko

Ces valeurs ne sont pas universelles.

Elles servent à déclencher une inspection lorsqu’un asset sort de l’ordinaire.

Un budget est plus utile qu’une règle comme :

« chaque SVG doit être réduit de 50 % ».

Un SVG déjà propre ne peut pas nécessairement perdre 50 % sans détérioration.

Ne pas optimiser pour un pourcentage

Supposons :

original : 4 Ko
optimisé : 3,5 Ko

Le gain est seulement 12,5 %.

Cela peut être parfaitement satisfaisant.

À l’inverse :

original : 800 Ko
optimisé : 300 Ko

semble impressionnant, mais 300 Ko peuvent encore être excessifs pour une petite illustration.

Jugez le résultat absolu et son usage, pas uniquement le pourcentage.

Quand faut-il redessiner plutôt qu’optimiser ?

Un fichier peut être structurellement mauvais.

Exemples :

• logo vectorisé depuis une image basse résolution ;
• des milliers de points pour une forme simple ;
• formes dupliquées inutilement ;
• raster énorme encapsulé dans SVG ;
• géométrie issue d’un export défectueux.

Dans ces situations, la meilleure optimisation peut être de revenir dans l’outil graphique et de reconstruire proprement le dessin.

Un optimiseur ne peut pas toujours réparer une mauvaise modélisation.

Quand faut-il abandonner SVG ?

Si le document est essentiellement photographique, le vectoriel n’est probablement pas le bon format.

Comparez avec :

• JPEG ;
• WebP ;
• AVIF ;
• PNG lorsque nécessaire.

Le guide PNG, JPEG, WebP ou AVIF : quel format choisir ? aide à prendre cette décision.

Le convertisseur d’images permet ensuite de comparer des sorties raster.

SVG et images responsives

Un SVG vectoriel n’a généralement pas besoin de plusieurs densités uniquement pour rester net.

Cela ne signifie pas qu’il résout tous les problèmes d’images responsives.

Une illustration complexe peut nécessiter :

• une composition mobile ;
• une version simplifiée ;
• un cadrage différent.

Le futur guide Images responsives : comprendre srcset et sizes expliquera pourquoi le choix de résolution et l’art direction sont deux sujets différents.

SVG et performance globale de la page

Un fichier de 5 Ko peut encore être coûteux s’il contient énormément d’éléments ou un filtre complexe.

Inversement, un SVG externe légèrement plus lourd peut être mis en cache et réutilisé sur plusieurs pages.

Pour décider, considérez :

• transfert ;
• parsing ;
• rendu ;
• cache ;
• répétition ;
• interaction.

L’optimisation d’assets doit être reliée à la performance de la page entière, pas isolée dans un concours du plus petit fichier.

SVG inline et poids HTML

Un SVG de 10 Ko utilisé inline dix fois dans une page peut ajouter beaucoup de balisage au document.

Même si la compression réseau réduit les répétitions, le navigateur doit construire les éléments correspondants.

Selon le cas, envisagez :

• composant réutilisable ;
• sprite ;
• fichier externe ;
• <use>.

La bonne solution dépend du besoin de style et d’interaction.

SVG externe et cache

Un fichier chargé par <img> peut être mis en cache séparément.

Si le même logo apparaît sur de nombreuses pages, cette réutilisation est avantageuse.

Ne passez donc pas systématiquement tout en inline dans le seul but d’éviter une requête.

Les protocoles modernes, le cache et la taille du HTML changent l’équation.

Core Web Vitals

Optimiser un SVG peut contribuer à réduire le temps de chargement, mais les Core Web Vitals dépendent de nombreux facteurs.

Pour une image importante au-dessus de la ligne de flottaison :

• son mode de découverte ;
• sa priorité ;
• ses dimensions ;
• son emplacement ;
• le CSS ;
• le serveur

peuvent compter davantage que quelques centaines d’octets économisés.

Pour éviter le CLS, réservez correctement l’espace lorsque le SVG fait partie du contenu.

Le futur article Optimiser les images pour les performances Web détaillera cette vision d’ensemble.

Licences et crédits

Une optimisation peut retirer des données de licence intégrées.

Cela ne supprime évidemment pas vos obligations.

Avant de nettoyer un fichier tiers :

1. identifiez sa licence ;
2. vérifiez les conditions d’attribution ;
3. stockez les crédits dans un emplacement pérenne ;
4. assurez-vous que le build ne les fait pas disparaître involontairement.

Le fichier le plus léger n’est pas un objectif légitime s’il vous fait perdre les informations nécessaires au respect de la licence.

Confidentialité et informations d’éditeur

Des métadonnées ou noms de calques peuvent révéler :

• nom d’un auteur ;
• nom d’un projet interne ;
• chemin de travail ;
• logiciel utilisé ;
• commentaires.

Le nettoyage peut donc avoir un intérêt de confidentialité.

Mais ne supposez pas qu’un optimiseur supprime toutes les informations potentiellement sensibles.

Inspectez le fichier et définissez une politique de publication.

Le futur guide Métadonnées d’image : les lire, les conserver ou les supprimer approfondira ce point.

Checklist d’optimisation manuelle

Avant :

• conserver l’original ;
• mesurer la taille ;
• identifier le contexte d’intégration ;
• vérifier la licence ;
• capturer un rendu de référence.

Pendant :

• supprimer d’abord les données non visuelles inutiles ;
• minifier ;
• simplifier progressivement ;
• réduire la précision avec prudence ;
• surveiller les IDs ;
• préserver le viewBox ;
• conserver l’accessibilité.

Après :

• comparer visuellement ;
• tester plusieurs tailles ;
• tester plusieurs fonds ;
• tester le composant réel ;
• contrôler le nom accessible ;
• mesurer le poids transféré ;
• vérifier la console ;
• conserver les crédits.

Checklist pour un pipeline automatisé

Un pipeline mature devrait idéalement :

• utiliser une configuration versionnée ;
• traiter uniquement les fichiers prévus ;
• conserver les sources ;
• produire des sorties reproductibles ;
• fixer des budgets ;
• vérifier le viewBox ;
• contrôler les identifiants selon l’architecture ;
• préserver les éléments d’accessibilité requis ;
• empêcher les images base64 inattendues ;
• lancer des tests visuels sur les ressources sensibles ;
• permettre des exceptions documentées.

L’automatisation est utile lorsqu’elle encode une politique réfléchie. Elle devient dangereuse lorsqu’elle applique des transformations agressives sans contexte.

Procédure pratique avec Bethemesh

Pour optimiser un fichier ponctuellement :

1. conservez votre SVG original ;
2. ouvrez l’optimiseur SVG ;
3. chargez ou collez le contenu ;
4. commencez avec le nettoyage des commentaires et données inutiles ;
5. observez la différence de taille ;
6. réduisez la précision seulement si nécessaire ;
7. comparez l’aperçu ;
8. récupérez la version optimisée ;
9. testez-la dans le composant final.

Si vous constatez que le fichier contient principalement un raster, arrêtez-vous et réévaluez le format avec PNG, JPEG, WebP ou AVIF.

Si votre travail porte surtout sur les couleurs, utilisez le convertisseur de couleurs et vérifiez le résultat avec l’outil de contraste WCAG.

Exemple de diagnostic : une icône de 80 Ko

Imaginez une icône de 24 × 24 affichée dans un bouton, mais pesant 80 Ko.

Inspection :

12 000 points
métadonnées d’éditeur
6 décimales
plusieurs groupes

Le principal problème n’est probablement pas le commentaire de 50 octets.

Priorités :

1. revenir au dessin ;
2. réduire le nombre de points ;
3. nettoyer la structure ;
4. ajuster la précision ;
5. minifier.

Après reconstruction, le fichier peut potentiellement tomber à quelques kilo-octets.

Le gain vient de la géométrie, pas seulement du XML.

Exemple de diagnostic : un SVG de 400 Ko avec photo

Inspection :

<image href="data:image/png;base64,..."/>

La majorité du poids vient de la photographie.

Priorités :

1. extraire le raster ;
2. déterminer son rôle ;
3. le redimensionner ;
4. choisir un format adapté ;
5. décider s’il doit rester intégré.

Le redimensionneur d’images et le convertisseur d’images deviennent alors plus utiles que la simplification des paths.

Exemple de diagnostic : logo de 6 Ko

Le logo :

• possède un viewBox correct ;
• contient quatre paths ;
• n’a pas de métadonnées ;
• utilise deux couleurs ;
• pèse 6 Ko.

Une optimisation agressive permettant de gagner 700 octets n’est peut-être pas nécessaire si elle augmente le risque sur un asset de marque.

La meilleure décision peut être de ne rien changer.

Savoir ne pas optimiser davantage fait partie de l’optimisation.

Exemple de diagnostic : bibliothèque de 500 icônes

Ici, un gain moyen de seulement :

500 octets × 500

représente :

250 000 octets

sur l’ensemble des sources.

Mais toutes les icônes ne sont pas nécessairement chargées simultanément.

Le principal bénéfice de l’automatisation peut être :

• cohérence ;
• budgets ;
• suppression de résidus ;
• détection des anomalies.

Ne raisonnez pas uniquement en additionnant la taille de tout le dépôt.

Les erreurs à éviter

Optimiser l’unique copie

Vous perdez potentiellement des informations de travail.

Supprimer le viewBox

Vous risquez de casser le redimensionnement.

Supprimer tous les IDs

Les gradients, masques, ARIA ou scripts peuvent en dépendre.

Raccourcir les IDs sans contexte

Les références externes ou collisions inline peuvent casser.

Supprimer <title> automatiquement

Vous pouvez dégrader l’accessibilité.

Modifier currentColor

Vous pouvez casser les thèmes et composants.

Réduire trop fortement la précision

Les petites formes et courbes peuvent se déformer.

Se fier uniquement au poids

Un SVG léger peut rester complexe à rendre.

Se fier uniquement à l’aperçu isolé

Le fichier peut casser une fois inline.

Confondre optimisation et sécurité

Un SVG plus petit n’est pas nécessairement sûr.

Oublier les licences

Les crédits restent obligatoires même après suppression des métadonnées.

Garder une photo en base64 sans réfléchir

Vous pouvez utiliser SVG comme un conteneur inutilement lourd.

Ce qu’il faut retenir

Une bonne optimisation SVG suit une hiérarchie.

Commencez par ce qui ne modifie pas le dessin :

• commentaires inutiles ;
• métadonnées non nécessaires ;
• données d’éditeur ;
• espaces.

Passez ensuite aux transformations syntaxiques et structurelles.

N’attaquez la géométrie — précision, simplification de paths — qu’après avoir établi une référence visuelle.

Et tout au long du processus, protégez :

• viewBox ;
• références internes ;
• styles nécessaires ;
• currentColor ;
• accessibilité ;
• licences ;
• sécurité du contexte d’intégration.

Le meilleur SVG n’est pas nécessairement celui qui possède le moins d’octets.

C’est celui qui contient le minimum nécessaire pour remplir correctement sa fonction.

Après cette optimisation vectorielle, la suite logique de la collection consiste à élargir la réflexion : Images responsives : comprendre srcset et sizes, Métadonnées d’image : les lire, les conserver ou les supprimer, puis Optimiser les images pour les performances Web.

Questions fréquentes

Combien peut-on gagner en optimisant un SVG ?

Cela dépend entièrement de la source. Un SVG déjà propre peut ne perdre que quelques pourcents. Un export rempli de métadonnées, de points inutiles ou de structures redondantes peut être réduit beaucoup plus fortement.

Quelle précision décimale faut-il utiliser ?

Il n’existe pas de valeur universelle. Deux ou trois décimales conviennent souvent à des formes simples, mais certains dessins exigent davantage. Testez toujours les tailles réelles.

Puis-je supprimer tous les commentaires ?

Les commentaires purement techniques ou d’éditeur peuvent généralement disparaître. Vérifiez auparavant qu’ils ne contiennent ni licence, ni attribution, ni information de maintenance nécessaire.

Puis-je supprimer <metadata> ?

Oui pour le rendu si ces données ne sont pas nécessaires, mais elles peuvent contenir des informations juridiques ou documentaires. Conservez-les ailleurs lorsque nécessaire.

Faut-il toujours minifier un SVG ?

Pour une ressource de production générée automatiquement, la minification est souvent pertinente. Pour un fichier maintenu à la main, vous pouvez conserver une source lisible et minifier au build.

Faut-il supprimer width et height ?

Pas automatiquement. Le bon choix dépend du mode d’intégration et de la gestion des dimensions par le HTML et CSS.

Peut-on supprimer viewBox ?

Généralement non si vous voulez conserver un SVG correctement redimensionnable. Sa suppression peut changer le cadrage et le comportement responsive.

Peut-on convertir toutes les formes en paths ?

Techniquement souvent oui, mais ce n’est pas toujours avantageux. Les primitives comme <circle> ou <rect> sont plus lisibles et parfois déjà très compactes.

Peut-on fusionner tous les paths ?

Non. Ils peuvent avoir des styles, interactions, animations ou règles de remplissage distincts.

Pourquoi mon SVG optimisé casse-t-il uniquement lorsqu’il est inline ?

Il peut dépendre d’identifiants, de styles, de currentColor ou entrer en collision avec un autre SVG du DOM.

Pourquoi un dégradé a-t-il disparu ?

Son identifiant ou sa définition dans <defs> a peut-être été supprimé ou renommé sans mettre correctement à jour la référence url(#...).

Pourquoi mon SVG est-il coupé après optimisation ?

Le viewBox, un filtre, un masque ou des coordonnées proches des limites ont peut-être été modifiés.

Pourquoi une icône paraît-elle différente seulement à 16 px ?

Une réduction de précision ou une simplification peut modifier la rasterisation à petite taille. Testez toujours la taille minimale réelle.

Un SVG minifié est-il plus performant ?

Il est généralement plus léger à transférer et analyser, mais les performances de rendu dépendent également du nombre d’éléments, des filtres et des animations.

Un SVG optimisé est-il sécurisé ?

Non. Optimisation et assainissement sont deux processus différents. Un SVG non fiable nécessite une politique de sécurité spécifique.

Supprimer <script> suffit-il à sécuriser un SVG ?

Non. D’autres constructions et références peuvent nécessiter un contrôle selon le contexte.

Faut-il conserver <title> et <desc> ?

S’ils participent volontairement à l’accessibilité d’un SVG inline, oui. Pour un SVG décoratif ou chargé avec une autre stratégie d’alternative, leur rôle peut être différent.

Peut-on raccourcir les identifiants ?

Oui si toutes les références sont connues et mises à jour et si cela ne crée pas de collisions. Soyez particulièrement prudent avec les SVG inline.

Comment gérer une photo intégrée dans un SVG ?

Évaluez si elle doit réellement être embarquée. Elle peut souvent être optimisée séparément et servie comme fichier raster adapté.

Dois-je utiliser SVG pour une photographie ?

Généralement non. Utilisez plutôt JPEG, WebP ou AVIF selon le besoin. Consultez PNG, JPEG, WebP ou AVIF : quel format choisir ?.

Comment vérifier que le rendu n’a pas changé ?

Comparez original et optimisé aux tailles réelles, sur plusieurs fonds et dans le composant final. Pour les assets sensibles, utilisez une superposition ou des tests visuels.

Comment optimiser plusieurs centaines de SVG ?

Automatisez avec une configuration versionnée, des budgets et des tests. Conservez les sources et traitez les changements de configuration comme des évolutions de votre pipeline.

L’outil Bethemesh peut-il m’aider ?

Oui. Utilisez l’optimiseur SVG pour expérimenter localement, comparer le poids et vérifier visuellement le résultat avant de l’intégrer au site.

Quel article lire ensuite ?

Après l’optimisation d’un SVG isolé, poursuivez avec Images responsives : comprendre srcset et sizes, puis Métadonnées d’image : les lire, les conserver ou les supprimer et enfin Optimiser les images pour les performances Web.