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

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?

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.

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.

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:

• Schéma d'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.

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

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.

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?

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/