Optimiser un fichier SVG/Généralités

Début de la boite de navigation du chapitre

Avant de voir comment optimiser un fichier SVG, il est utile de revenir sur les notions de format vectoriel et de format SVG.

fin de la boite de navigation du chapitre

Format vectoriel

La plupart des images de nos jours sont matricielles. Une image matricielle est constituée d’une grille de définition L × H pixels où L désigne le nombre de colonnes et H le nombre de lignes. L’image est ensuite construite à partir d’un code qui va désigner point par point la couleur à utiliser. La longueur du code, et donc le poids de l’image, sont donc principalement liés aux dimensions de celle-ci.

Dans une image vectorielle, le code ne sert plus à désigner la couleur des pixels mais à définir des formes et leurs caractéristiques. Par conséquent, le poids est lié à la longueur du code et non plus aux dimensions de l’image. Tant que celui-ci reste de la même longueur, il est possible de modifier la définition en jouant sur des facteurs de valeurs ; et à l'inverse, il est possible de l’alléger en optimisant le code.

Un fichier SVG est généré par un ensemble d’équations. Ces équations sont basées sur des points et des vecteurs. Par conséquent plus l’ensemble d’équations est important, plus le fichier sera lourd. La longueur de cet ensemble dépend du nombre d’équations ainsi que de la longueur de chacune d’entre elles.

Au final, la taille et la qualité d’un SVG sont très variables, tout dépend de la façon dont le fichier a été conçu. Ainsi des SVG d’aspect similaire peuvent avoir une différence de poids ou de structuration importante.

Format(s) SVG

C'est un format ouvert développé par le World Wide Web Consortium (W3C). La deuxième et dernière version du SVG est la 1.1 et date d'août 2011. Le SVG 1.1 est très proche du SVG 1.0. La prochaine version se fait pour le moment attendre (un brouillon du SVG 2 est paru seulement en 2012).

Techniquement, le format SVG est issu du XML et son type MIME est image/svg+xml.

Quand on enregistre un fichier sous un logiciel comme Inkscape ou Illustrator , celui propose plusieurs possibilités de formats. Sous Inkscape, les deux premiers sont : « SVG Inkscape (*.svg) » (mode par défaut) et « SVG Simple (*.svg) ». Les deux sont très similaires (cela reste du SVG) mais le premier correspond à un fichier dont le code s'écarte sur certains points des spécifications propres au format SVG. Celui-ci est enrichi par plusieurs éléments de code spécifiques à Inskscape (et à Sodipodi son prédécesseur). Celui-ci existe pour compléter certains manques des formats SVG 1.0 puis SVG 1.1 (l’absence de calque par exemple). Un fichier SVG Inkscape reste un fichier valide mais il pourra être mal interprété par un autre logiciel éditeur de SVG. Inversement, si enregistrer en SVG simple permet d’avoir un fichier plus polyvalent et correspondant exactement à la norme SVG, celui perdra certains des avantages d’Inkscape et pourra être plus difficile à rééditer avec ce même logiciel (par exemple, les calques n'existent pas en SVG simple et « disparaissent » donc à l’enregistrement en SVG simple).

Sans connaissance du code, il existe des outils pour vérifier automatiquement la validité d'un fichier SVG, par exemple sur le site validator.w3.org du W3C.

Optimisation

On parle bien d’optimisation et non pas simplement de réduction ou de simplification. Le but n’est pas uniquement de réduire au maximum le poids des images téléchargées, mais aussi de simplifier la lecture et la réédition du fichier.

Paradoxalement, l'optimisation passe parfois par un alourdissement du fichier. Quelques exemples :

• chaque élément doit posséder un identifiant. Celui-ci doit être significatif. La « significativité » étant subjective, il vaut mieux être trop explicite que pas assez. On évitera par exemple les abréviations, siglaisons et troncations trop poussées. Écrire « MtB » est certes plus court que « Mont Blanc » mais le peu que l’on gagne ne compense pas l'incompréhension générée.
• deux éléments distincts doivent rester distincts. Ainsi deux carrés blancs doivent rester deux éléments et non pas un seul, même si la seconde solution est plus légère.

De plus, l’optimisation doit être la plus cohérente et la plus uniforme possible. Il vaut mieux améliorer peu mais tout le fichier plutôt que d’améliorer beaucoup une seule partie du fichier. De façon un peu contre-intuitive, il vaut mieux gagner 50 % sur l'intégralité d’un code de 100 octets que 90 % sur la moitié du même code. Dans le premier cas, le code final sera de 50 octets, dans le second cas de 95 octets !

Quelques questions à se poser :

• mon fichier sera-t-il réédité dans le futur ; est-ce une version finale ou bien une version temporaire ? par exemple, en cartographie : la carte de mon fichier est-elle destinée à être prise telle quelle ou est-ce un fond de carte qui sera décliné, ou bien même une carte à mettre à jour régulièrement ?
• mon fichier fait-il partie d’une série ou d’un ensemble ? si oui, il vaut mieux rester cohérent avec cette série, ou alors il faut appliquer les mêmes optimisations à tous les éléments de la série.
• …