Outils de développement · Encodeur et décodeur Base64
Images Base64 en ligne en CSS : quand les données : les URI sont utiles et quand elles font mal
· Pourquoi c'est important
base64 Navigateur
Intégration d'une image en tant que données Base64 : l'URI supprime une requête mais agrandit le fichier et annule la mise en cache. Cet article explique quand l'échange en vaut la peine et quand un fichier séparé est plus rapide.
La feuille de style qui a atteint des centaines de kilo-octets : l'habitude d'une équipe d'inline et comment elle s'est manifestée dans les temps de chargement
Une équipe de développement a décidé que l'intégration de petites icônes en tant que données Base64 : URI dans leur CSS réduirait les requêtes HTTP et améliorerait la vitesse de chargement des pages. Au fil du temps, à mesure que de nouvelles icônes étaient ajoutées, la feuille de style est passée à 400 kilo-octets.
Le bundle CSS, qui devrait contenir des règles de style, est désormais dominé par les données d'image. L'équipe a mesuré le temps de chargement et a constaté que la page était plus lente qu'avant l'inline, pas plus rapide. Le problème est devenu clair : la feuille de style 400 kilobyte est téléchargée à chaque chargement de page et mise en cache par page, alors que si les icônes étaient des fichiers séparés, un seul fichier d'icône serait mis en cache et partagé sur chaque page.
Qu'est-ce qu'une donnée : URI en ligne et pourquoi il s'agit de Base64 – la syntaxe, le type de média et la pénalité de taille
L'ajout de pages supplémentaires au site a aggravé le problème, car chaque page télécharge à nouveau la même feuille de style avec toutes ces images intégrées. Cet article explique ce qu'est une donnée : l'URI, pourquoi il s'agit de Base64, comment l'inline affecte la mise en cache et les performances, et les règles empiriques pour décider quand le compromis en vaut la peine. Une URL de données est un moyen d'intégrer une ressource directement dans un fichier HTML ou CSS au lieu de créer un lien vers un fichier externe. La syntaxe est data:mediaType;base64,encoded_bytes.
Le mediaType déclare le type de ressource qui suit, comme image/svg+xml pour SVG, image/png pour PNG ou text/plain pour le texte. L'indicateur ;base64 indique que la charge utile est codée en base64 plutôt qu'en texte codé en pourcentage. Les encoded_bytes sont les données réelles. Lorsqu'un navigateur rencontre une URL data: dans une propriété href, src ou background-image, il décode le Base64 et restitue la ressource en ligne. Aucune requête HTTP n'est effectuée car la ressource est déjà là, intégrée dans le document parent. Cela permet d'économiser une ou quelques requêtes HTTP, ce qui est important dans un monde HTTP/1.1 où chaque requête a une surcharge.
Mise en cache et chemin critique : pourquoi les octets en ligne sont à nouveau téléchargés avec chaque page incluant la feuille de style
Dans un monde HTTP/2 ou HTTP/3 où de nombreuses requêtes peuvent être multiplexées sur une seule connexion, les économies sont moindres. La pénalité de taille du codage Base64 est immédiate et significative. Une icône SVG qui fait 3 kilo-octets lorsqu'elle est enregistrée en tant que fichier XML devient 4 kilo-octets lorsqu'elle est codée en Base64 et intégrée en tant que données : URI. L'augmentation de taille de 33 % due à l'encodage doit être ajoutée à chaque page incluant la feuille de style. Si l'icône est utilisée sur dix pages, la feuille de style est téléchargée dix fois, incluant à chaque fois la même image codée de 4 kilo-octets.
Si l'icône était un fichier distinct, l'original de 3 kilobyte serait téléchargé une fois et mis en cache, puis utilisé à partir du cache sur les dix pages. Le choix économique est clair pour la plupart des icônes : les fichiers séparés sont globalement plus petits. L'avantage de l'inline s'applique uniquement lorsqu'une icône est utilisée sur exactement une page ou sur très peu de pages, et que l'icône est véritablement critique pour cette page. Un favicon qui apparaît sur chaque page est un mauvais candidat pour l'inline ; c'est mieux en tant que fichier mis en cache séparé.
Coûts d'analyse sur le client – comment les grandes chaînes en ligne sont gérées par les analyseurs CSS et HTML, décrites qualitativement
Une illustration unique utilisée uniquement sur une page de destination pourrait bénéficier de l'intégration pour enregistrer une demande. La mise en cache annule la plupart des avantages de l'incorporation de données : les URI dans les feuilles de style. Une feuille de style est généralement mise en cache pendant des jours ou des semaines. Lorsque la feuille de style est téléchargée, toutes les ressources qui y sont intégrées sont à nouveau téléchargées, même si le navigateur a déjà cette image en cache. Si la feuille de style est mise à jour, toutes les données intégrées doivent être revalidées ou téléchargées à nouveau, même si une seule règle CSS a été modifiée.
Cela provoque un gonflement : les modifications apportées aux couleurs ou à l'espacement déclenchent un nouveau téléchargement complet de la feuille de style, y compris les kilo-octets de données d'image qui n'ont pas changé. Un fichier image distinct peut être mis en cache indépendamment avec ses propres en-têtes d'expiration, mis à jour séparément et réutilisé dans les feuilles de style et les pages. Le cache du navigateur est bien plus efficace lorsque les ressources sont des fichiers séparés que lorsqu'elles sont intégrées dans des documents plus volumineux. Les coûts d'analyse et de rendu s'aggravent lorsque de grandes chaînes Base64 sont intégrées dans des feuilles de style. Un analyseur CSS doit lire l'intégralité de la feuille de style avant d'appliquer les règles.
Exemple concret : insérer une petite icône SVG sous forme de texte – coller le balisage dans l'encodeur et assembler les données : URI à la main
Une feuille de style de 400 kilo-octets avec Base64 en ligne représente 400 kilo-octets de texte qui doit être analysé avant que des règles puissent être appliquées. Un analyseur HTML restituant une page avec des données volumineuses : l'URI dans un attribut de style ou une propriété background-image doit décoder le Base64 et construire l'image avant que l'élément puisse être restitué. Pour les icônes SVG simples, c'est trivial. Pour les images plus complexes ou les icônes plus grandes, le décodage et le rendu s'effectuent sur le thread principal, bloquant potentiellement l'interactivité. Le coût qualitatif est réel mais difficile à mesurer sans profilage.
En règle générale, si l'image intégrée fait plus de quelques kilo-octets, les fichiers séparés sont plus rapides. Un exemple concret montre le compromis exact. Prenez une simple icône de flèche SVG, 1.2 kilo-octets de XML. Codé en base64, il devient 1600 caractères, soit environ 1.6 kilo-octets avec le préfixe data: URL. Une règle CSS distincte avec background-image : url(/icons/arrow.svg) ajoute peut-être 40 octets à la feuille de style. Le fichier d'icône est téléchargé une fois, mis en cache et réutilisé. L'inlining enregistre une requête HTTP pour cette icône mais ajoute 1.6 kilo-octets à chaque chargement de feuille de style.
Des règles empiriques qui tiennent le coup : des ressources minuscules, critiques et à usage unique en ligne ; tout le reste sous forme de fichier
Si la feuille de style fait 50 kilo-octets et est partagée sur 20 pages, l'intégration de cette icône augmente le téléchargement total de 32 kilo-octets par visite du site. La requête HTTP qu’il enregistre représente tout au plus quelques centaines d’octets de surcharge. La demande est également automatiquement multiplexée dans HTTP/2,, éliminant ainsi la différence de surcharge. Le commerce inline perd beaucoup à moins que la feuille de style soit minuscule, que l'icône soit énorme ou que l'icône apparaisse sur exactement une page et nulle part ailleurs. Les règles empiriques qui survivent à un examen minutieux sont limitées et spécifiques.
De minuscules ressources critiques à usage unique peuvent être intégrées. Une flèche SVG 200-byte qui apparaît uniquement sur une page inhabituelle peut être intégrée pour économiser la surcharge de la requête. Tout le reste devrait être séparé. La logique critique du chemin de rendu est importante : si une icône doit être visible immédiatement et que chaque milliseconde de temps de chargement coûte une conversion, l'inline pourrait gagner. Pour les pages typiques avec des icônes typiques, des fichiers séparés sont presque toujours préférables. Testez les deux approches avec vos actifs réels et mesurez la charge des pages, les taux de réussite du cache et la cascade de demandes.
Ce que cela ne couvre pas : détails du multiplexage HTTP/2 et HTTP/3 et compression du format d'image
Ne présumez pas que l'inline est une optimisation sans mesure. Le moyen le plus simple de se retrouver avec une feuille de style gonflée est de l'incorporer progressivement sans mesurer si chaque ajout est réellement plus rapide. L'encodeur et décodeur Base64 vous aide à prendre cette décision avant de vous engager dans l'inline. Collez votre balisage SVG ou autre source d'icônes dans l'outil sous forme de texte. Cliquez sur Encoder et définissez les options pour générer une donnée : URI. L'outil vous montre la longueur exacte des données : URL. Comparez cela à la taille d'une règle CSS distincte et au fichier d'actifs lui-même.
Calculez le nombre de pages qui devraient partager la feuille de style pour atteindre le seuil de rentabilité de l'intégration par rapport aux fichiers séparés. Assemblez les données : URI et testez-les dans une page HTML réelle avant de les valider dans la feuille de style. Si l’URI comporte plus de quelques centaines de caractères, le coût de l’intégration est probablement supérieur à l’avantage de sauvegarder une requête. Utilisez l'outil pour tester vos icônes et actifs réels, puis mesurez l'impact sur vos mesures réelles de chargement de page avant et après l'inline.
À retenir : insérez avec parcimonie et mesurez - comment l'encodeur et le décodeur Base64 vous permettent d'encoder le balisage SVG et de voir la taille exacte avant de vous engager
L'approche performante consiste à être sélectif en matière d'inline. Les icônes utilisées sur chaque page ou sur plusieurs pages sont des fichiers mis en cache distincts. Les icônes utilisées sur exactement une page ou vraiment essentielles à la première peinture peuvent être intégrées. Mesurez le compromis entre vos actifs et vos pages réels plutôt que de suivre des conseils génériques. Utilisez l'encodeur et le décodeur Base64 pour voir la taille exacte de tout élément intégré avant de l'ajouter à une feuille de style. La pénalité de taille est réelle et se multiplie à chaque page vue.
La mise en cache et le multiplexage des requêtes ont rendu l'avantage initial de l'inline moins important. Pour la plupart des applications modernes, des feuilles de style plus petites et une meilleure efficacité du cache à partir de fichiers séparés dépassent la surcharge des requêtes. Inlinez avec parcimonie, mesurez le résultat et faites confiance à la mesure plutôt qu’à l’intuition.