Нужно ли упаковывать мелкие картинки как data:image;base64 в css или как убедить оппонента?

Question

[Павел Тысляцкий]

Привет,

Недавно с товарищем возник горячий спор по поводу того, нужно ли упаковывать иконки и мелкие картинки в base64. Специфика такова, что мы пишем phonegap + sencha touch 2 приложение, но также есть и сайт.

Он приводил доводы против этой практики:

1) увеличение размера CSS файла
2) увеличение времени на загрузку картинки (base64 декодирование)
3) неудобство работы с CSS, содержащим бинарные данные, неудобство при замене картинки
4) одна картинка может использваться во многих местах — придется для одной картинки делать общий стиль и потом каскадировать для отдельных элементов
5) картинки хорошо кешатся
6) его знакомые верстальщики впервые слышат об этом

Я же в опровержение:

1) уменьшаем количество запросов
2) избавление от бага, когда загрузка/отрисовка нескольких картинок происходит не одновременно (хотя можно группировать картинки в спрайты)
3) при использовании sass/compas избавляемся от необходимости вручную кодировать и вставлять картинки в css
4) принятая практика (смотри page speed, как делают в sencha touch)
5) статья об этом на хабре

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

Comments

[demark]

Со сжатием проблем тоже нет: картинки в CSS-файле, сжатым через gzip (вы ещё не используете его?), будут даже занимать чуть меньше места, чем оригиналы.

1. В base64 размер увеличивается на ~1/3
2. Gzip уменьшает этот оверхед до 2-3%, но никак не меньше оригинала.

en.wikipedia.org/wiki/Data_URI_scheme#Disadvantages

[demark]

По ссылке странный источник 2003 года.

А вам надо какого года?=) Первый «прототип» алгоритма base64 начали юзать ещё в 1987 году.
RFC3548 (July, 2003): Base/16/32/64. Есть ещё RFC4648 (2006) — следующая версия RFC, но алгоритм тот же.

Оверхед на заголовок всего, как правило, 150-300 байт.

Выйгрыша по размеру, в целом, не будет. (почитайте мой коммент ниже). По кол-ву соединений — да.

В общем, надо реально отталикваться от конкретного случая и решать — стоит или нет.

[demark]

* если быть точным, то не по кол-ву соединений (keep-alive поддерживается большинством браузеров), а по кол-ву запросов.

Answer 1

[gro]

Про кэш: css закэшируется в браузере также, как и набор картинок.

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

Comments

[shagguboy]

если css меняется раз в месяц то почему бы и нет

Answer 2

[Анатолий]

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

Answer 3

[Виталий Желтяков]

Изначально, Вы думаете не в том направлении, как и многие на Хабре… Почитайте про Application Cache — это современное решение.

Comments

[Павел Тысляцкий]

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

[Виталий Желтяков]

Тогда определитесь, что Вам важнее — удобство разработки или производительность проекта.

[Павел Тысляцкий]

Хочется совмещать, разве data:image;base64 так отрицательно сказывается на производительности?

[Виталий Желтяков]

Зачем?
Данные в Application Cache загружаются фоново, не задерживая основную загрузку. После загрузки отображаются моментально, т.к. берутся из кэша. Никаких лишних телодвижений.
Application Cahe изначально задумывался для выполнения этих задач.

Answer 4

[bubuq]

Мой опыт использования этой техники крайне положителен. Мне, правда, нужно выдавать не иконы, а полноценные изображения, 10-20 штук на странице, и все они генерируются динамически, так что спрайты исключены. Время декодированя base64 смехотворно по сравнению со временем на дополнительный запрос.

В случае же с мелкими статическими картинками большой разницы по сравнению с одним спрайтом не будет.

Аргумент «верстальщики не слышали» можно отмести. Когда-то люди про веб не слышали.

Answer 5

[demark]

Вообще, если вы используете Application Cache, то юзать base64 действительно нет необходимости. Это как спорить добавить 1 или 2 л.с. в движок на 500 лошадей.

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

Когда используется Application Cache, браузер запрашивает сначала только манифест файл и, если он изменён, начинает отправлять запросы if-modified-since по каждому файлу.

Теперь посчитаем: допустим у вас картинки/иконки по 20КБ * 10 шт. = 200КБ
В base64 размер увеличится в 1.37 = 274КБ + вес остального CSS.
Т.е. при изменении 1 файла, придётся заново загружать 274КБ, минимум.

Теперь что будет, если просто кэшировать картинки, оверхед на HTTP-запрос (заголовки) — 0.15-0.3 КБ,
итого 10*0.3 = 3КБ + 20КБ новый файл = 23КБ. Но тут оверхед на сеть (keep-alive) 1*DNS Lookup + 1*Connect + 10*Send/Receive.

— Хотя мне, например, нравится этот финт с уменьшением кол-ва запросов — в общем, надо реально исходить из задач — где-то это уместо, а где-то сродне экономии на спичках.

en.wikipedia.org/wiki/Data_URI_scheme#Advantages

Comments

[Павел Тысляцкий]

Под мелкими картинками я подрозумевал иконки, фон, спрайты кнопок и тому подобное, средним размером 1-2 кб.

Answer 6

[fStrange]

Подобные холивары всегда навевают скуку.

Если у решения нет убойных плюсов или явных минусов, то выбирать следует ориентируясь на свое личное удобство.

Comments

[Павел Тысляцкий]

Отчего холивар, помоему вполне конкретный вопрос. Я, например, считаю, что встраивать мелкие каринки в css, это как признак хорошего тона, мой же товарищ наоборот, считает это злом. Поэтому я хочу получить объективную точку зрения.

[SpeCT]

Холивар, потому что вы не завершите спор неожиданным killer-плюсом одного из решений. В конечном итоге выбор будет сделан исходя совсем не из первичной стороны вопроса.

Это почти как про синглтоны спорить, только уровнем повыше :)

Я использовал оба метода. Скрипты писал картинки -> base64 -> sass. Сейчас как и все начал пользоваться Application Cache. Никто пока не жаловался.

В конечном счёте, экономически разницы как вы храните картинки нет. Вы в любом случае их будете хранить, читать и показывать. Так почему бы не сделать так, чтобы на всю проблему ушло как можно меньше времени – сделать так, чтобы вам было потом удобно работать.

Answer 7

[Wott]

Само по себе это ничего не дает ни во времени загрузки ( online event даже позже случается ) ни в скорости загрузки.
Но в комплексе это очень хороший метод оптимизации количества запросов и кеша.

wott.info/wordpress/optimization-in-numbers/

Answer 8

[superpuperlesha]

Предлагаю формулу по которой можно посчитать актуальность хранения картинки в css.
1) Все картинки которые пользователи и адмиы сайта не меняют (управления слайдерами, пагинация, логотип, фон...) хранить в css. Остальные картинки подключать.
2) Размер картинки менее x байт также хранить в css.

Answer 9

[pepsikat]

W3C ругается на base64.