Dois-je intégrer des images en tant que données / base64 dans CSS ou HTML


131

Pour réduire le nombre de requêtes sur le serveur, j'ai intégré des images (PNG et SVG) en BASE64 directement dans le css. (Il est 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 le faire également pour le CSS et le JS?


1
peu de gens utilisent plus IE7 et malgré tous les inconvénients, il y a un très bon avantage - moins de fichiers image à gérer! c'est-à-dire que si vous avez besoin de dessiner des lignes spéciales pour un composant d'arbre, l'incorporation des minuscules images de coude dans le css lui-même en combinaison avec repeat-x ou repeat-y supprime le besoin de vous assurer que les fichiers image supplémentaires sont au bon endroit (avec très peu overhead pour ce cas d'utilisation)
DaveAlger

Réponses:


153

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

C'est une bonne pratique généralement uniquement pour les très petites images CSS qui vont être utilisées ensemble (comme les sprites CSS) lorsque la compatibilité IE n'a pas d'importance, et que l'enregistrement de la demande est plus important que la capacité de 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 d'une 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 32768 caractères.

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

  • Le codage Base64 gonfle la taille des images de 33%.

  • Si elles sont servies dans une ressource gzippée, les data:images vont presque certainement être une pression terrible sur les ressources du serveur! Les images sont traditionnellement très gourmandes en CPU à compresser, avec très peu de réduction de taille.


2
@meo point intéressant. Je pense que c'est mauvais pour les performances de gzip, car les images sont généralement déjà compressées de manière très optimale. Les compresser coûte une quantité horrible d'espace CPU pour des gains en pourcentage à un chiffre. Essayez de gzipper un fichier JPG et vous verrez ce que vous voulez dire. Je vais modifier cela dans la réponse
Pekka

1
Je sais que gzipper des images compressées n'est pas la voie à suivre. Mais je pensais que c'est peut-être plus efficace sur la base 64. Surtout quand vous avez plus d'une image dans la source.
meo

2
@meo non, cela ne sera en aucun cas plus efficace sur la base64, car les motifs sous-jacents seront toujours les données d'image compressées qui se trouvent juste être exprimées en notation base64.
Pekka

1
@meo ah, je vois. Cela ne fonctionnera pas du tout dans IE et présente le même problème de mise en cache: vous enregistrez une demande, mais chaque demande de page augmente en taille. Il est généralement préférable de tout compacter dans un seul CSS et un fichier JS
Pekka

5
Cela ne gonfle PAS la page HTML lorsque vous intégrez les images dans un fichier CSS comme l'indique la question.
Daniel Beardsley

38

Les réponses communes ici semblent suggérer que ce n'est pas nécessaire, pour un ensemble de raisons légitimes. Cependant, tout cela semble négliger le comportement des applications modernes et le processus de création.

Il n'est pas impossible (et en fait assez facile) de concevoir un processus simple qui parcourra un dossier d'images et générera un seul CSS avec toutes les images de ce dossier.

Ce css sera entièrement mis en cache et réduira considérablement les allers-retours vers le serveur, ce qui est comme le suggère correctement @MemeDeveloper l'un des plus grands succès de performance.

Bien sûr, c'est du hack. sans aucun doute. même que les sprites sont un hack. Dans un monde parfait, cela ne sera pas nécessaire, jusque-là, c'est une pratique possible si ce que vous devez réparer est:

  1. Page avec plusieurs images qui ne sont pas facilement "spritable".
  2. Les voyages aller-retour vers les serveurs sont un véritable goulot d'étranglement (pensez mobile).
  3. la vitesse (au niveau des millisecondes) est vraiment très 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) sur IE5 et IE6.

mon avis.


4
Cela devrait être voté pour attirer plus d'attention. d'autres réponses sont un peu obsolètes - ils parlent d'IE6 alors que IE8 est un peu obsolète ces jours-ci ... (et merci pour cela)
Hertzel Guinness

11

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).

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

Désavantages

  • Les URI de données ne sont pas mis en cache séparément de leurs documents contenant (par exemple, les fichiers CSS ou HTML) de sorte que les données sont téléchargées chaque fois que les documents contenant sont retéléchargés.
  • 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é en 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/alternativeou 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 encodées en Base64 ont une taille 1/3 plus grande 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 compliquent la tâche des logiciels de sécurité pour filtrer le contenu.

3
Les CSS sont re-téléchargés à chaque demande? C'est un nouveau! De plus, si vous avez déjà archivé un fichier de votre vie, vous auriez remarqué que le taux de compression n'est pas de 2-3%! Si je ne me trompe pas, j'ai d'abord vu cette technique implémentée sur yahoo.com. ... ce n'est clairement pas une bonne pratique!
StefanNch

@StefanNch ce n'est pas ce qu'il dit. Dans l'extrait, «contenant le document» fait référence au fichier css.
Christophe du

9

J'utilisais des uri de données pendant environ un mois, et j'ai juste arrêté de les utiliser parce qu'ils rendaient mes feuilles de style absolument énormes.

Data-uri fonctionne dans IE6 / 7 (il vous suffit de servir un fichier mhtml à ces navigateurs).

Le seul avantage que j'ai tiré de l'utilisation de data-uri était que mes images d'arrière-plan étaient rendues dès que la feuille de style était 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 de l'essayer, juste pour que vous le sachiez par vous-même


3

J'étais plus enclin à utiliser des 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 renvoyer le tout perdu, à moins que vous n'ayez plusieurs fichiers CSS, bien sûr.


J'ai déjà des sprites, je me demandais si je pouvais l'optimiser encore plus avec cette méthode.
meo

2

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

Les navigateurs Web et les serveurs ont tout un tas de trucs de mise en cache intégrés, donc j'aurais pensé que votre meilleur pari était simplement de demander à votre serveur de dire au client de mettre en cache les fichiers image. À moins d'avoir des tas de très petites images sur une page, je n'aurais pas pensé que les frais généraux liés à plusieurs demandes étaient si importants. Les navigateurs utilisent généralement la même connexion pour demander beaucoup de fichiers, de sorte qu'aucune nouvelle connexion réseau n'est établie, donc à moins que le volume de trafic via les en-têtes HTTP ne soit significatif par rapport à la taille des fichiers image, je ne m'inquiéterais pas trop des demandes multiples. .

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


4
cause le nombre de requêtes est l'un des plus grands succès de performance si vous vous souciez de la première chose à essayer. voir la prise de yahoo developer.yahoo.com/performance/rules.html "Réduire le nombre de composants réduit à son tour le nombre de requêtes HTTP nécessaires pour rendre la page. C'est la clé pour des pages plus rapides."
MemeDeveloper

0

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

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

Bien sûr, les problèmes de support avec les anciens navigateurs doivent être gardés à l'esprit. Il peut également être judicieux d'utiliser la capacité d'un framework pour insérer automatiquement les images dans des URL de données telles que ClientBundle de GWT ou au moins utiliser des classes CSS au lieu de l'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/

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.