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

[igolovin]

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

[Shedal]

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

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

[Smi1e]

Так весь CSS кешируется.

[iBear]

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

[ulitin]

или так duris.ru

[VasilioRuzanni]

Всмысле скорее «зачем шестой» :) Да и седьмой уже с приятной периодичностью сдает позиции.

[vitosik]

Я правда написал инже в каментах, но еще и здесь продублирую, для ie7 можно использовать mhtml — у него с ним проблем не будет.

[AHDPEu]

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

[Psih]

тянущиеся бекграунды?

[TiGR]

А какие с ними проблемы? Я засовывал тянущиеся в спрайты.

[Psih]

Про Clip написали ниже — не везде работает, что плохо.

[TiGR]

Я не про clip. Просто частенько элементы для которых используется бэкграунд с repeat-x, ограничены по высоте. В таком случае можно сложить в пачку несколько таких бэкграундов, в один спрайт, в который к тому же можно вставить и другие изображения.

[Psih]

Это вам не border-radius, которым как правило можно принебречь в IE.

[TiGR]

А какие проблемы со спрайтами в IE?

[Mithgol]

PIE легко обеспечит border-radius в IE.

[AHDPEu]

Согласен с Вами и Psih'ом. Действительно не случай для спрайтов

[TiGR]

Какая проблема? Ставим бэкграунд в самый верх спрайта, задаём положение отступом.

Не, я не спорю, что такие варианты бывают, но они очень редки.

[Serator]

Панацея со вкусом Firefox'а :)

[TiGR]

Самый главный вопрос в максимальной высоте элементов, к которым применяются эти фоны. Если это нечто невысокое (типа заголовков и других элементов), то вполне можно упаковать в спрайт.

[Jman]

И какие проблемы c clip? в IE он прекрасно работает, просто с маленькой особеностью. Для пнг (с фильтрами) часто использую. А проблема в запятых — уберите запятые, во всех браузерах не сломается а в IE заработает

[kuber]

Это назвается спрайты и это действительно на данный момент очень Хороший способ!

[GolDenOne]

Не подходит для анимированных гифов.

[folgakauchuk]

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

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

[kuber]

На сколько мелких? В спрайтах позиционирование с точностью в 1px.

[kuber]

Выше Вы все правильно написали.

[cubesun]

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

[uglymeta]

Вам явно слово «оптимизация» не знакомо. Экономия запросов к серверу это святое. Мы например в продакшен версиях всегда спецальными самописными скриптами собираем минимизированную версию из девелоперской. В итоге если открыть исходный код, то там в секции голова будут все стили в разделе, все скрипты в разделе и дальше тело с ногами, всё без переносов строк, выглядит стрёмно, но работает быстро. Запросы делаются только на необходимые картинки непосредственно в теле, которые нет смысла кодировать в base64, хотя будь моя воля я бы к одному запросу на сервер всё сводил.

[kuber]

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

Даже на маленькую картинку вы полчите кода в несколько метров, сильно сомневаюьс, что это украсит Ваш css файл.

[vitosik]

Держите:
100 картинок
jashkenas.s3.amazonaws.com/misc/jammit_example/normal.html

Все картинки в цсс
jashkenas.s3.amazonaws.com/misc/jammit_example/jammit.html

[kuber]

Я про код писал! А не про конечный результат.

[vitosik]

Насчет «нескольких метров» для маленькой картинки вы сильно преувеличиваете, посмотрите в примерах, что я скинул, а скорость загрузки сильно выше + gzip в помощь

[kuber]

> Насчет «нескольких метров» для маленькой картинки вы сильно преувеличиваете

Специально замерил, для картинки телефончика, что ниже при размере шрифта 11 pt нужно: почти 6 метром кода

Преувеличил?

[vitosik]

Ок, согласен насчет осторожности при использовании такого метода, но в приведенных мною примеров гигантского размера я не увидел.

[kuber]

А Вы код смотрели? Первая же галочка тянет на:
2,5 метра кода
При тех же 11pt.

Остальные примерно также или больше.

[kuber]

А теперь представьте у нас 10 картинок и в итоге это выльется в 30 метров кода и что это хранить вместе с нашим основным CSS кодом? Но, постойте CSS отвечает за стили и хранить в нем 30 метров абракадабр как то не правильно.

Конечно, можно выделить отдельный файл images.css, чтобы убрать всю эту «красоту» в отдельный файл, но тогда на чем мы выигрываем?
2 CSS файла VS 1 CSS и 1 спрайт.

