Comments 131
Насколько я знаю, чужие посты публиковать нельзя.
Было бы хорошо, если бы вы написали точно, работает ли это в IE6/7; в противном случае использование этого приема сильно ограничено.
Еще интересно, не падает ли скорость загрузки страницы при повсеместном использовании этого приема. Ведь обычные картинки браузер кеширует, а сохраненные в css — вряд ли.
Еще интересно, не падает ли скорость загрузки страницы при повсеместном использовании этого приема. Ведь обычные картинки браузер кеширует, а сохраненные в css — вряд ли.
К сожалению, в IE6-7 работать не будет, понадобится бубен.
или так duris.ru
Я правда написал инже в каментах, но еще и здесь продублирую, для ie7 можно использовать mhtml — у него с ним проблем не будет.
Можно пример картинки, который нельзя засунуть в спрайт?
тянущиеся бекграунды?
А какие с ними проблемы? Я засовывал тянущиеся в спрайты.
Про Clip написали ниже — не везде работает, что плохо.
Это вам не border-radius, которым как правило можно принебречь в IE.
А какие проблемы со спрайтами в IE?
PIE легко обеспечит border-radius в IE.
Согласен с Вами и Psih'ом. Действительно не случай для спрайтов
Какая проблема? Ставим бэкграунд в самый верх спрайта, задаём положение отступом.
Не, я не спорю, что такие варианты бывают, но они очень редки.
Не, я не спорю, что такие варианты бывают, но они очень редки.
Панацея со вкусом Firefox'а :)
Самый главный вопрос в максимальной высоте элементов, к которым применяются эти фоны. Если это нечто невысокое (типа заголовков и других элементов), то вполне можно упаковать в спрайт.
И какие проблемы c clip? в IE он прекрасно работает, просто с маленькой особеностью. Для пнг (с фильтрами) часто использую. А проблема в запятых — уберите запятые, во всех браузерах не сломается а в IE заработает
Это назвается спрайты и это действительно на данный момент очень Хороший способ!
Не подходит для анимированных гифов.
так вроде же говорится о
мелких картинках, которые нельзя засунуть в спрайты
Хз, насколько это целесообразно. Время на разработку увеличивается (время = деньги), а эффекта почти нет. Но прикольно:)
Вам явно слово «оптимизация» не знакомо. Экономия запросов к серверу это святое. Мы например в продакшен версиях всегда спецальными самописными скриптами собираем минимизированную версию из девелоперской. В итоге если открыть исходный код, то там в секции голова будут все стили в разделе, все скрипты в разделе и дальше тело с ногами, всё без переносов строк, выглядит стрёмно, но работает быстро. Запросы делаются только на необходимые картинки непосредственно в теле, которые нет смысла кодировать в base64, хотя будь моя воля я бы к одному запросу на сервер всё сводил.
Очень зря, что автор не привел реальный пример, чтобы все увидели, что пользоваться таким способом нужно очень осторожно.
Даже на маленькую картинку вы полчите кода в несколько метров, сильно сомневаюьс, что это украсит Ваш css файл.
Даже на маленькую картинку вы полчите кода в несколько метров, сильно сомневаюьс, что это украсит Ваш css файл.
Держите:
100 картинок
jashkenas.s3.amazonaws.com/misc/jammit_example/normal.html
Все картинки в цсс
jashkenas.s3.amazonaws.com/misc/jammit_example/jammit.html
100 картинок
jashkenas.s3.amazonaws.com/misc/jammit_example/normal.html
Все картинки в цсс
jashkenas.s3.amazonaws.com/misc/jammit_example/jammit.html
Я про код писал! А не про конечный результат.
Насчет «нескольких метров» для маленькой картинки вы сильно преувеличиваете, посмотрите в примерах, что я скинул, а скорость загрузки сильно выше + gzip в помощь
> Насчет «нескольких метров» для маленькой картинки вы сильно преувеличиваете
Специально замерил, для картинки телефончика, что ниже при размере шрифта 11 pt нужно: почти 6 метром кода
Преувеличил?
Специально замерил, для картинки телефончика, что ниже при размере шрифта 11 pt нужно: почти 6 метром кода
Преувеличил?
Ок, согласен насчет осторожности при использовании такого метода, но в приведенных мною примеров гигантского размера я не увидел.
А Вы код смотрели? Первая же галочка тянет на:
2,5 метра кода
При тех же 11pt.
Остальные примерно также или больше.
2,5 метра кода
При тех же 11pt.
Остальные примерно также или больше.
А теперь представьте у нас 10 картинок и в итоге это выльется в 30 метров кода и что это хранить вместе с нашим основным CSS кодом? Но, постойте CSS отвечает за стили и хранить в нем 30 метров абракадабр как то не правильно.
Конечно, можно выделить отдельный файл images.css, чтобы убрать всю эту «красоту» в отдельный файл, но тогда на чем мы выигрываем?
2 CSS файла VS 1 CSS и 1 спрайт.
Конечно, можно выделить отдельный файл images.css, чтобы убрать всю эту «красоту» в отдельный файл, но тогда на чем мы выигрываем?
2 CSS файла VS 1 CSS и 1 спрайт.
Специально для этого есть решения, позволяющие упаковывать ваши картинки в цсс при деплое на прод. Не вижу в этом проблем.
В том то и проблема, что Вы не видите.
Сервисы по упаковке, хорошо, а если он недоступен?
PHP скрипт с регуляркой, а Вы учитвали, что при этом возрастет нагрузка на web-сервер?
Вы не провели достаточное исследование.
Сервисы по упаковке, хорошо, а если он недоступен?
PHP скрипт с регуляркой, а Вы учитвали, что при этом возрастет нагрузка на web-сервер?
Вы не провели достаточное исследование.
Я не использую сервисы, в моем случае (это рельсы), есть такой инструмент ка jammit github.com/documentcloud/jammit, который как раз пакует картинки в цсс, помимо множества других плюшек.
Возможно для php есть что-то подобное, не берусь утверждать…
Возможно для php есть что-то подобное, не берусь утверждать…
Вы предлагаете упаковывать при каждом клиентсокм запросе?
Извините, я что-то не понял. Можете пояснить, где там 6 метров?
Перейдите по ссылке ниже!
Там одна страница текста. Где 6 метров?
Ответ: 32 строки * 18 см = 576 см, что примерно 6 метров.
Очень неожиданно, если честно )
Я просто не мог проверить до сего момента, то, что вы указывали в примерах и был крайне удивлен, результирующим кодом в 6 kb, а вы оказывается про длину говорили…
Я просто не мог проверить до сего момента, то, что вы указывали в примерах и был крайне удивлен, результирующим кодом в 6 kb, а вы оказывается про длину говорили…
Строчка в 18 см?!
Надо было хотя бы раз вставить тег irony…
Надо было хотя бы раз вставить тег irony…
А у нас тут ещё 31 марта…
Спасибо, за поднятое настроение :)))
Спасибо, за поднятое настроение :)))
Вот посмотрите как будет выглядить код, для маленькой картинки:Посмотреть
А вот сама картинка:
Эффект как раз есть. И вполне материальный:
— увеличивается время загрузки страницы
— поступает команда: «Сделать быстрее, чтоб всё было ОК»
— картинки прячутся в CSS, а его, в свою очередь, забирает к себе CDN и отдаёт быстро-быстро много-много
Имеем — довольных посетителей, довольных заказчиков, премии и т.п. за один день работы
— увеличивается время загрузки страницы
— поступает команда: «Сделать быстрее, чтоб всё было ОК»
— картинки прячутся в CSS, а его, в свою очередь, забирает к себе CDN и отдаёт быстро-быстро много-много
Имеем — довольных посетителей, довольных заказчиков, премии и т.п. за один день работы
Очень сложный вопрос. Дело в том, что Base64 код вполне может весить больше, чем картинка в web-форматах.
Храните картинки на разных доменах и разных железках, это полезнее будет.
Не знаю в который раз уже пишут о Data Uri (очень много...), но можно же было хоть в ~ 100500-ый раз написать, что собирать изображение в строку нужно автоматически, а не руками. Следовательно проблем со сложностью обновления изображений быть не должно. Да и sprit'ы можно тоже в Data Uri засовывать…
Для ie7 можно использовать mhtml en.wikipedia.org/wiki/MHTML
Вот пример рабочей цсски для семерки:
jashkenas.s3.amazonaws.com/misc/jammit_example/assets/silk-mhtml.css
jashkenas.s3.amazonaws.com/misc/jammit_example/assets/silk-mhtml.css
Я правильно понимаю, что для 5-7 IE мы добавляем костыль в виде скрипта, и количество запросов становится тем же?)
Для ie7 есть вполне «нормально» решение.
иногда уменьшение результативного объема изображения на больших файлах.
Интересно как, если мне не изменяет память base64 увеличивает объем процентов на 30
Интересно как, если мне не изменяет память base64 увеличивает объем процентов на 30
Это обсуждалось столько раз и base64 и спрайты — и то и другое давно успешно применяется.
Что нового Вы открылимиру хабру?
Что нового Вы открыли
Автор ничего не открыл. И более того, не достаточно хорошо изучил вопрос. Изначально не привел никаких сведений о реальном изменении размера изображений до кодирования и после него, о замере времени реальной загрузки и т.д.
Тогда удовлетворите наше любопытство и сделайте настоящее исследование расставив хоть какие-то точки над и. Например, вот так:
Конечно, можно еще много чего добавить. Например, обзор сервисов (инструментов) для упоковки картинок в css.
Вот это было бы интересно.
- Необходимо будет решить вопрос с размером картинок. Во первых изучить алгоритм Base64. Пережать, скажем сотню картинок. Выявить закономерности (Например, если в картинке есть градиент, то она скорее всего увеличится). Оформить графики. Сделать Выводы.
- Отобрать набор тестовых картинок (желательно разнотипных, типы должны появится из первого эксперемента). Загружать сайты с картинками с различных Web-серверов, машин, браузеров, в разное время суток в виде отдельных картинок, спрайтов, css. Оформить графики. Сделать Выводы.
- Изучить нагрузку на Web-сервер без перекодирования и с кодирование картинок в Base64. Сделать Выводы.
- Подвести общие итоги. Выписать плюсы и минусы. Дать конкретные рекомендации к каким картинкам и в каких случаях лучше применять этот метод, а в каких не стоит
Конечно, можно еще много чего добавить. Например, обзор сервисов (инструментов) для упоковки картинок в css.
Вот это было бы интересно.
Base64 не занимается сжатием. Он просто перегруппировывает набор битов из групп по 8 в группы по 7 битов (очень упрощенно выражаясь), которые потом представляются в виде букв, цифр и пары спецсимволов. Таким образом, размера полученной последовательности можно прбилизительно оценить как originalSize*8/7.
Так что первые 2 пункта вроде как не нужны. Нагрузка на веб-сервер — это уже интереснее, хотя тут все-таки слишком много вариантов, но опять-таки все уже давно обсудили и даже тут на хабре =)
Так что первые 2 пункта вроде как не нужны. Нагрузка на веб-сервер — это уже интереснее, хотя тут все-таки слишком много вариантов, но опять-таки все уже давно обсудили и даже тут на хабре =)
Реальная загрузка хороша видна невооруженным глазом на примере из комментов.
До оптимизации ~ 5 сек.
После оптимизации ~ 0.5 сек.
До оптимизации ~ 5 сек.
После оптимизации ~ 0.5 сек.
Хорошо начало положено, только вот а где спрайты?
Все это должно быть в топике, а не в комментах. И блог выбрали правильно, так предшественников почитайте. И основоположника клиентской оптимизации на хабре sunnybear к примеру — его сайт www.webo.in
Для мобильных браузеров с отключенными картинками этот вариант плох: придется качать весь css файл
Сравниваю 2 диаграмы загрузки ресурсов и не могу понять, как на второй base64 изображения начали грузиться одновременно со страницей. И как вообще в таком случае определено понятие «загрузки» изображений, если они — часть css?
Я вижу еще значительные недостатки, которые не указаны в статье:
1. Чтобы не потерять в удобстве расширения и изменения макета/стилей нужно писать некий скрипт, который бы парсил CSS-ы и подменял URI фоновых картинок на их base64 эквиваленты, а потом заменял подключение developer-friendly CSS-ов на сгенерированные.
2. Если одно изображение используется несколько раз возникает значительная избыточность.
3. Если рассматривать подход без использования base64, то сначала загружается HTML — рендерится разметка, следом CSS — применяются стили разметки (размеры, колонки, шрифты, бла-бла), а потом уже загружаются фоновые изображения, дополняя страницу деталями. В данном случае зачастую первых двух действий относительно достаточно для взаимодействия пользователя со страницей.
В случае с base64 значительно увеличивается размер CSS файла, замедляя загрузку стилей разметки, замедляя тем самым рендеринг макета и изменяя логичный (по моему мнению) ход вещей.
1. Чтобы не потерять в удобстве расширения и изменения макета/стилей нужно писать некий скрипт, который бы парсил CSS-ы и подменял URI фоновых картинок на их base64 эквиваленты, а потом заменял подключение developer-friendly CSS-ов на сгенерированные.
2. Если одно изображение используется несколько раз возникает значительная избыточность.
3. Если рассматривать подход без использования base64, то сначала загружается HTML — рендерится разметка, следом CSS — применяются стили разметки (размеры, колонки, шрифты, бла-бла), а потом уже загружаются фоновые изображения, дополняя страницу деталями. В данном случае зачастую первых двух действий относительно достаточно для взаимодействия пользователя со страницей.
В случае с base64 значительно увеличивается размер CSS файла, замедляя загрузку стилей разметки, замедляя тем самым рендеринг макета и изменяя логичный (по моему мнению) ход вещей.
Гораздо, это во сколько?
Вам же написали, логика немного страдает. Сначала разметка, затем стили. Все правильно и логично, достаточно для того, чтобы клацнуть по рубрикатору или «на главную». Затем картинки.
В случае картинок в css, стройная система слегка смещается.
Да и почему Вы почему так напуганы соединениями?
Вам же написали, логика немного страдает. Сначала разметка, затем стили. Все правильно и логично, достаточно для того, чтобы клацнуть по рубрикатору или «на главную». Затем картинки.
В случае картинок в css, стройная система слегка смещается.
Да и почему Вы почему так напуганы соединениями?
А как отключить картинки? В смысле теперь при отключении картинок трафик не экономится.
Кстати, да, любопытный вопрос. Имею большой опыт сидения на дорогом жпрс-е.
Поразмышлял — выходит даже плюс. Ясно же, что в CSS имеет смысл засовывать мелкие картинки: значки, кнопки, пиктограммки, скругленные уголки и т.п. Они много не весят и вполне посильны даже для мобильной связи. И самое главное, зачастую без них макет выглядит неполноценно — непонятно куда можно кликать, теряются иконки статусов и т.д. (хотя отчасти это вопрос аккуратности разработчика). Зачастую хочется как раз эту копеечную мелочь врубить, оставив отключенными большие картинки основного контента.
Но дело в том, что если обычную картинку (тег IMG) можно легко посмотреть через команду контекстного меню, то изображение, подстеленное через css::background, отдельно просмотреть невозможно! Только включив вообще все картинки. Ну если не рассматривать варианты с файрбагом и копание в исходниках.
Поразмышлял — выходит даже плюс. Ясно же, что в CSS имеет смысл засовывать мелкие картинки: значки, кнопки, пиктограммки, скругленные уголки и т.п. Они много не весят и вполне посильны даже для мобильной связи. И самое главное, зачастую без них макет выглядит неполноценно — непонятно куда можно кликать, теряются иконки статусов и т.д. (хотя отчасти это вопрос аккуратности разработчика). Зачастую хочется как раз эту копеечную мелочь врубить, оставив отключенными большие картинки основного контента.
Но дело в том, что если обычную картинку (тег IMG) можно легко посмотреть через команду контекстного меню, то изображение, подстеленное через css::background, отдельно просмотреть невозможно! Только включив вообще все картинки. Ну если не рассматривать варианты с файрбагом и копание в исходниках.
Давно пользуюсь data:url и могу сказать что все описанные недостатки нивелируются достоинствами этого метода оптимизации при его правильном использовании. Я имею в виду использование «быстрых» css селекторов, группировку селекторов при подключении одного изображения в разных местах, gzip сжатие. Время до показа страницы может немного и увеличивается, но незначительно и в большинстве случаев после этого человек получает уже практически полностью загруженную страницу и общее впечатление остается лучше чем когда страница грузится постепенно.
А на счет большого времени при изменении дизайна я категорически не соглашусь. Если сравнить время на изменения в дизайне при использовании data:url и его аналога css-спрайтов. То тут и обсуждать нечего data:url быстрее и удобнее. И это если еще не брать во внимание ограничения которые накладывает использование css-спрайтов. Я до сих пор с ужасом вспоминаю случаи когда заказчик просил внести большие изменения в спрайт из 40+ изображений.
А на счет большого времени при изменении дизайна я категорически не соглашусь. Если сравнить время на изменения в дизайне при использовании data:url и его аналога css-спрайтов. То тут и обсуждать нечего data:url быстрее и удобнее. И это если еще не брать во внимание ограничения которые накладывает использование css-спрайтов. Я до сих пор с ужасом вспоминаю случаи когда заказчик просил внести большие изменения в спрайт из 40+ изображений.
А как в случае с IE < 8 происходит работа? Там же ведь по сути не css, а значит надо будет писать еще один css, в котором картинки подключаются обычным образом. И кстати картинки, то в таком случае не станут дергаться с сервера?
До / после
Увеличил объём данных в 2 раза, зато уменьшили число запросов в 50 раз.
Понятно, что станет лучше.
Вообще, у меня есть идея как оценивать такие штуки чисто теоретически.
Смотрим цены на запросы и трафик, например, на Amazon S3 и считаем, что выгодней по деньгам. Где по деньгам выгодней — там и нагрузка будет меньше, скорей всего.
Увеличил объём данных в 2 раза, зато уменьшили число запросов в 50 раз.
Понятно, что станет лучше.
Вообще, у меня есть идея как оценивать такие штуки чисто теоретически.
Смотрим цены на запросы и трафик, например, на Amazon S3 и считаем, что выгодней по деньгам. Где по деньгам выгодней — там и нагрузка будет меньше, скорей всего.
> Кодируем изображение в base64 с помощью онлайн сервисов
Вот этого не надо IMHO советовать. Мало ли какой эксплойт они там подсунут/подмешают.
Лучше добавьте ссылку на удобный инструмент, которым легко пользоваться у себя.
Вот этого не надо IMHO советовать. Мало ли какой эксплойт они там подсунут/подмешают.
Лучше добавьте ссылку на удобный инструмент, которым легко пользоваться у себя.
Только для автоматической, так называемой, компиляции css, исходники имхо должны оставаться поддерживаемыми
Вот нашел несколько интересных статей.
Про скорость рендеринга таких картинок: data:URI и производительность, или как замедлить Firefox в 10 (десять) раз
И еще вот: Кроссбраузерное использование data:URL
Про скорость рендеринга таких картинок: data:URI и производительность, или как замедлить Firefox в 10 (десять) раз
И еще вот: Кроссбраузерное использование data:URL
Спасибо, у меня в текущем проекте как раз много мелких иконок.
Написал себе python-скрипт для конвертации url("../path") в url(data:image/png;base64, data)
Написал себе python-скрипт для конвертации url("../path") в url(data:image/png;base64, data)
Может, пригодится кому: pastebin.com/ar78MWPm
а что значит «картинки нельзя засунуть в спрайты»?
OK, а как тогда определённый слой SVG таким образом использовать?
Допустим, мы упаковали SVG в base64, прописали правильный mime (
Допустим, мы упаковали 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 и готово.
Вот это раньше холивары были!)) А ведь эту статью могут найти в поиске до сих пор и прочитать и пойти делать всё из неё..))
Sign up to leave a comment.
Храните мелкие картинки в CSS