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

Вообще, если вы используете 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

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

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

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

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

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

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