Я смотрел на источник почерка greasemonkey и заметил в своем css следующее:
.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}
Я могу понять, что greasemonkey script хочет связать все, что может, в источнике, а не размещать его на сервере, что достаточно очевидно. Но так как я раньше не видел эту технику, я рассматривал ее использование и, по-видимому, привлекателен по нескольким причинам:
- Это уменьшит количество HTTP-запросов при загрузке страницы, тем самым повысив производительность
- Если нет CDN, это уменьшит количество трафика, генерируемого через файлы cookie, отправленные вместе с изображениями
- Файлы CSS могут быть кэшированы
- Файлы CSS могут быть GZIPPED
Учитывая, что IE6 (например) имеет проблемы с кешем для фоновых изображений, кажется, что это не худшая идея...
Итак, это хорошая или плохая практика, почему бы вам не использовать ее и какие инструменты вы бы использовали для кодирования изображений base64?
update - результаты тестирования
-
тестирование с изображением: http://fragged.org/dev/map-shot.jpg - 133.6Kb
-
тестовый URL: http://fragged.org/dev/base64.html
-
выделенный файл CSS: http://fragged.org/dev/base64.css - 178.1Kb
-
Сторона сервера кодирования GZIP
-
итоговый размер, отправленный клиенту (YSLOW компонентов): 59.3Kb
-
Сохранение данных, отправленных в браузер клиента: 74.3Kb
Приятно, но он будет немного менее полезен для меньших изображений, я думаю.
ОБНОВЛЕНИЕ: Брайан МакКуад (Bryan McQuade), разработчик программного обеспечения Google, работающий на странице PageSpeed, заявил в ChromeDevSummit 2013, что данные: uris в CSS считается анти-шаблоном рендеринга для предоставления критического/минимального CSS во время его беседы
#perfmatters: Instant mobile web apps
. См. http://developer.chrome.com/devsummit/sessions и помните об этом - фактический слайд