Картинки в теле страницы с помощью data: URL

[zerkms]

в минусах не написано, что инлайн картинки не получится закешировать, по определению :-)

[grokinn]

а еще опера с выключенными картинками эти картинки все равно не покажет а трафик на них уйдет)

[mobilz]

если они будут в css, то почему нет?

[zerkms]

а, разве что в цсс. пардон тогда...

[Stepanow]

А как-же это?

Такие изображения, внедренные в HTML-страницы, не кешируются для повторного использования, и они не кешируются от странице к странице ... Однако, CSS кешируется браузерами, и такие изображения могут быть повторно использованы вместе с использующим их селектором

[w00d]

Шифт забыли нажать в первой строке недостатков. (57ndash;7,)

[ioio]

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

[sunnybear]

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

[Kudja]

хотя и не считаю этот способ необходимым, т.к. есть масса прокси серверов...
но по поводу правки Вы не правы... кто Вам мешает написать функцию, которая при генерации страницы будет вставлять картинку. Я думаю оно изначально так и подразумевается, не будеш же ручками это все вставлять )) - это извращение получится

[johndow]

IE 6-7 можно заставить понять base64 кодированные картинки - но это жесточайшее извращение ))
к примеру http://bolknote.ru/2006.08.24

[pavelvk]

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

[maiden]

Познавательно. Хотя, не вижу смысла для практического применения этого метода. Для меня минусы перевешивают плюсы.

Во-первых работает не везде.
Во-вторых данные надо кодировать, чтобы поместить в код, что неудобно.
В третьих, траффик особо не экономится, так как данные все равно передаются, экономится только количество запросов к серверу. Что есть палка о двух концах.

Но за статью спасибо, узнать про это было интересно.

[khim]

Хех. Не очень понятно где использовать этот приём. Вроде бы такие вещи должны быть хороши для навигационных картинок, но тут лучше использовать другой приём - тот, который давно используется на простой странице поиска Гугла. Скажем сколько картинок на этой странице? Логотив вверху, Goooooooooogle внизу (причём ведь может быть и Google и Gooooogle, так что её вроде как надо собирать из частей), ещё там могут быть плюсики/минусики. Но Tools->Page Info покажет вам, что используется тут на самом деле ровно одна картика. Вот такая:

Обычно это даёт большую экономию, чем data:URL ...

[lost55]

>> Лично мне вышеприведенный код кажется сомнительным: все браузеры, кроме IE, посчитают,
>> что CSS-файлы закомментированы и вообще к ним не обратятся. Поэтому я бы советовал оставить
>> комментарии только для первого файла и переместить его вызов в конец, чтобы он переопределял
>> общие стилевые правила.

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

[Rumato]

сомнительное удовольствие

[aleks_raiden]

а по моему, кешировать можно вполне, используя любую систему кеширования, которая работает со строками. и тогда можно кешировать в Flash Storages или любую другую систему (например, через Dojo Storages), а для обычных картинок этого не сделаешь.

[Stepanow]

Респект. Мысль стоит добавления в статью. Действительно полезная идея для веб-приложений.

[sunnybear]

мне схема кеширования пока не совсем ясна. Если аналогично любому другому куску HTML-кода — это одно, это можно даже не упоминать. Но у меня есть подозрение, что имеется в виду что-то другое.

[paladin]

Вот так вот IE тормозит прогресс. Давно бы использовал если-б не IE.

Часто надо чтобы часть маленьких картинок на странице загрузилась как можно быстрее, чем остальные большие. Это нужно например, чтобы не терялись "красивости" верстки во время загрузки, чтобы пользователь быстрее увидел все управляющие кнопочки и т.п.

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

[sunnybear]

мне кажется, что CSS sprites + предзагрузка картинок вполне решают проблему

[Stepanow]

При повторной загрузке - полностью согласен, но при первой-то первым тянется html...

[sunnybear]

for(var i=0;i<images.length;i++)(new Image(width,height)).src=images[i].src</pre>

[paladin]

Мне кажется, что это не решит проблемы первой загрузки страницы.

