Est-il beaucoup plus rapide d'utiliser des images en ligne / base64 pour un site Web que de simplement créer un lien vers le fichier dur?
Est-il beaucoup plus rapide d'utiliser une base64/ligne pour afficher des images que de simplement lier au fichier dur sur le serveur?
url(data:image/png;base64,.......)
Je n'ai trouvé aucun type de mesure de performance à ce sujet.
J'ai quelques inquiétudes:
- Vous ne profitez plus de la mise en cache
- Une base64 n'est-elle PAS BEAUCOUP plus grande qu'une taille de fichier PNG/JPEG?
Définissons "plus vite" comme dans: le temps qu'il faut à un utilisateur pour voir une page Web HTML entièrement rendue
"Plus rapide" est une chose difficile à répondre car il existe de nombreuses interprétations et situations possibles:
Le codage Base64 augmentera l'image d'un tiers, ce qui augmentera l'utilisation de la bande passante. D'un autre côté, l'inclure dans le fichier supprimera un autre aller-retour GET vers le serveur. Ainsi, un canal à haut débit mais à faible latence (comme une connexion Internet par satellite) chargera probablement une page avec des images intégrées plus rapidement que si vous utilisiez des fichiers d'images distincts. Même sur ma ligne DSL (rurale, lente), les sites qui nécessitent de nombreux allers-retours prennent beaucoup plus de temps à charger que ceux qui sont juste relativement grands mais ne nécessitent que quelques GET.
Si vous effectuez l'encodage base64 à partir des fichiers source à chaque demande, vous utiliserez plus de CPU, détruisant vos caches de données, etc., ce qui pourrait nuire au temps de réponse de vos serveurs. (Bien sûr, vous pouvez toujours utiliser memcached ou autre pour résoudre ce problème).
Bien sûr, cela empêchera la plupart des formes de mise en cache, ce qui pourrait faire beaucoup de mal si l'image est souvent vue - par exemple, un logo qui s'affiche sur chaque page, qui pourrait normalement être mis en cache par le navigateur (ou un cache proxy comme Squid ou que ce soit) et demandé une fois par mois. Cela empêchera également les nombreuses optimisations que les serveurs Web ont pour servir des fichiers statiques en utilisant des API de noyau comme sendfile (2).
Fondamentalement, cela aidera dans certaines situations et fera mal dans d'autres. Vous devez identifier les situations qui sont importantes pour vous avant de pouvoir vraiment déterminer si cela vous convient.
J'ai fait une comparaison entre deux pages HTML contenant 1800 images d'un pixel.
La première page déclare les images en ligne:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">
Dans le second, les images font référence à un fichier externe:
<img src="img/one-gray-px.png">
J'ai trouvé qu'en chargeant plusieurs fois la même image, si elle est déclarée en ligne, le navigateur effectue une requête pour chaque image (je suppose qu'elle base64 la décode une fois par image), alors que dans l'autre scénario, l'image est demandée une fois par document (voir l'image de comparaison ci-dessous).
Le document avec des images en ligne se charge en environ 250 ms et le document avec des images liées le fait en 30 ms.
(Testé avec du chrome 34)
Le scénario d'un document HTML avec plusieurs instances de la même image en ligne n'a pas beaucoup de sens a priori. Cependant, j'ai trouvé que le plugin jquery lazyload définit un espace réservé en ligne par défaut pour toutes les images "paresseuses", dont l'attribut src y sera défini. Ensuite, si le document contient de nombreuses images paresseuses, une situation comme celle décrite ci-dessus peut se produire.
Vous ne profitez plus de la mise en cache
La question de savoir si cela dépend de la façon dont vous dépendez de la mise en cache.
L'autre chose (peut-être plus importante) est que s'il y a beaucoup d'images, le navigateur ne les obtiendra pas simultanément (c'est-à-dire en parallèle), mais seulement quelques-unes à la fois - donc le protocole finit par être bavard . S'il y a un retard de bout en bout sur le réseau, alors de nombreuses images divisées par quelques images à la fois multipliées par le retard de bout en bout par image se traduisent par un délai notable avant le chargement de la dernière image.
Une base64 n'est-elle PAS BEAUCOUP plus grande qu'une taille de fichier PNG/JPEG?
L'algorithme de formatage/compression d'image est le même, je suppose, c'est-à-dire PNG.
En utilisant la base 64, chaque caractère de 8 bits représente 6 bits: par conséquent, les données binaires sont décompressées selon un rapport de 8 à 6, c'est-à-dire seulement environ 35%.
C'est beaucoup plus rapide
Définissez "plus vite". Vous parlez de performances HTTP (voir ci-dessous) ou de performances de rendu?
Vous ne profitez plus de la mise en cache
En fait, si vous faites cela dans un fichier CSS, il sera toujours mis en cache. Bien entendu, toute modification apportée au CSS invalidera le cache.
Dans certaines situations, cela pourrait être utilisé comme un énorme gain de performances sur de nombreuses connexions HTTP. Je dis quelques situations parce que vous pouvez probablement profiter de techniques comme les sprites d'image pour la plupart des trucs, mais c'est toujours bien d'avoir un autre outil dans votre arsenal!