[vitosik]

Специально для этого есть решения, позволяющие упаковывать ваши картинки в цсс при деплое на прод. Не вижу в этом проблем.

[kuber]

В том то и проблема, что Вы не видите.

Сервисы по упаковке, хорошо, а если он недоступен?

PHP скрипт с регуляркой, а Вы учитвали, что при этом возрастет нагрузка на web-сервер?

Вы не провели достаточное исследование.

[vitosik]

Я не использую сервисы, в моем случае (это рельсы), есть такой инструмент ка jammit github.com/documentcloud/jammit, который как раз пакует картинки в цсс, помимо множества других плюшек.

Возможно для php есть что-то подобное, не берусь утверждать…

[vitosik]

И пакует он это все перед деплоем на прод.

[Chikiro]

Вы предлагаете упаковывать при каждом клиентсокм запросе?

[kuber]

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

[andoriyu]

Какой же вы тупой.

[TiGR]

Извините, я что-то не понял. Можете пояснить, где там 6 метров?

[kuber]

Перейдите по ссылке ниже!

[TiGR]

Там одна страница текста. Где 6 метров?

[kuber]

Ответ: 32 строки * 18 см = 576 см, что примерно 6 метров.

[vitosik]

Очень неожиданно, если честно )

Я просто не мог проверить до сего момента, то, что вы указывали в примерах и был крайне удивлен, результирующим кодом в 6 kb, а вы оказывается про длину говорили…

[vitosik]

не kb, а mb — метрах, очепятка

[TiGR]

Строчка в 18 см?!

Надо было хотя бы раз вставить тег irony…

[kuber]

Неужели только мне нравится, когда код красивый (это ведь все таки стили)? И в нем нету сотен строк абракадабр?

[TiGR]

Если оно делается в автомате при deploy, то кому какая разница?

[Minras]

А у нас тут ещё 31 марта…
Спасибо, за поднятое настроение :)))

[kuber]

Вот посмотрите как будет выглядить код, для маленькой картинки:Посмотреть

[kuber]

А вот сама картинка:

[vitosik]

Для цссок скорее подойдет большое количество маленьких изображений <= 1 kb, ну а потолок 32kb, поскольку восьмой ie их не переваривает.

[pro100tak]

Эффект как раз есть. И вполне материальный:
— увеличивается время загрузки страницы
— поступает команда: «Сделать быстрее, чтоб всё было ОК»
— картинки прячутся в CSS, а его, в свою очередь, забирает к себе CDN и отдаёт быстро-быстро много-много

Имеем — довольных посетителей, довольных заказчиков, премии и т.п. за один день работы

[cubesun]

Если какой-нибудь портал при этом станет грузиться на 5-10 секунд быстрее, то это, конечно, круто, полезно и нужно:) А если речь идет о миллисекундах, то ситуация совсем уже другая.

[stolen]

У некоторых пользователей одно HTTP-соединение может открываться порядка секунды. При плохих пингах до пользователя, но вменяемых скоростях соединения профит от вписанных картинок очевиден.

[kuber]

Очень сложный вопрос. Дело в том, что Base64 код вполне может весить больше, чем картинка в web-форматах.

[vitosik]

gzip нивелирует эту разницу

[kuber]

Это зависит от конкретной картинки!

[panki61]

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

[Serator]

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

[vitosik]

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

[vitosik]

Вот пример рабочей цсски для семерки:
jashkenas.s3.amazonaws.com/misc/jammit_example/assets/silk-mhtml.css

[xargon]

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

[vitosik]

Для ie7 есть вполне «нормально» решение.

[Ewka]

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

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

[hellman]

Ага. Из каждых 3х байтов получаются 4.

[SdotR]

В сыром http-запросе помимо всего прочего идет куча всякой фигни. За счет этого и получается экономия, но только для небольших файлов (навскидку, < 1 KiB).

[AYShestakov]

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

[kuber]

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

[kuber]

Тогда удовлетворите наше любопытство и сделайте настоящее исследование расставив хоть какие-то точки над и. Например, вот так:

