web-dev-qa-db-fra.com

Dois-je incorporer des images en tant que data / base64 en CSS ou HTML?

Pour réduire le nombre de requêtes sur le serveur, j'ai intégré certaines images (PNG & SVG) directement sous BASE64 dans le fichier css. (Son automatisé dans le processus de construction)

comme ça:

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

Est-ce une bonne pratique? Y a-t-il des raisons d'éviter cela? Existe-t-il un navigateur majeur qui ne prend pas en charge les URL de données?

Question bonus: est-il judicieux de faire cela pour CSS & JS également?

htmlcssbase64
129
meo

Est-ce une bonne pratique? Y a-t-il des raisons d'éviter cela?

En règle générale, c'est une bonne pratique que pour les très petites images CSS qui seront utilisées ensemble (comme les sprites CSS) lorsque IE), la compatibilité importe peu et l'enregistrement de la demande est plus important que la mise en cache.

Il présente un certain nombre d'inconvénients notables:

  • Ne fonctionne pas du tout dans IE6 et 7.

  • Fonctionne uniquement pour les ressources taille maximale de 32 Ko dans IE8 . C'est la limite qui s'applique après le codage base64. En d'autres termes, pas plus de 32 768 caractères.

  • Il enregistre une demande, mais gonfle la page HTML à la place! Et rend les images inaccessibles. Ils sont chargés chaque fois que la page ou la feuille de style est chargée.

  • L'encodage Base64 augmente de 33% la taille des images.

  • Si servi dans une ressource compressée, data: _ les images vont presque certainement peser lourdement sur les ressources du serveur! Les images demandent traditionnellement beaucoup de temps à compresser, avec un minimum de réduction de taille.

154
Pekka 웃

Les réponses communes suggèrent ici que cela n'est pas nécessaire, pour un ensemble de raisons légitimes. Cependant, tout cela semble négliger le comportement et les processus de construction des applications modernes.

Il n'est pas impossible (et en fait très facile) de concevoir un processus simple qui parcourt un dossier d'images et génère un CSS unique contenant toutes les images de ce dossier.

Ce css sera entièrement mis en cache et réduira considérablement les allers-retours au serveur, ce que suggère très justement @MemeDeveloper comme l'un des plus gros succès en termes de performances.

Bien sûr, c'est bidouille. sans aucun doute. comme les sprites sont un hack. Dans un monde parfait, cela ne sera pas nécessaire. Jusque-là, c'est une pratique possible si vous devez corriger ceci:

  1. Page avec plusieurs images qui ne sont pas facilement "spritables".
  2. Les allers-retours aux serveurs sont un véritable goulet d'étranglement (pensez mobile).
  3. la vitesse (au niveau des millisecondes) est vraiment importante pour votre cas d'utilisation.
  4. Vous ne vous souciez pas (comme vous devriez, si vous voulez que le Web aille de l'avant) à propos de IE5 et IE6.

mon avis.

34
JAR.JAR.beans

Ce n'est pas une bonne pratique. Certains navigateurs ne prennent pas en charge les URI de données (par exemple IE 6 et 7)) ou la prise en charge est limitée (par exemple 32 Ko pour IE8).

Voir aussi cet article Wikipedia pour des détails complets sur les inconvénients de l'URI de données:

Inconvénients

  • Les URI de données ne sont pas mis en cache séparément des documents qu'ils contiennent (fichiers CSS ou HTML, par exemple), de sorte que les données sont téléchargées à chaque fois que les documents contenant sont téléchargés à nouveau.
  • Le contenu doit être réencodé et ré-intégré chaque fois qu'une modification est apportée.
  • Internet Explorer jusqu'à la version 7 (environ 15% du marché à compter de janvier 2011) manque de support.
  • Internet Explorer 8 limite les URI de données à une longueur maximale de 32 Ko.
  • Les données sont incluses sous forme de flux simple et de nombreux environnements de traitement (tels que les navigateurs Web) peuvent ne pas prendre en charge l'utilisation de conteneurs (tels que multipart/alternative ou message/rfc822) pour fournir une plus grande complexité telle que les métadonnées, la compression de données ou la négociation de contenu.
  • Les URI de données codées en Base64 sont 1/3 plus grandes que leur équivalent binaire. (Cependant, cette surcharge est réduite à 2-3% si le serveur HTTP compresse la réponse à l'aide de gzip)
  • Les URI de données empêchent les logiciels de sécurité de filtrer le contenu.
11
Martin Buberl

J'utilisais des data-uri pendant environ un mois et j'ai simplement cessé de les utiliser car elles rendaient mes feuilles de style absolument énormes.

Les données-uri fonctionnent dans IE6/7 (il vous suffit de servir un fichier mhtml à ces navigateurs).

Le seul avantage que j'ai obtenu en utilisant data-uri est que mes images d'arrière-plan sont rendues dès que la feuille de style a été téléchargée, par opposition au chargement progressif que nous voyons autrement.

C'est bien que cette technique soit disponible, mais je ne l'utiliserai pas trop à l'avenir. Je recommande cependant d'essayer, juste pour que vous sachiez vous-même

9
stephenmurdoch

J'aurais plus tendance à utiliser les sprites CSS pour combiner les images et économiser sur les demandes. Je n'ai jamais essayé la technique base64 mais cela ne fonctionne apparemment pas dans IE6 et IE7. Cela signifie également que si des images changent, vous devez redonner toute la perte, sauf si vous avez plusieurs fichiers CSS, bien sûr.

3
Steve Claridge

Je n'ai aucune idée des meilleures pratiques générales, mais je ne voudrais pas voir ce genre de chose si je pouvais l'aider. :)

Les navigateurs Web et les serveurs ont toute une batterie de solutions de mise en cache. J'aurais donc pensé que le mieux serait de demander à votre serveur de demander au client de mettre en cache les fichiers image. À moins que vous n'ayez des tonnes de très petites images sur une page, je n'aurais pas pensé que le surcoût de plusieurs demandes était une si grosse affaire. Les navigateurs utilisent généralement la même connexion pour demander de nombreux fichiers, de sorte qu'aucune nouvelle connexion réseau n'est établie. Par conséquent, à moins que le volume de trafic via les en-têtes HTTP soit significatif par rapport à la taille des fichiers image, je ne m'inquiéterais pas trop des requêtes multiples. .

Y a-t-il des raisons pour lesquelles vous pensez qu'il y a trop de demandes adressées au serveur en ce moment?

2
Chris

Je le suggérerais pour les images minuscules utilisées très souvent, par exemple les icônes communes d'une application Web.

  • Minuscule, car l'encodage Base64 augmente la taille
  • Souvent utilisé, parce que cela justifie le temps de chargement initial plus long

Bien sûr, il faut garder à l’esprit les problèmes de support avec les anciens navigateurs. En outre, il pourrait être judicieux d'utiliser la capacité d'un framework pour intégrer automatiquement les images aux URL de données telles que ClientBundle de GWT ou au moins utiliser des classes CSS au lieu de les ajouter directement au style de l'élément.

Plus d'informations sont rassemblées ici: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

0
Sebastian