Est intégrer les données d’image de fond dans les CSS en Base64 bonne ou mauvaise pratique ?

Question

J'ai été à la recherche à la source d'un script greasemonkey et de remarquer ce qui suit dans leur css:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

Je peux comprendre qu'un script greasemonkey aurait à regrouper tout ce qu'il peut dans la source, par opposition à l'héberger sur un serveur, c'est assez évident. Mais depuis je n'avais pas vu cette technique précédemment, j'ai examiné son utilisation et il semble attrayante pour un certain nombre de raisons:

1. Il permettra de réduire la quantité de requêtes HTTP sur le chargement de la page, ainsi que l'amélioration du rendement
2. Si pas de CA, alors qu'il permettra de réduire la quantité de trafic généré par les cookies envoyés à côté des images
3. CSS les fichiers peuvent être mis en cache
4. CSS les fichiers peuvent être au FORMAT gzip

Considérant que IE6 (par exemple) a des problèmes avec cache pour les images d'arrière-plan, il semble que ce n'est pas la pire idée...

Donc, est-ce une bonne ou une mauvaise pratique, pourquoi ne PAS l'utiliser et quels outils utilisez-vous pour base64 encode les images?

mise à jour - les résultats des tests

• test avec une image: http://fragged.org/dev/map-shot.jpg - de 133,6 Ko

• test de l'URL: http://fragged.org/dev/base64.html

• dédié fichier CSS: http://fragged.org/dev/base64.css- À 178,1 Ko

• L'encodage GZIP côté serveur

• taille résultante envoyé au client (YSLOW les composants de test): 59.3 Ko

• Enregistrement de données envoyé au navigateur client: 74.3 Ko

Sympa, mais il sera un peu moins utile pour les petites images, je suppose.

Mise à JOUR: Bryan McQuade, ingénieur logiciel chez Google, travail sur PageSpeed, exprimée à ChromeDevSummit 2013 que des données:les uri dans le CSS est considéré comme un rendu de blocage anti-modèle pour la prestation de critique/minime CSS lors de son talk - #perfmatters: Instant mobile web apps. Voir http://developer.chrome.com/devsummit/sessions et garder à l'esprit - de diapositive réelle

Answer 1

Ce n'est pas une bonne idée quand vous le voulez vos images et des informations de style pour être mis en cache séparément. Aussi, si vous encodez une grande image ou d'un nombre important d'images dans votre fichier css, il faudra le navigateur plus à télécharger le fichier quitter votre site sans aucune des informations de style jusqu'à ce que le téléchargement est terminé. Pour les petites images que vous n'avez pas l'intention de le changer souvent, si jamais c'est une excellente solution.

aussi loin que la génération de l'encodage base64:

• http://www.motobit.com/util/base64-decoder-encoder.asp (télécharger)
• http://www.greywyvern.com/code/php/binary2base64 (à partir de lien avec peu de tutoriels-dessous)
• http://base64img.com - en temps réel HTML5 conversion des images en Base64
• http://datauri.net - intègre automatiquement les données des Uri dans les fichiers CSS. prend en charge plusieurs fichiers / drag & drop

Answer 2

"Les données Uri" devrait être définitivement considéré comme pour les sites mobiles. HTTP l'accès sur des réseaux cellulaires est livré avec une latence plus élevée par requête/réponse. Donc il y a des cas d'utilisation où le brouillage vos images sous forme de données dans le CSS ou HTML des modèles pourrait être bénéfique sur les applications web mobiles. Vous devriez mesurer l'utilisation au cas par cas -- je ne dis pas que les données Uri doit être utilisé un peu partout, dans une application web mobile.

Notez que les navigateurs mobiles ont des limitations sur la taille totale des fichiers qui peuvent être mis en cache. Limites pour iOS 3.2 ont été assez faible (25 KO par fichier), mais devient plus grande (100K) pour les nouvelles versions de Safari Mobile. Donc, assurez-vous de garder un œil sur votre taille totale du fichier lors de l'inclusion de données Uri.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Answer 3

Si vous référencez cette image une seule fois, je ne vois pas un problème pour l’intégrer dans votre fichier CSS. Mais une fois que vous utilisez plus d’une image ou que vous devez référencer plusieurs fois dans votre CSS, vous pouvez envisager d’utiliser une seule image interactive au lieu de cela vous pouvez puis recadrer vos images individuelles (voir CSS Sprites).

Answer 4

Une des choses que je suggère est d'avoir deux feuilles de style séparées: une avec vos définitions de style régulières et une autre qui contient vos images en encodage base64.

Vous devez inclure la feuille de style de base avant la feuille de style d'image, bien sûr.

De cette façon, vous vous assurerez que votre feuille de style régulière est téléchargée et appliquée le plus rapidement possible au document, tout en profitant des demandes http réduites et des autres avantages que vous offrent les données.

Answer 5

Base64 ajoute environ 10% à la taille de l'image après GZipped mais cela l'emporte sur les avantages quand il s'agit de mobile. Comme il y a une tendance générale avec un design web réactif, il est fortement recommandé.

W3C recommande également cette approche pour mobile et si vous utilisez un pipeline d'actifs dans les rails, il s'agit d'une fonctionnalité par défaut lors de la compression de votre CSS

http://www.w3.org/TR/mwabp/#bp-conserve-css-images