• Необходимо будет решить вопрос с размером картинок. Во первых изучить алгоритм Base64. Пережать, скажем сотню картинок. Выявить закономерности (Например, если в картинке есть градиент, то она скорее всего увеличится). Оформить графики. Сделать Выводы.
• Отобрать набор тестовых картинок (желательно разнотипных, типы должны появится из первого эксперемента). Загружать сайты с картинками с различных Web-серверов, машин, браузеров, в разное время суток в виде отдельных картинок, спрайтов, css. Оформить графики. Сделать Выводы.
• Изучить нагрузку на Web-сервер без перекодирования и с кодирование картинок в Base64. Сделать Выводы.
• Подвести общие итоги. Выписать плюсы и минусы. Дать конкретные рекомендации к каким картинкам и в каких случаях лучше применять этот метод, а в каких не стоит

Конечно, можно еще много чего добавить. Например, обзор сервисов (инструментов) для упоковки картинок в css.

Вот это было бы интересно.

[TEHEK]

Base64 не занимается сжатием. Он просто перегруппировывает набор битов из групп по 8 в группы по 7 битов (очень упрощенно выражаясь), которые потом представляются в виде букв, цифр и пары спецсимволов. Таким образом, размера полученной последовательности можно прбилизительно оценить как originalSize*8/7.

Так что первые 2 пункта вроде как не нужны. Нагрузка на веб-сервер — это уже интереснее, хотя тут все-таки слишком много вариантов, но опять-таки все уже давно обсудили и даже тут на хабре =)

[Hoorsh]

Реальная загрузка хороша видна невооруженным глазом на примере из комментов.

До оптимизации ~ 5 сек.
После оптимизации ~ 0.5 сек.

[kuber]

Хорошо начало положено, только вот а где спрайты?

[AYShestakov]

Все это должно быть в топике, а не в комментах. И блог выбрали правильно, так предшественников почитайте. И основоположника клиентской оптимизации на хабре sunnybear к примеру — его сайт www.webo.in

[kuber]

Да, только не в таком виде. На webo.in и небольшой видеокурс есть по клиентской оптимизации. Автору можно и его рекомендовать.

[orionll]

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

[Ruberoid]

Поговорим по этому поводу через пять лет, ок? Занесите в календарь напоминалку.

[Yavanosta]

Еще год остался.

[Ruberoid]

Полагаю, вопрос уже исчерпан. Даю новый прогноз. Еще пять лет и десктопы останутся только в памяти большой цивилизации. Интернет есть всё и интернет есть везде.

[Zenitchik]

И на чём Вы будете кодить?

[pxx]

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

[pxx]

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

[Ruberoid]

Гораздо, это во сколько?
Вам же написали, логика немного страдает. Сначала разметка, затем стили. Все правильно и логично, достаточно для того, чтобы клацнуть по рубрикатору или «на главную». Затем картинки.
В случае картинок в css, стройная система слегка смещается.
Да и почему Вы почему так напуганы соединениями?

[Hellcunt]

> Да и почему Вы почему так напуганы соединениями?

Соединение с сервером одна из самых затратных операций. Чем меньше соединений, тем быстрее грузится сайт. Да и на сервер нагрузка меньше.

[savostin]

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

[dom1n1k]

Кстати, да, любопытный вопрос. Имею большой опыт сидения на дорогом жпрс-е.

Поразмышлял — выходит даже плюс. Ясно же, что в CSS имеет смысл засовывать мелкие картинки: значки, кнопки, пиктограммки, скругленные уголки и т.п. Они много не весят и вполне посильны даже для мобильной связи. И самое главное, зачастую без них макет выглядит неполноценно — непонятно куда можно кликать, теряются иконки статусов и т.д. (хотя отчасти это вопрос аккуратности разработчика). Зачастую хочется как раз эту копеечную мелочь врубить, оставив отключенными большие картинки основного контента.

Но дело в том, что если обычную картинку (тег IMG) можно легко посмотреть через команду контекстного меню, то изображение, подстеленное через css::background, отдельно просмотреть невозможно! Только включив вообще все картинки. Ну если не рассматривать варианты с файрбагом и копание в исходниках.

[Glivera]

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

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

[Rekrut]

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

[kirilloid]

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

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

[kirilloid]

Я и не говорил, что всё. Но с такими соотношениями для 99% сайтов data/uri будет точно выгодней. Хотя совсем не исключено, что спрайты будут еще выгодней.

[ComodoHacker]

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

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

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

[dyakov]

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

[Rekrut]

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

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

[igrishaev]

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

[igrishaev]

Может, пригодится кому: pastebin.com/ar78MWPm

[Tomasina]

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

[varg242]

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

[ValeriyKr]

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

[Den1xxx]

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

[LeonidFrolov]

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

[naarende]

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

[Zenitchik]

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