[paladin]

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

Способа организовать подобное без значительных трудозатрат по оптимизации загрузки страницы сейчас нет.

[diamant]

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

[khim]

Способа организовать подобное без значительных трудозатрат по оптимизации загрузки страницы сейчас нет.

Есть. Вся навигация складывается в один .png файл, ссылка на который стоит в самом начале страницы (там где лого или первый уголок или ещё что), все остальные картинки - идут потом. Всё. Вначале грузятся уголки, элементы дизайна и прочая, вся страница показывается уже с оформлением, а уж затем грузятся все остальные картинки. Какие-то ну совсем мелкие картинки из постов могут проскочить вперёд, но это - не очень большая проблема...

[tenshi]

не страдайте глупостями :)
один отдельный картинко со спрайтами - и кэшируется хорошо и запросы экономит.

[sunnybear]

лучше отдельной картинки со спрайтами может быть только встроенная картинка :) кешируется вместе со стилями, запросов на 1 меньше (для каждой картинки)

[tenshi]

так и представляю... десятка два селекторов, после которых десятки килобайт каши-малаши.
нормальная последовательность загрузки:
1. страница с собственно данными
2. стили, для задания раскладки и цветов
3. картинки - дополнительные украшательства
4. скрипты - дополнительная клиентская функциональность
если раздуть цсс до неимоверных размеров, то счастливые пользователи оперы при первой загрузке будут продолжительное время смотреть на страницу без стилей вообще.

целый запрос экономится... афигеть!

[sunnybear]

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

[tenshi]

^_^ я тоже тоже люблю сферических коней. они такие грациозные и быстрые...

[sunnybear]

если Вы с ними не имели дело, это не значит, что их не существует :)

[anshargal]

Из-за наличия IE6/7 для обычных веб-сайтов еще года 3-4 о data:URL можно не думать.
Зато в браузерах для iPhone/iPod Touch и Android все работает уже сейчас.

[alteist]

ИМХО как только IE такое внедрит, инет захлестнет волна новых эксплоитов и вирусов. Остальные браузеры этим уже переболели.

[diamant]

может, потому и не спешат?

[alteist]

может это и вовсе секретная стратегия MS?)) тогда остается только догадываться что бы было, если IE обзаводился всеми фичами в срок))

[diamant]

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

[mariner]

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

[bolk]

IE8b1 доступен для ознакомления и он поддерживает data url. Но только длиной 32Кб. Судя по всему, ограничение это убирать не собираются.

[Regis]

Имхо, самое подходящее применение для инлайн изображений - капча (не нужно кэшировать, привязано к странице, код на сервере немного упрощается). В остальных случаях обычно лучше от лишних запросов избавляться с помощью "CSS sprites".

[bolk]

Одно из приложений data URL, которые не было освещено — использование их в веб-приложениях, например, в Opera widgets. Там они более чем логичны.

[bolk]

http://habrahabr.ru/blog/webdev/39096.ht…

[sunnybear]

пара моментов спорные (например, не указано, что делать с CSS-картинками, деление по Gecko немного удивило), но подход очень понравился. Может быть, сделаю еще одну общую статью на эту тему, расширив несколько случаи применения (+ надо же осветить mhtml все-таки :).

[bolk]

С CSS-картинками — по аналогии. Для Gecko в OBJECT обязательно указание mime type.

[ATimofeev]

Ого, да это же хит!
Пара замечаний:
1. Раз уж автор предлагает использовать PHP в коде CSS, то почему бы уж не скупиться и не определять версию браузера на нем же.
2. Опять таки про использование PHP, но на этот раз недоумеваю – если использовать в CSS файле base64 через PHP разве картинка для получения хэша не будет дергаться? Ну хотя если CSS станет кэшироваться будет легче.

[sunnybear]

я бы предложил статически «собирать» CSS-файлы перед заливкой на боевой сайт

[bolk]

Я не понял — вы мне коммент написали или нет?

[ATimofeev]

Уже не помню, что Вы писали. Мой ответ, скорее, с одной стороны ответ Николаю, с другой – просто мысли всл