Favicon в виде data URI (base64)
Favicon в виде data URI встраивает изображение прямо в тег <link> как текст base64 (href="data:image/png;base64,...") вместо ссылки на файл, что убирает один HTTP-запрос. Он работает для вкладки браузера, но ломается везде, где иконку получают по URL: запросы /favicon.ico, apple-touch-icon, иконки манифеста, краулеры и разворачиватели ссылок. Так что это не замена настоящим файлам.
Что это даёт и чего стоит
Встраивание иконки как base64 экономит один запрос: изображение путешествует внутри HTML, так что браузер не загружает отдельный файл для вкладки. Для крошечной иконки на странице, чувствительной к задержкам, это может выглядеть привлекательно.
Проблема — всё, что не читает ваш HTML. Краулер или разворачиватель ссылок, запрашивающий /favicon.ico по пути, не получает ничего. iOS хочет настоящий файл apple-touch-icon; Android читает файлы, перечисленные в манифесте. Ни один из них не может использовать иконку, существующую только как текст внутри одного тега <link>, а блоб base64 раздувает каждый HTML-ответ, в котором он есть.
Как это выглядит
<link rel="icon" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." />Годится для вкладки, невидимо для всего, что запрашивает иконку по URL.
Частые вопросы о favicon в виде data URI
Можно ли использовать base64-favicon?
Для вкладки браузера — да. Но он не удовлетворит запросы /favicon.ico, apple-touch-icon, манифест или краулеры, так что на реальном сайте он может только дополнять настоящие файлы, а не заменять их.
Работает ли встроенный favicon на домашних экранах iOS?
Нет. Домашние экраны iOS используют apple-touch-icon, который должен быть настоящим файлом, который она может загрузить. Data URI в ссылке favicon ничего не даёт домашнему экрану.
Хорош ли data URI favicon для производительности?
Он убирает один маленький запрос, но встраивает закодированное изображение в каждый HTML-ответ, который его несёт. Для иконки, которая всё равно жёстко кешируется после первой загрузки, экономия обычно ничтожна, а раздувание — нет.