Data-URI-Favicons (base64)
Ein Data-URI-Favicon bettet das Bild direkt im Link-Tag als base64-Text ein (href="data:image/png;base64,...") statt auf eine Datei zu verweisen, was eine HTTP-Anfrage entfernt. Es funktioniert für den Browser-Tab, versagt aber überall dort, wo ein Icon per URL abgeholt wird: /favicon.ico-Anfragen, apple-touch-icon, Manifest-Icons, Crawler und Link-Unfurler. Es ist also kein Ersatz für echte Dateien.
Was es bringt und was es kostet
Das Icon als base64 inline einzubetten spart eine Anfrage: Das Bild reist im HTML mit, sodass der Browser für den Tab keine separate Datei abholt. Für ein winziges Icon auf einer latenzempfindlichen Seite kann das reizvoll wirken.
Das Problem ist alles, was dein HTML nicht liest. Ein Crawler oder Link-Unfurler, der /favicon.ico per Pfad anfragt, bekommt nichts. iOS will eine echte apple-touch-icon-Datei; Android liest im Manifest gelistete Dateien. Keines davon kann ein Icon nutzen, das nur als Text in einem Link-Tag existiert, und der base64-Blob bläht jede HTML-Antwort auf, in der er steht.
Wie es aussieht
<link rel="icon" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." />Für den Tab in Ordnung, für alles, was ein Icon per URL anfragt, unsichtbar.
FAQ zum Data-URI-Favicon
Kann ich ein base64-Favicon verwenden?
Für den Browser-Tab ja. Aber es erfüllt weder /favicon.ico-Anfragen noch apple-touch-icon, das Manifest oder Crawler, sodass es auf einer echten Website nur echte Dateien ergänzen, nicht ersetzen kann.
Funktioniert ein Inline-Favicon auf iOS-Home-Bildschirmen?
Nein. iOS-Home-Bildschirme verwenden das apple-touch-icon, das eine echte Datei sein muss, die es abholen kann. Ein Data-URI in einem Favicon-Link bewirkt für den Home-Bildschirm nichts.
Ist ein Data-URI-Favicon gut für die Performance?
Es entfernt eine kleine Anfrage, bettet aber das kodierte Bild in jede HTML-Antwort ein, die es trägt. Für ein Icon, das nach dem ersten Laden ohnehin hart gecacht wird, ist die Ersparnis meist vernachlässigbar und die Aufblähung nicht.