L'incorporation de données d'image d'arrière-plan dans CSS en tant que Base64 est-elle une bonne ou une mauvaise pratique?

Je cherchais la source d'un script utilisateur greasemonkey et j'ai remarqué 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 voudrait regrouper tout ce qu'il peut dans la source plutôt que de l'héberger sur un serveur, c'est assez évident. Mais comme je n'avais pas vu cette technique auparavant, j'ai envisagé son utilisation et elle semble séduisante pour plusieurs raisons:

1. Cela réduira le nombre de requêtes HTTP au chargement de la page, améliorant ainsi les performances
2. S'il n'y a pas de CDN, cela réduira la quantité de trafic généré par les cookies envoyés avec les images
3. Les fichiers CSS peuvent être mis en cache
4. Les fichiers CSS peuvent être GZIPPED

Étant donné qu'IE6 (par exemple) a des problèmes de cache pour les images d'arrière-plan, cela ne semble pas être la pire idée ...

Alors, est-ce une bonne ou une mauvaise pratique, pourquoi NE L'UTILISEZ-VOUS PAS et quels outils utiliseriez-vous pour coder en base64 les images?

mise à jour - résultats des tests

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

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

• fichier CSS dédié: http://fragged.org/dev/base64.css - 178.1Kb

• Côté serveur d'encodage GZIP

• taille résultante envoyée au client (test des composants YSLOW): 59,3 Ko

• Enregistrement des données envoyées au navigateur client de: 74,3 Ko

Bien, mais ce sera un peu moins utile pour les petites images, je suppose.

MISE À JOUR: Bryan McQuade, un ingénieur logiciel chez Google, travaillant sur PageSpeed, a déclaré lors de ChromeDevSummit 2013 que data: uris en CSS est considéré comme un anti-modèle bloquant le rendu pour fournir un CSS critique / minimal lors de son discours #perfmatters: Instant mobile web apps. Voir http://developer.chrome.com/devsummit/sessions et gardez cela à l'esprit - diapositive réelle

Ce n'est pas une bonne idée lorsque vous souhaitez que vos images et informations de style soient mises en cache séparément. De plus, si vous encodez une grande image ou un nombre important d'images dans votre fichier css, il faudra plus de temps au navigateur pour télécharger le fichier en quittant votre site sans aucune information de style jusqu'à la fin du téléchargement. Pour les petites images que vous n'avez pas l'intention de changer souvent, c'est une bonne solution.

en ce qui concerne la génération de l'encodage base64:

• http://b64.io/
• http://www.motobit.com/util/base64-decoder-encoder.asp (téléchargement)
• http://www.greywyvern.com/code/php/binary2base64 (à partir du lien avec de petits tutoriels en dessous)

Cette réponse est obsolète et ne doit pas être utilisée.

1) La latence moyenne est beaucoup plus rapide sur mobile en 2017. https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2) multiplex HTTP2 https://http2.github.io/faq/#why-is-http2-multiplexed

Les «URI de données» doivent absolument être pris en compte pour les sites mobiles. L'accès HTTP sur les réseaux cellulaires s'accompagne d'une latence plus élevée par demande / réponse. Il existe donc des cas d'utilisation où le brouillage de vos images en tant que données dans des modèles CSS ou HTML pourrait être bénéfique sur les applications Web mobiles. Vous devez mesurer l'utilisation au cas par cas - je ne préconise pas que les URI de données soient utilisés 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. Les limites pour iOS 3.2 étaient assez faibles (25K par fichier), mais deviennent plus grandes (100K) pour les nouvelles versions de Mobile Safari. Veillez donc à garder un œil sur la taille totale de votre fichier lorsque vous incluez des URI de données.

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

Si vous référencez cette image une seule fois, je ne vois aucun problème pour l'intégrer dans votre fichier CSS. Mais une fois que vous utilisez plus d'une image ou devez la référencer plusieurs fois dans votre CSS, vous pouvez envisager d'utiliser une seule image image à la place, vous pouvez ensuite recadrer vos images uniques à partir de (voir Sprites CSS ).

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

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

De cette façon, vous vous assurerez que votre feuille de style régulière est téléchargée et appliquée dès que possible au document, tout en bénéficiant de demandes http réduites et d'autres avantages que les uris de données vous offrent.

Base64 ajoute environ 10% à la taille de l'image après GZipped, mais cela l'emporte sur les avantages en matière de mobile. Puisqu'il existe une tendance générale avec la conception de sites Web réactifs, il est fortement recommandé.

