Храните мелкие картинки в CSS

Насколько я знаю, чужие посты публиковать нельзя.

Было бы хорошо, если бы вы написали точно, работает ли это в IE6/7; в противном случае использование этого приема сильно ограничено.

Еще интересно, не падает ли скорость загрузки страницы при повсеместном использовании этого приема. Ведь обычные картинки браузер кеширует, а сохраненные в css — вряд ли.

К сожалению, в IE6-7 работать не будет, понадобится бубен.

так вроде же говорится о

мелких картинках, которые нельзя засунуть в спрайты

Хз, насколько это целесообразно. Время на разработку увеличивается (время = деньги), а эффекта почти нет. Но прикольно:)

Храните картинки на разных доменах и разных железках, это полезнее будет.

Не знаю в который раз уже пишут о Data Uri (очень много...), но можно же было хоть в ~ 100500-ый раз написать, что собирать изображение в строку нужно автоматически, а не руками. Следовательно проблем со сложностью обновления изображений быть не должно. Да и sprit'ы можно тоже в Data Uri засовывать…

Для ie7 можно использовать mhtml en.wikipedia.org/wiki/MHTML

Я правильно понимаю, что для 5-7 IE мы добавляем костыль в виде скрипта, и количество запросов становится тем же?)

иногда уменьшение результативного объема изображения на больших файлах.

Интересно как, если мне не изменяет память base64 увеличивает объем процентов на 30

Это обсуждалось столько раз и base64 и спрайты — и то и другое давно успешно применяется.
Что нового Вы открыли миру хабру?

Для мобильных браузеров с отключенными картинками этот вариант плох: придется качать весь css файл

Сравниваю 2 диаграмы загрузки ресурсов и не могу понять, как на второй base64 изображения начали грузиться одновременно со страницей. И как вообще в таком случае определено понятие «загрузки» изображений, если они — часть css?

Я вижу еще значительные недостатки, которые не указаны в статье:
1. Чтобы не потерять в удобстве расширения и изменения макета/стилей нужно писать некий скрипт, который бы парсил CSS-ы и подменял URI фоновых картинок на их base64 эквиваленты, а потом заменял подключение developer-friendly CSS-ов на сгенерированные.
2. Если одно изображение используется несколько раз возникает значительная избыточность.
3. Если рассматривать подход без использования base64, то сначала загружается HTML — рендерится разметка, следом CSS — применяются стили разметки (размеры, колонки, шрифты, бла-бла), а потом уже загружаются фоновые изображения, дополняя страницу деталями. В данном случае зачастую первых двух действий относительно достаточно для взаимодействия пользователя со страницей.
В случае с base64 значительно увеличивается размер CSS файла, замедляя загрузку стилей разметки, замедляя тем самым рендеринг макета и изменяя логичный (по моему мнению) ход вещей.

А как отключить картинки? В смысле теперь при отключении картинок трафик не экономится.

Давно пользуюсь data:url и могу сказать что все описанные недостатки нивелируются достоинствами этого метода оптимизации при его правильном использовании. Я имею в виду использование «быстрых» css селекторов, группировку селекторов при подключении одного изображения в разных местах, gzip сжатие. Время до показа страницы может немного и увеличивается, но незначительно и в большинстве случаев после этого человек получает уже практически полностью загруженную страницу и общее впечатление остается лучше чем когда страница грузится постепенно.

А на счет большого времени при изменении дизайна я категорически не соглашусь. Если сравнить время на изменения в дизайне при использовании data:url и его аналога css-спрайтов. То тут и обсуждать нечего data:url быстрее и удобнее. И это если еще не брать во внимание ограничения которые накладывает использование css-спрайтов. Я до сих пор с ужасом вспоминаю случаи когда заказчик просил внести большие изменения в спрайт из 40+ изображений.

А как в случае с IE < 8 происходит работа? Там же ведь по сути не css, а значит надо будет писать еще один css, в котором картинки подключаются обычным образом. И кстати картинки, то в таком случае не станут дергаться с сервера?

До / после
Увеличил объём данных в 2 раза, зато уменьшили число запросов в 50 раз.
Понятно, что станет лучше.

Вообще, у меня есть идея как оценивать такие штуки чисто теоретически.
Смотрим цены на запросы и трафик, например, на Amazon S3 и считаем, что выгодней по деньгам. Где по деньгам выгодней — там и нагрузка будет меньше, скорей всего.

> Кодируем изображение в base64 с помощью онлайн сервисов

Вот этого не надо IMHO советовать. Мало ли какой эксплойт они там подсунут/подмешают.

Лучше добавьте ссылку на удобный инструмент, которым легко пользоваться у себя.

Только для автоматической, так называемой, компиляции css, исходники имхо должны оставаться поддерживаемыми

Вот нашел несколько интересных статей.

Про скорость рендеринга таких картинок: data:URI и производительность, или как замедлить Firefox в 10 (десять) раз
И еще вот: Кроссбраузерное использование data:URL

Спасибо, у меня в текущем проекте как раз много мелких иконок.
Написал себе python-скрипт для конвертации url("../path") в url(data:image/png;base64, data)

а что значит «картинки нельзя засунуть в спрайты»?

OK, а как тогда определённый слой SVG таким образом использовать?
Допустим, мы упаковали SVG в base64, прописали правильный mime (image/svg+xml), а как слой тогда указать (было, например, filters.svg#superslice).

Вот монстры интернета, например, Google и Apple на своих сайтах используют спрайты. Думаю лучше использовать именно их. Еще и редактировать удобно (в какой-то мере) — открыл один файл и правишь львиную часть дизайна. Удобно.

Круть — анимированный гиф тоже поддерживается севрисом www.dailycoding.com/Utils/Converter/ImageToBase64.aspx

Emmet, который есть почти для всех популярных редакторов, кроме чудесного Zen coding в том числе умеет по шорткату конвертировать изображения в base64. В Coda 2 — курсор в любое место URL с изображением, Ctrl+I и готово.

Вот это раньше холивары были!)) А ведь эту статью могут найти в поиске до сих пор и прочитать и пойти делать всё из неё..))