Au pire on utilise un design pattern du style proxy pour ne pas calculer à chaque appel la représentation base64 d'un élément. Ça évite ces optimisations peu élégantes ...

Une autre technique – sprites CSS – consiste à regrouper toutes les images de la charte graphique (pas le contenu) en une seule image.

Ben justement, on fait ce calcul une fois au moment du développement, on met ça dans une feuille de style qu'on va compresser et concaténer au moment du commit, du déploiement ou du premier accès (pour éviter de le faire à chaque requête). Cette méthode évite les gros sprites qui posent souvent des problèmes de consommation mémoire. Avec certains framworks de développement web, il est même possible de mettre l'URL de l'image dans le CSS et de laisser le pre-processor s'occuper de remplacer cette URL par l'équivalent en base64. @Eaglelouk : en quoi ça pollue le code ?

@fornorst : Merci pour cette technique que je ne connaissais pas.

[quote=Eaglelouk] Mouais, le problème c'est que ça pollue le code.. Je n'ose pas imaginer si les dev d'applications OS X / iOS faisaient pareil pour les ressources de leurs apps xD [/quote] Oui mais à ce compte là, la minification pollue le code également. Mais le fait est qu'on s'en fout : ce n'est pas le code qu'on édite. Ces opérations se font généralement par des hooks au commit ou au déploiement (avec Capistrano, par exemple), généralement appuyés par les outils du framework (l'assets pipeline dans Rails, par exemple). Au final, tu édites un code lisible et maintenable, puis tu configures tes outils pour produire le résultat le plus efficace possible, moche ou non.

Y en a qui ont oublié que le navigateur met des images en cache local ! Ainsi, au lieu de ne télécharger chaque image de la charte graphique qu'une seule fois, ce images seront téléchargées* à chaque nouvelle page/nouveau contenu HTML ! Donc à part être une fausse bonne idée en termes de quantité de données à télécharger et de performances, c'est quoi l'avantage d'inclure ces images dans le code HTML ? (*) ces images base64 étant inclues dans le code HTML sont téléchargée à chaque fois que le code HTML est chargé.

Tu n'as effectivement que peu d'intérêt à mettre ces données dans le HTML mais si tu mets ces données dans ton CSS et que ton CSS est mis en cache par le navigateur, tu auras le même niveau de cache que si tu avais mis ces images en externe. Tu auras juste une amélioration à la première visite sur la page où ton navigateur aura eu moins de resources à charger. Prenons l'exemple d'une page avec une feuille de style et 3 images. Toutes les resources ont une bonne politique de cache hormis la page HTML elle même qui n'a aucun cache. On peut distinguer 4 cas : 1/ toutes les resources sont chargées séparément 2/ les images sont mises dans un sprite 3/ les images sont stockées en base64 dans la CSS 4/ tout est stocké dans le HTML (CSS + images en base64) Cas 1 - première requête : 5 requêtes : la page HTML, la CSS et les 3 images Cas 1 - requêtes suivantes : 1 requête : la page HTML Cas 2 - première requête : 3 requêtes : la page HTML, la CSS et le sprite Cas 2 - requêtes suivantes : 1 requête : la page HTML Cas 3 - première requête : 2 requêtes : la page HTML et la CSS Cas 3 - requêtes suivantes : 1 requête : la page HTML Cas 4 - première requête : 1 requêtes : la page HTML Cas 4 - requêtes suivantes : 1 requête : la page HTML Dans les 3 premiers cas, les requêtes suivantes téléchargent le même volume d'information (une page HTML simple). La distinction se fait donc sur la première requête où la technique avec les images en base64 est meilleure que la technique avec les sprites. Dans le cas 4, la première requête est plus performante que les premières requêtes des autres cas (une seule connexion à ouvrir) mais elle est moins performante sur les requêtes suivantes (on demande au navigateur de tout re-télécharger). Par contre, dans le cas où cette page est prévue pour n'être vue qu'une seule fois, ça peut valoir le coup de tout inclure dans le HTML.

Est-ce qu'on peut l'utiliser sur des images optimisées par par JPEGmini, ImageOptim ou CryoPNG sans qu'il ne touche aux optimisations déjà réalisées et se contente de faire l'encodage Base64 ?

Sass & Compass FTW http://compass-style.org/reference/compass/helpers/inline-data/

@sunjohn : oui bien sûr que c'est plus compliqué que ce que j'ai noté mais bon, je n'allais pas réécrire les règles déjà bien expliquées par l'équipe Exceptionnal Performances de Yahoo! (équipe qui a réellement tracé la voie sur les perfs web) dans un post sur MacG :) J'expliquais juste qu'en fonction des cas, l'inclusion de certaines images dans la feuille de style voire dans le markup pouvait améliorer les perfs. Mais c'est évident que quand on cherche à faire un très gros site avec des temps de réponse optimaux, on se pose plein de questions ;)

Marrant je cherchais ce genre de soft il y a 15 jours... C'est surtout intéressant dans le cadre de développement mobile web où les connexions sont plus lentes et plus instables que les "classiques" ADSL par exemple. Même si on y gagne que quelques millisecondes , le cumul est bon à prendre Maintenant l'intégration de ces optimisations n'est pas évidente dans le maintien et la lecture du code, je trouve. C'est vraiment la dernière optimisation que je ferai avant compression. Et en s'assurant un bon doublon avec les références des images.

@xDave : voilà à quoi ressemble un bout d'une de mes CSS sur un projet Symfony2 utilisant Assetic pour la gestion des CSS et JS et utilisant le filtre cssembed pour gérer les images en data-uri : #opening-hours-layer h3 { background: transparent url('/bundles/kbrwregularwebsite/images/opening-hours-layer-blue-arrow.png') 0 } Ca ne me semble pas si problématique pour "le maintien et la lecture du code", si ? :) Au moment, du déploiement, je n'ai qu'à lancer la commande "php app/console assets:deploy" et c'est fini. Et vu que je déploie en automatique, aucun risque que j'oublie de le faire. Ainsi mes utilisateurs voient le site s'afficher plus vite et ça ne me coûte rien à moi développeur :)

zut erreur