J’ai profité de la sortie de la branche 2.7 de Dotclear et de l’arrivée de Twig comme moteur de template pour faire quelques modifications sur le blog :
- Migration vers des templates utilisant la syntaxe Twig et utilisation au maximum de l’héritage (la killer feature de Twig !).
- Utilisation encore plus massive de Less.
- Mise à jour des librairies JS et CSS (merci Bower).
- Suppression des sprites CSS pour utiliser des images en data URI au sein de mes CSS.
Et c’est sur ce dernier point que je souhaitais discourir…
Les sprites CSS c’est bien… mais c’est chi**t !!!
En effet, les sprites CSS c’est bien pour les performances web client side (notamment : Minimize HTTP Requests & Preload Components). Le problème, c’est que c’est chi**t à manipuler ! Il existe des générateurs de sprites, mais ce n’est pas la panacée. Bilan : j’y réfléchi à 2 fois avant de changer une image et dans certains cas il est même obligatoire de mixer plusieurs images sprites (sur des background-repeat bien complexes).
Data URI, L’alternative ?
La solution alternative c’est d’utiliser des data URIs, c’est à dire de mettre le code base64 de l’image directement dans la CSS (où une CSS séparée). Vous me direz que faire un sprite CSS ou faire un base64 c’est aussi pénible et je vous répondrais oui… Si on travaille en pure CSS ! Mais si on utilise Less (et c’est surement aussi possible en Sass) il y a une fonction qui fait ça automatiquement !
Y a-t-il que des avantages ?
Malheureusement non.
- Un fichier CSS avec du base64 pèse 25% (10% si on utilise compression gzip) de plus qu’un sprite.
- Les data URI’s ne sont pas supportées par IE6/7 (ça je m’en fous un peu :-)).
- Les performances sont quelques peu en dessous d’un sprite.
En conclusion
J’ai déjà pas mal optimisé mon site, le fait de passer par data-uri me permet de :
- Réduire le poids général de ma CSS (j’embarquais déjà quelques data-uri que je viens de délocaliser dans une CSS à part).
- Pouvoir rapidement faire évoluer mon image sprites (retirer les images inutiles par exemple) et gagner en time to market.
Bref : adopté !
