Favicons en URI de données (base64)
Un favicon en URI de données intègre l'image directement dans la balise link sous forme de texte base64 (href="data:image/png;base64,...") au lieu de pointer vers un fichier, ce qui supprime une requête HTTP. Cela fonctionne pour l'onglet du navigateur, mais casse partout où une icône est récupérée par URL : requêtes /favicon.ico, apple-touch-icon, icônes de manifeste, robots d'exploration et outils d'aperçu de liens. Ce n'est donc pas un substitut aux vrais fichiers.
Ce que cela rapporte, et ce que cela coûte
Intégrer l'icône en base64 économise une requête : l'image voyage à l'intérieur du HTML, donc le navigateur ne récupère pas de fichier séparé pour l'onglet. Pour une petite icône sur une page sensible à la latence, cela peut sembler séduisant.
Le problème, c'est tout ce qui ne lit pas votre HTML. Un robot d'exploration ou un outil d'aperçu de liens qui demande /favicon.ico par chemin n'obtient rien. iOS veut un vrai fichier apple-touch-icon ; Android lit les fichiers listés dans le manifeste. Aucun d'eux ne peut utiliser une icône qui n'existe que sous forme de texte dans une seule balise link, et le blob base64 alourdit chaque réponse HTML sur laquelle il se trouve.
À quoi cela ressemble
<link rel="icon" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." />Convenable pour l'onglet, invisible pour tout ce qui demande une icône par URL.
FAQ sur le favicon en URI de données
Puis-je utiliser un favicon base64 ?
Pour l'onglet du navigateur, oui. Mais il ne satisfera pas les requêtes /favicon.ico, l'apple-touch-icon, le manifeste ni les robots d'exploration, donc sur un vrai site il ne peut que compléter les vrais fichiers, pas les remplacer.
Un favicon en ligne fonctionne-t-il sur les écrans d'accueil iOS ?
Non. Les écrans d'accueil iOS utilisent l'apple-touch-icon, qui doit être un vrai fichier qu'iOS peut récupérer. Un URI de données dans un lien de favicon ne fait rien pour l'écran d'accueil.
Un favicon en URI de données est-il bon pour les performances ?
Il supprime une petite requête mais intègre l'image encodée dans chaque réponse HTML qui la porte. Pour une icône de toute façon fortement mise en cache après le premier chargement, l'économie est généralement négligeable et l'alourdissement ne l'est pas.