Quand faut-il utiliser des images en Base64 ?

La règle de base

Intégrez une image directement dans le code quand le coût d'une requête séparée dépasse celui des octets en plus. Avec les connexions HTTP/2 et HTTP/3 actuelles, les requêtes supplémentaires coûtent peu, et ce seuil arrive donc vite : une bonne limite pratique est de 2 à 4 Ko par image. Les outils de build courants vont dans le même sens : Vite intègre par défaut les fichiers de moins de 4 Ko, et les asset modules de webpack ceux de moins de 8 Ko.

L'outil ci-dessous transforme un PNG (ou n'importe quelle image) en data URI. Déposez l'image ou ouvrez-la, puis choisissez comment la copier dans Copier en : Data URI, Base64 seul, une ligne CSS background-image prête à l'emploi, une balise HTML img avec largeur et hauteur, ou Markdown. Il affiche le poids de la data URI et de combien elle dépasse le fichier, et vous prévient quand le résultat est assez lourd pour ralentir une page. Les images sont converties dans votre navigateur et ne sont jamais envoyées.

Ce qui se passe quand on intègre une image

Une data URI comme data:image/png;base64,iVBORw0KGgo... place les octets de l'image à l'intérieur du HTML, du CSS ou du JSON qui y fait référence. Le navigateur reçoit l'image en même temps que ce fichier, sans téléchargement séparé. C'est là tout l'avantage. Les inconvénients découlent du même principe :

• Le poids : le Base64 écrit 3 octets sous forme de 4 caractères, l'image grossit donc d'environ un tiers. La compression Gzip ou Brotli du serveur en récupère une partie pendant le transfert, mais pas tout, et les images déjà compressées (PNG, JPG, WebP) y gagnent peu.
• Le cache : un fichier image séparé est mis en cache une fois et réutilisé sur chaque page. Une image intégrée n'est mise en cache qu'avec le fichier qui la contient. Modifiez une ligne de CSS, et toutes les icônes intégrées sont téléchargées à nouveau.
• Le blocage de l'affichage : le CSS bloque le premier rendu. Chaque kilooctet d'image intégré dans une feuille de style retarde le moment où quelque chose apparaît à l'écran, même si ces images sont tout en bas de la page.
• Pas de chargement différé : loading="lazy" et les choix responsive de srcset perdent leur intérêt, puisque les octets sont déjà arrivés avec la page.
• La maintenance : une longue chaîne Base64 est illisible en revue de code et facile à casser avec un copier-coller raté.

Guide des poids : intégrer ou fichier séparé ?

Les bons usages des images en Base64

• Les petites icônes en CSS, comme des flèches, des coches, une case à cocher personnalisée ou la flèche d'une liste déroulante, qui doivent apparaître en même temps que les styles et ne jamais surgir en retard.
• Les livrables en un seul fichier : un rapport HTML, une facture exportée, une page de documentation ou un prototype qui doit fonctionner ouvert depuis le disque ou envoyé en une seule pièce jointe.
• Les API et les bases de données : le JSON n'a pas de type binaire, donc les images dans les requêtes et réponses d'API (signatures, avatars, documents scannés, images produits de certaines intégrations de places de marché) sont souvent envoyées sous forme de chaînes Base64.
• Les aperçus basse qualité : une toute petite version floue intégrée dans le HTML s'affiche instantanément pendant le chargement de l'image complète.
• Les icônes SVG : le SVG est du texte, il n'a donc souvent pas besoin de Base64 du tout. L'option Encodage URL au lieu du Base64 (plus court) de l'outil garde le SVG lisible et donne généralement un résultat plus court.

Quand les éviter

• Les photos et toute image de plus de 10 Ko environ sur une page web. Utilisez un fichier classique en WebP ou AVIF, avec largeur et hauteur indiquées et chargement différé pour les images sous la ligne de flottaison.
• La plus grande image en haut de la page (l'élément LCP). Une grosse image intégrée alourdit le HTML lui-même et retarde tout le reste ; précharger un fichier séparé est généralement plus rapide.
• Les images répétées d'une page à l'autre, comme le logo du site ou un motif de fond. Le cache l'emporte sur l'économie d'une requête.
• Les e-mails HTML destinés au grand public. Beaucoup de clients de messagerie n'affichent pas les images en data URI ; Gmail et Outlook pour Windows sont les plus connus. Utilisez plutôt des images hébergées ou des pièces jointes référencées par Content-ID (CID). Les data URI intégrées fonctionnent surtout dans Apple Mail et certaines applications mobiles, ce qui ne suffit pas pour une newsletter.
• Les très grosses data URI en général. L'ancien Internet Explorer 8 les limitait à 32 Ko ; les navigateurs modernes en acceptent de bien plus grosses, mais les performances se dégradent bien avant d'atteindre une limite.

Bien s'y prendre

Réduisez l'image avant de la convertir. Chaque octet économisé est multiplié par 4/3 dans la data URI : compressez les icônes PNG, ramenez les images trop grandes à leur taille d'affichage, et pour les photos que vous devez intégrer, par exemple dans des données JSON, utilisez un JPG ou un WebP à une qualité raisonnable. Le compresseur et l'outil de redimensionnement d'images de ce site le font dans le navigateur, et vous pouvez ensuite rapporter ici le fichier allégé.

Indiquez les dimensions. Une balise img sans largeur ni hauteur fait sauter la mise en page quand l'image apparaît. C'est pour cela que la sortie HTML de cet outil inclut la largeur et la hauteur réelles de l'image.

Gardez le fichier source. Conservez le PNG ou le SVG d'origine dans votre projet et générez la data URI à partir de lui, avec votre outil de build ou avec cet outil quand quelque chose change. Ne considérez jamais la chaîne Base64 comme la version de référence.

Mesurez. Comparez la page avec et sans les images intégrées dans l'onglet Réseau des outils de développement du navigateur ou avec Lighthouse. Si le fichier CSS ou HTML grossit nettement sans que rien ne s'accélère, revenez à un fichier séparé.