Le W3C recommande également cette approche pour les mobiles et si vous utilisez le 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

Je ne suis pas d'accord avec la recommandation de créer des fichiers CSS séparés pour les images non éditoriales.

En supposant que les images sont à des fins d'interface utilisateur, c'est le style de la couche de présentation, et comme mentionné ci-dessus, si vous faites de l'interface utilisateur mobile, c'est vraiment une bonne idée de conserver tous les styles dans un seul fichier afin de pouvoir les mettre en cache une fois.

Dans mon cas, cela me permet d'appliquer une feuille de style CSS sans se soucier de copier les images associées, car elles sont déjà intégrées à l'intérieur.

J'ai essayé de créer un concept en ligne d'outil d'analyse CSS / HTML:

http://www.motobit.com/util/base64/css-images-to-base64.asp

Ça peut:

• Téléchargez et analysez les fichiers HTML / CSS, extrayez les éléments href / src / url
• Détecter les données de compression (gzip) et de taille sur l'URL
• Comparer la taille des données d'origine, la taille des données base64 et la taille des données base64 compressées
• Convertissez l'URL (image, police, css, ...) en un schéma d'URI de données base64.
• Compter le nombre de requêtes pouvant être épargnées par les URI de données

Les commentaires / suggestions sont les bienvenus.

Antonin

Vous pouvez l'encoder en PHP :)

<img src="data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>">

Or display in our dynamic CSS.php file:

background: url("data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>");

1 That’s sort of a “quick-n-dirty” technique but it works. Here is another encoding method using fopen() instead of file_get_contents():

<?php // convert image to dataURL
$img_source = "feed-icon.gif"; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);
?>

La source

Apportant un peu aux utilisateurs de Sublime Text 2, il existe un plugin qui donne au code base64 que nous chargeons les images dans le ST.

Appelé Image2base64: https://github.com/tm-minty/sublime-text-2-image2base64

PS: Ne sauvegardez jamais ce fichier généré par le plugin car il écraserait le fichier et le détruirait.

Merci pour les informations ici. Je trouve cette intégration utile et particulièrement pour les mobiles, en particulier avec le fichier css des images intégrées mis en cache.

Pour vous faciliter la vie, comme mes éditeurs de fichiers ne gèrent pas cela de manière native, j'ai créé quelques scripts simples pour le travail d'édition sur ordinateur portable / bureau, à partager ici au cas où ils seraient utiles à quelqu'un d'autre. Je suis resté avec php car il gère ces choses directement et très bien.

Sous Windows 8.1, dites ---

C:\Users\`your user name`\AppData\Roaming\Microsoft\Windows\SendTo

... là, en tant qu'administrateur, vous pouvez établir un raccourci vers un fichier de commandes dans votre chemin. Ce fichier batch appellera un script php (cli).

Vous pouvez ensuite cliquer avec le bouton droit sur une image dans l'explorateur de fichiers et envoyer au fichier de commandes.

Ok, demande Admiinstartor, et attendez que les fenêtres noires du shell de commande se ferment.

Ensuite, collez simplement le résultat du presse-papiers dans votre éditeur de texte ...

<img src="|">

ou

 `background-image : url("|")` 

Les éléments suivants devraient être adaptables pour d'autres systèmes d'exploitation.

Fichier batch ...

rem @echo 0ff
rem Puts 64 encoded version of a file on clipboard
php c:\utils\php\make64Encode.php %1

Et avec php.exe sur votre chemin, cela appelle un script php (cli) ...

<?php 

function putClipboard($text){
 // Windows 8.1 workaround ...

  file_put_contents("output.txt", $text);

  exec("  clip < output.txt");

}


// somewhat based on http://perishablepress.com/php-encode-decode-data-urls/
// convert image to dataURL

$img_source = $argv[1]; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);

$finfo = finfo_open(FILEINFO_MIME_TYPE); 
$dataType = finfo_file($finfo, $img_source); 


$build = "data:" . $dataType . ";base64," . $img_string; 

putClipboard(trim($build));

?>

Pour autant que j'ai fait des recherches,

Utilisation: 1. Lorsque vous utilisez un sprite svg. 2. Lorsque vos images sont de taille inférieure (max 200 Mo).

N'utilisez pas: 1. Lorsque vous êtes de plus grandes images. 2. Icônes en svg. Comme ils sont déjà bons et compressés après compression.