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

Привет,

Недавно с товарищем возник горячий спор по поводу того, нужно ли упаковывать иконки и мелкие картинки в 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) статья об этом на хабре

Может кто-нибудь поделится своим опытом и приведет аргументы за или против либо оспорит представленные мной доводы?
  • Вопрос задан
  • 6203 просмотра
Пригласить эксперта
Ответы на вопрос 10
@gro
Про кэш: css закэшируется в браузере также, как и набор картинок.

Вот только потом добавили одну маленькую картинку (удалили, изменили) и браузер, вместо того, чтобы подсосать только её, тащит css со всем набором.
Ну и просто css немного подправить — опять всё выкачивать.
Ответ написан
taliban
@taliban
php программист
Такой подход очень актуален когда у Вас сервер очень сильно нагружен соединениями, в остальных случаях обычные картинки предпочтительней, всеравно кешируется все.
Ответ написан
Изначально, Вы думаете не в том направлении, как и многие на Хабре… Почитайте про Application Cache — это современное решение.
Ответ написан
Antelle
@Antelle
1) увеличение размера CSS файла
Картинки лучше бы положить в отдельную CSS-ку, тогда нестрашно
2) увеличение времени на загрузку картинки (base64 декодирование)
Время ничтожно мало, так можно дойти и до того, что bmp вместо jpeg отдавать
3) неудобство работы с CSS, содержащим бинарные данные, неудобство при замене картинки
CSS в отдельный файл, собирать скриптом из картинок, трудностей не будет. Спрайты, в конце концов, редактировать тоже не особо удобно.
4) одна картинка может использваться во многих местах — придется для одной картинки делать общий стиль и потом каскадировать для отдельных элементов
Это же хорошо, не будет дублирования кода.
5) картинки хорошо кешатся
CSS не хуже
6) его знакомые верстальщики впервые слышат об этом
Бывает. Но лучше бы промолчать об этом и загуглить.
Ответ написан
bubuq
@bubuq
Мой опыт использования этой техники крайне положителен. Мне, правда, нужно выдавать не иконы, а полноценные изображения, 10-20 штук на странице, и все они генерируются динамически, так что спрайты исключены. Время декодированя base64 смехотворно по сравнению со временем на дополнительный запрос.

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

Аргумент «верстальщики не слышали» можно отмести. Когда-то люди про веб не слышали.
Ответ написан
demark
@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
Ответ написан
fStrange
@fStrange
Подобные холивары всегда навевают скуку.

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

wott.info/wordpress/optimization-in-numbers/
Ответ написан
@superpuperlesha
Предлагаю формулу по которой можно посчитать актуальность хранения картинки в css.
1) Все картинки которые пользователи и адмиы сайта не меняют (управления слайдерами, пагинация, логотип, фон...) хранить в css. Остальные картинки подключать.
2) Размер картинки менее x байт также хранить в css.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы