Я смотрел на источник пользовательского скрипта greasemonkey и заметил следующее в их css:
.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}
Я могу оценить, что скрипт greasemonkey захочет объединить все, что может в исходном коде, а не размещать его на сервере, это достаточно очевидно. Но так как я не видел эту технику ранее, я рассмотрел ее использование, и она кажется привлекательной по ряду причин:
- Это уменьшит количество HTTP-запросов при загрузке страницы, что повысит производительность
- Если CDN отсутствует, это уменьшит объем трафика, генерируемого с помощью файлов cookie, отправляемых вместе с изображениями.
- CSS-файлы могут быть кэшированы
- CSS-файлы могут быть сжаты
Учитывая, что IE6 (например) имеет проблемы с кешем для фоновых изображений, кажется, что это не самая плохая идея ...
Итак, является ли это хорошей или плохой практикой, почему бы вам не использовать ее и какие инструменты вы бы использовали для кодирования изображений base64?
обновление - результаты тестирования
тестирование с изображением: http://fragged.org/dev/map-shot.jpg - 133,6 КБ
тестовый URL: http://fragged.org/dev/base64.html
выделенный файл CSS: http://fragged.org/dev/base64.css - 178.1Kb
GZIP-кодировка на стороне сервера
результирующий размер, отправленный клиенту (тест компонентов YSLOW): 59,3 КБ
Сохранение данных, отправленных клиентскому браузеру размером: 74,3 КБ
Хорошо, но это будет немного менее полезно для небольших изображений, я думаю.
ОБНОВЛЕНИЕ: Брайан МакКуэйд, инженер-программист из Google, работающий над PageSpeed, заявил на ChromeDevSummit 2013, что data: uris в CSS считается анти-паттерном, блокирующим рендеринг, для предоставления критического / минимального CSS во время своего выступления
#perfmatters: Instant mobile web apps
. Смотрите http://developer.chrome.com/devsummit/sessions и имейте это в виду - фактический слайд
источник
PRO:
ограничений кеша для сотовых устройств ...CON:
некоторые изображения следует рассматривать как контент, а не как простую презентацию, и, следовательно, они лучше подходят для тегов HTML IMG, чем фоновые изображения CSS.Ответы:
Это не очень хорошая идея, если вы хотите, чтобы ваши изображения и информация о стиле кэшировались отдельно. Кроме того, если вы кодируете большое изображение или значительное количество изображений в своем файле CSS, браузеру потребуется больше времени, чтобы загрузить файл, покидающий ваш сайт без какой-либо информации о стиле, до завершения загрузки. Для небольших изображений, которые вы не собираетесь менять часто, если это хорошее решение.
что касается генерации кодировки base64:
источник
Этот ответ устарел и не должен использоваться.
1) Средняя задержка намного выше на мобильных устройствах в 2017 году. Https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network
2) HTTP2 мультиплексы https://http2.github.io/faq/#why-is-http2-multiplexed
«URI данных» обязательно должны учитываться для мобильных сайтов. HTTP-доступ по сотовым сетям имеет большую задержку на запрос / ответ. Так что есть некоторые случаи использования, когда вставка изображений в виде данных в шаблоны CSS или HTML может быть полезна для мобильных веб-приложений. Вы должны измерять использование в каждом конкретном случае - я не сторонник того, чтобы URI данных использовались повсеместно в мобильном веб-приложении.
Обратите внимание, что мобильные браузеры имеют ограничения на общий размер файлов, которые могут быть кэшированы. Ограничения для iOS 3.2 были довольно низкими (25 КБ на файл), но увеличиваются (100 КБ) для новых версий Mobile Safari. Поэтому обязательно следите за общим размером файла при включении URI данных.
http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/
источник
Если вы ссылаетесь на это изображение только один раз, я не вижу проблемы, чтобы вставить его в ваш файл CSS. Но как только вы используете более одного изображения или вам нужно ссылаться на него несколько раз в вашем CSS, вы можете рассмотреть возможность использования одной карты изображений, вместо этого вы можете обрезать свои отдельные изображения (см. CSS-спрайты ).
источник
[emoji] {background-image: url(data:image/png;base64,qwedfcsfrtgyu/=);} [emoji=happy] {background-position: -20px 0px;}
Одна из вещей, которые я бы посоветовал - это иметь две отдельные таблицы стилей: одну с вашими обычными определениями стилей и другую, которая содержит ваши изображения в кодировке base64.
Вы должны включить базовую таблицу стилей перед таблицей стилей изображения, конечно.
Таким образом вы гарантируете, что ваша обычная таблица стилей будет загружена и применена как можно скорее к документу, но в то же время вы получите выгоду от сокращения http-запросов и других преимуществ data-uris.
источник
Base64 добавляет около 10% к размеру изображения после GZipped, но это перевешивает преимущества, когда дело доходит до мобильных устройств. Поскольку существует общая тенденция с адаптивным веб-дизайном, настоятельно рекомендуется.
W3C также рекомендует этот подход для мобильных устройств, и если вы используете конвейер ресурсов в рельсах, это функция по умолчанию при сжатии CSS
http://www.w3.org/TR/mwabp/#bp-conserve-css-images
источник
Я не согласен с рекомендацией создавать отдельные CSS-файлы для нередакторных изображений.
Предполагая, что изображения предназначены для пользовательского интерфейса, это стилизация уровня представления, и, как уже упоминалось выше, если вы работаете с мобильным интерфейсом, это определенно хорошая идея - сохранить все стили в одном файле, чтобы их можно было кэшировать один раз.
источник
В моем случае это позволяет мне применять таблицу стилей CSS, не беспокоясь о копировании связанных изображений, поскольку они уже встроены внутри.
источник
Я попытался создать онлайн концепцию инструмента анализатора CSS / HTML:
http://www.motobit.com/util/base64/css-images-to-base64.asp
Оно может:
Комментарии / предложения приветствуются.
Антонин
источник
Вы можете закодировать его в PHP :)
Источник
источник
Подводя немного для пользователей Sublime Text 2, есть плагин, который дает код base64, который мы загружаем изображения в ST.
Называется Image2base64: https://github.com/tm-minty/sublime-text-2-image2base64
PS: Никогда не сохраняйте этот файл, сгенерированный плагином, потому что он перезапишет файл и уничтожит.
источник
Спасибо за информацию здесь. Я считаю это вложение полезным и особенно для мобильных устройств, особенно с использованием кэшированного файла встроенных изображений.
Чтобы облегчить жизнь, так как мои файловые редакторы не обрабатывают это изначально, я сделал несколько простых сценариев для работы на ноутбуке / настольном компьютере, поделитесь ими на случай, если они пригодятся кому-либо еще. Я придерживался php, поскольку он обрабатывает эти вещи напрямую и очень хорошо.
Под Windows 8.1 говорят ---
... там, как администратор, вы можете установить ярлык для командного файла в вашем пути. Этот пакетный файл будет вызывать php (cli) скрипт.
Затем вы можете щелкнуть правой кнопкой мыши изображение в проводнике и отправить пакетный файл.
ОК, запрос Admiinstartor, и дождитесь закрытия черных окон командной оболочки.
Затем просто вставьте результат из буфера обмена в свой текстовый редактор ...
или
Следующее должно быть адаптируемо для других ОС.
Пакетный файл ...
И с php.exe на вашем пути, это вызывает скрипт php (cli) ...
источник
Насколько я исследовал,
Использование: 1. Когда вы используете svg sprite. 2. Когда ваши изображения имеют меньший размер (максимум 200 МБ).
Не используйте: 1. Когда вы большие изображения. 2. Иконки как SVG. Как они уже хороши и сжаты после сжатия.
источник