Пользователь
0,0
рейтинг
31 марта 2011 в 13:05

Разработка → Храните мелкие картинки в CSS

Храните мелкие картинки, которые нельзя засунуть в спрайты, в data:image base64 в CSS — это экономит кучу запросов к вебсерверу.

Кодируем изображение в base64 с помощью онлайн сервисов, вроде сервиса от DailyCoding (очень удобно, ничего лишнего).
Кладем получившуюся строку в CSS файл, заменяя «ТИП» на MIME-тип вашего изображения — jpeg/png/gif или (OMG!) bmp и «КОД» на нужную строку в base64:

.some_background {
	background-image: url("data:image/ТИП;base64,КОД");
}

Теперь можно смело подключать нужному элементу стиль some_background и наслаждаться двумя запросами к вебсерверу (html + css), вместо трех (html + css + изображение).

Пример реализации с изображениями:
images.html — 361 байт
images/images.css — 305 байт
images/test1.png — 1 600 байт
images/test2.png — 1 143 байт
Итого — 3 409 байт


Пример реализации с base64.
base64.html — 361 байт
images/base64.css — 3 991 байт
Итого — 4 352 байт


Пример работы готового инструмента Jammit:
(Google Chrome, ~60 Мбит/сек):

До (102 запроса, 73,23 КБ передано, 3.41 сек):
image

После (2 запроса, 153,88 КБ передано, 0,94 сек):
image

Плюсы:
  • уменьшение числа запросов к вебсерверу;
  • меньшее засорение кеша пользователя;
  • иногда уменьшение результативного объема изображения на больших файлах.

Минусы:
  • сложность обновления изображений;
  • иногда незначительное увеличение результативного объема изображения на мелких файлах.

Непонятности (непонятно, плюс это или минус):
  • Internet Explorer 5, 6 и 7 не добавляли в друзья base64, но в IE8 работает нормально. Ее можно включить, но не рекомендую это делать, лучше использовать mhtml (спасибо vitosik)

Мне кажется, что увеличение объема CSS файла лучше, чем лишний запрос к вебсерверу, поскольку по-умолчанию браузеры открывают в среднем 8 паралленьных соединений к вебсерверу, а 50—70 изображений это уже очередь, а кто любит очереди? :)

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

Для автоматического упаковывания изображений в base64 есть онлайн сервис duris.ru, но можно использовать и PHP скрипт с регуляркой: (спасибо Serator)
<?php
echo preg_replace('/images\/[-\w\/\.]*/ie','"data:image/".((substr("\\0",-4)==".png")?"png":"gif").";base64,".base64_encode(file_get_contents("\\0"))',file_get_contents('style.css'));
?>

Он делает из такого CSS файла:
* {
	padding:0;
	margin:0;
}
html {
	display:table;
	width:100%;
	height:100%;
}
body {
	margin:auto 0;
	overflow-y:scroll;
	background:hsl(0,0%,30%) url(images/background.svg) no-repeat;

}
.px_sort_0{background:url(images/px/arrow-090-small.png)}
.px_sort_1{background:url(images/px/arrow-270-small.png)}/* margin:0 5px; */
.px_status_0{background:url(images/px/minus-circle-frame.png);cursor:pointer}
.px_status_1{background:url(images/px/plus-circle-frame.png);cursor:pointer}
.px_delete{background:url(images/px/cross-circle-frame.png);cursor:pointer}
.px_help{background:url(images/px/question-frame.png);cursor:help}
.px_info{background:url(images/px/information-frame.png);cursor:help}
.px_return{background:url(images/px/arrow-skip-180.png);cursor:pointer}
.px_watch{background:url(images/px/eye.png);cursor:pointer}
.px_home{background:url(images/px/home.png)}
[data-beforeAddContent]:before {
	content:attr(data-beforeAddContent);
	display:block;
	color:red;
	width:100px;
	height:16px;
	border:10px solid black;
}

такой:
* {
	padding:0;
	margin:0;
}
html {
	display:table;
	width:100%;
	height:100%;
}
body {
	margin:auto 0;
	overflow-y:scroll;
	background:hsl(0,0%,30%) url(data:image/gif;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPg0KCTxkZWZzPg0KCQk8cmFkaWFsR3JhZGllbnQgaWQ9InN1biIgY3g9IjUwJSIgY3k9IjUwJSIgcj0iNDUlIj4NCgkJCTxzdG9wIG9mZnNldD0iMCIgc3R5bGU9InN0b3AtY29sb3I6aHNsKDIxMCwxMDAlLDUwJSk7Ii8+DQoJCQk8c3RvcCBvZmZzZXQ9IjEiIHN0eWxlPSJzdG9wLWNvbG9yOmhzbGEoMjEwLDEwMCUsNTAlLDApOyIvPg0KCQk8L3JhZGlhbEdyYWRpZW50Pg0KCTwvZGVmcz4NCgk8Y2lyY2xlIGN4PSI1MCUiIGN5PSIxNTBweCIgcj0iNzAwIiBzdHJva2UtZGFzaGFycmF5PSIxMDAiIHN0cm9rZT0idXJsKCNzdW4pIiBmaWxsPSJub25lIiBzdHJva2Utd2lkdGg9IjE0MDAiLz4NCjwvc3ZnPg==) no-repeat;
}
.px_sort_0{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAQ5JREFUeNpi/P//PwMlgImBQjDwBrCgCxj1XGfg4OZmYGNnj2FgZCxg+P9/wq+fP5f8+PqV4VyJJnEuAAZsDFBTQZS7mDGIBvGJ9gJI8c9v3wri/OWMX/xgYIj2kzMG8XEZgmHAz+/fbb9/+cIwcdbps4+/MzBMmX36LIgPEicqDP7/+5f+++dPht+/fp55+JWB4dvnTwysbOwmrOzsxAXi148fGUA2gsDrn0ADPn0GsoD4zjYgbYo1wFAw2FRxLQbuyCVndA7+/w+iQXxsakGYBZuz/ry8pvH/8YVbN/q+Mfx/e+vW35fXjIDC14D4B7paRvS8wMjICKJEgJgN2aEgHwHV/iFowNDLCwABBgC9qJ54WqC2JwAAAABJRU5ErkJggg==)}
.px_sort_1{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAP5JREFUeNpi/P//PwMlgImBQjDwBrCgC9jPfQGmGRkZZwIJY4b//88CwykdJHYwWYKwC37/+gXGv37+NI5yFzMG0TAxolzw4dUrBg5ubjD7DVDPj69fwWwILUfYgK+fPgJt/8HAysbOcB+o5/uXL0DbfzL8/vmTuED8/+//TKDiM98+f2J4CDQARIP4IHGiDPjx7dvhb58+M1jEOhs//MbAoBPpbAzig8SxOgGUEpExl1EEA6dzTQx35JIzOgf//wfRID5IHF0tOBVjCECAArNJagmL/6wzIBrI1wFiNmwGMKLnBWD8gygBIOZCEv4DxG+Bav+i+4Bx6GcmgAADAAiPsgkULyM8AAAAAElFTkSuQmCC)}/* margin:0 5px; */
.px_status_0{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAvNJREFUeNp8k11MUmEYx/9wQErIWaEoKjRtgqI1m9kszaGtqZu65SzXpJu2Ppbd1LzVzS7r0nnfRbKpiV554Y06q6m4RV8iRsgMooGBggJ6gJ73ZMtqdbYfh73n+f+fj/d9RW1tbRCJRBCLxcKbyCJKAKiIDPx4toivqVRqmfATSCaTYG8Jfj0yokqr1V7o6Oi4XlhYWM7zvPBBIpHA6XS+HRkZGXK73S9oaYGIs2+cXq9nWZn4cktLS5fJZHrI22wq3/AwvgwOIjA2hrDTCYVcrqq/dvUSVco5HA4mdhMJTqfTsVJqWltbu4xG4w1XXx+kc3PQUlZtbi7ylEootrawOTsLn3UJ5aau0xzH8WTiZybiRCKh0mg0tQ0N9SZnXy9yKDhHpcL29jYCgYDAzs4OVLSm3NjAWn8/6urqTHl5ebVMywwM7e1XOj9PTSHD44WIBuP1ehEMBn/D5/NBxAblWoN/ZhrNzU2dTCuhH3VBQYHB8WwIJxQKeDweYXB7u7tC5h2qZJf+/xyoOj8fWLQi985tA9Myg8xwOIKozQY+KwvVMzNCBaFQCNQr5HI5FGSclpYmGExXVCBFsdFoDEwrIWfWBnja1+jmJux2u5BNKpX+JRa2jaqJUaygIS0zCHOcBFJDGWLWRbiNRvzvSSczFguImUGYZfeurn60KyqrEIzFoJHJoGa9/oMotZV+5ixcrjU70zKDN2az2aKsqUO87BQ2KeAIHWsFBf9JmNpKUqKj1TWYmLBYmJbLzs6OBIPfpIDo8MV7D0o/vXsD/7obclauUCgJiVVi+9x5lDx6gvHx0efz8y8tdABfc/sXw7O8/F5MsxE39vTqcbIYbk6KJc86HBIp+PpGqG/eRfGt+zCbn46Pjg5ZotHoJJ0PXrSf5JBMJjtGEzfqdKVV3d09TZWV1UUHh2e1vnIODDyeXFn5sBCJRKbj8fgGLceYAUdkEsdZq7R9mXT7iujSZB28zlSln6bu3NvbC7FuiAAR+i7AAKjye47FnCxuAAAAAElFTkSuQmCC);cursor:pointer}
.px_status_1{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAw5JREFUeNpMk01ME1EUhU9npqC1MVWEKrUQMVqQIC6ABBVIRYwYgURCokhduiKaaIwLja5cuQTcaWJi6AK0EKJEF8QQ0IAoUQIF2vKjIjTlp1BoO+209d5BkJd8M3fezDn3vXfnampqaqDRaCAIgnonUokcAEZiLzbHGuFNJBJOwkcgHo+D7xL+j2SiKDMz80xdXV19VlZWnqIo6gtJkuDxeEba2tpaZ2dn+2lqkJD5nZidnc1ZWXyhqqqqwWaz3e2XvxjtCw40zb9Am68L42suSDrJaCu/dp5WKk5OTrJ4loiJFouFl3K2urq6wWq13rjlfoghcQSJNAEpxgMwHNiHtV0bGAgMo2ehDzfzb+SLoqiQiY9NhFgsZszIyCgpLz9nu+16gEiKAoPBgGAwiFeHm1RCodDmnEHGnanHKCsrs5lMphLWskFube2Vqx2/3sKvCyBBtktLS1hfX98+HI6Xl5fV2Je0gnfeD7h0qfIqayW6pJvN5tznE3bsPqRTxTwi0QgWFxfV7M5xJ5TY5oEeTDPiG22x9FBxLmvZwBAIrGMkPIa0eDp6T3fC6/WqWdlAq9Vi0PperQRT2FeBEc0YGYfBWolKxdtAjEq2Gl6D2+3erC99zOIt4RZRSUFMVlgM1rJBQBQl5IjH8T0ygZKx6u29Dxf1qKK8T6Xbc0k6LXKU4xQJbBDg7H9cLvf4qT35iPpDSDInAelQ2cq69cyIoQTydScxPT0zzlo2+GG32x2VxoswBQ9CXE1A0AuAfocBxYw2oEGWnImKlAp0djocrBVoGfNTU+7ejo43r1vynsH824j4aBDYiCHnazGODRSqMUbDODJnQlNuC7q6Ol9PT0/1slb81xhzTueoQP0hPLr8JDtV3g/MRPDTNQksyDgrF6M+9Tru5z2E3f6yo7291UHl7V5ZWVE06mkAu5KTk/fr9XqrxXKiqLHxXmVBQfHRHY2GoaHPnubmp90TE2ODVOKPsizzDxNmA5EwECm8UyqdgfZ9lJomdWc70yp9tGRPNBr10/MGsUj4/wowAGfaiP6JIq6oAAAAAElFTkSuQmCC);cursor:pointer}
.px_delete{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAxhJREFUeNpUU11IU2EYfrazOdGjqSm2hq6mbUszK+ZC0kT7IQUVCivCdRVdRF2Ft0p2l7ciCN1E4CjnzzCw6MaGEdkK1t907sdRWuLEn6nb3FF735OQffCc853zfs/z/n6K5uZmKBQKKJVK+U3IIxwFkE/IxN+1Spjf2dnxEhYI2N7eBr9V+Lc0BKterz/T0tJyw2AwlEmSJBtUKhUCgcCX/v7+vnA4/JZ+TRASbBPMZjN7ZfLFxsbGVpvNdl/yePJ/P3+OXz09iAwOIhoIQExPz6+7dvU8RSr4fD4mhwlbgslk4lCqmpqaWmtra2+GOjqgHh+HnrzqtVrocnMhrq5ixeXCb/dHlNlaywVBkEhkgUWUW1tb+YWFhdXnztXZAh3tOECHT4yOYn19HZFIRMbGxgZOvnqF3MVFzHR2oqamxqbT6aqZywKlV65cvv7z9Wtkzs7B6HDIeR9+9gxLS0syeM+rxOmEJjSDhTdjaGiov85cFjhYUFBQuvp+AqIowlFcLB+Ox+PQPX2K7N5e+P1+BINBPM7JQXRlBdEPbmi12lLmskBWNLqGmMcDKZlERno6nlDeXq8X8/PzshC312WxyG2KkwCfjcXiYK6KWsUikKivMTJuzM1BpD0VCmq1GikpKTIydnstbG4iTnaZQ1wlPaKCoIK69BjilG8aGY6Mjf1H5jk4OzUFkQWIzGcBJQtE2fvc9LR/UrRYsUThaveQv1ZU4FN5uSzAsNI8xCiytFMVCIVmJpnLAp/tdvtQblUNEseOw3Phgkz2EfkQ+WG4aVZ4vTAasU2Osiur4HQODTGXU/gVDPpdw8ODA+aHXVBYTuMlFWwfj/AueN9nMEBhrYTxwSOMjDgHQqGgi7nC7sWY9Xq/KSk95aW2dnNqsRFhQY2Psz/gU6kh1V2C4dYdGG/fg93+ZNjh6BuKxWKjNCOSQq4GkKrRaHJoDmpNphLr3btt9RZLZdGeiwa3+12gu7trdGrq+8Ta2tpYIpFY5K6ygEDIIuwniFTALCpYEV2avL3XmaJcoJADyWRymb7XCRHC8h8BBgBnQIpwMqgwawAAAABJRU5ErkJggg==);cursor:pointer}
.px_help{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAA0pJREFUeNpMk11ME1kUx/+dj07ZDhVYbKGGJdDE8rHKC6trXMXqrsYHPkzkhVg1QeKLMSZ+PBhj4sM+7cPug8bsgyb6QJMFLcZE44NRY8RQIVYb7JcNFi22QD+YTillpoP3jq46yW/uvXPv/5wz95xj6O3thcFgAMMw+khYT2gFYCNY8PmRCKm1tbUgYYEATdNARw7fHoGwpbGxcXt/f/9Ac3PzJlVV9Q2O4xCLxQIjIyPD8Xj8GfnkI5ToHtvS0kK9UvHe7u7uQ263+/RkGDbvoxyu35Vw96mMaLwAzmi2DRzs+p1EykYiESqOE8qs0+mkofzW09NzyOVyHb5wNYXQ3A8wVdajrs6G2tparGhmvCSaJy/SOHLA2cGyrEqMLFAjXLlctjU1Ne3Ys2e3+/yVFASLHVVCBXZ1cDiwy/zl78z45z8OU9M8Lv6bwsXBLrff74/Mzs6GWIfDsXVo6NjZ8YBijaYqYTQKSKclSJKEQDiFVFpBa7MF8YSMUHwV0rIGRsvjl81228SEb4pGYG9oaGgffpiAKFqRTKZ1n68iCsYLy9jZkcFP1Un4/Uvw+XKw2614FS3j1776dqplyKsqn5fxZkZFuayhVFrF/GIWc8lFODZoGNi3DuFZBbefLIPlTSgUFf1ssbgCquVIqqgRqGoZcmEVmbxCcsyDE3hcOl6nR/PnzTSMFVX6fM3AkrN5fNaoDDWQZ1kOGxuAhKwSYeXXwug790EfTeKP36pFW8VGO50w1ECeep+LRt+GfnYIkHJZmCurYTSt03l6rUPn/zVFKclobzJiZuZdiGqpgdcej8f7x9Zakr4lrMhpCGYL+ArLV6d0TiktZ2ATZbg6q3HnjtdLtazVapWz2QwPGCpODbraHjwO4mMyA8FkwfWxBG7cy5FK5TH/PoAaPom/z7RjbGz01sTEuJcUoJ/90hiJYHCaIf3BXDjZ0yIai8h8DCMwHcRS+gPa6iX0ddXgzNE2eDw3xkZHh73FYvF+NptVDfptkHsSBKFGFEWX09m25cSJs/s7O7c5vms0TE4+j12+/Nf9cPiNT5blx6VSiRbMCjXAEmiO6FWLPM9Xke5zkKZZ/307kygXyK3HFEXJkXWBsEjIfRJgAII6jzFPmgnBAAAAAElFTkSuQmCC);cursor:help}
.px_info{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAx5JREFUeNpMU1tIU2Ec/23nnB1PZ9q0taUyLQVnruhFulAy1g0MvHQRQlwFPRUSQfaU9NRbQS9R9BL04h40pkhFUHSjwhK6iM5Lw0apU9vF7eh23NnW/zuG9cHvfN/5/t/v933/m6GlpQUGgwFGo1GfCZsJ2wHYCUVYGwnCfD6fDxAWCcjlcmAzj39DJOyurKzc39bW1l5VVbVT0zTdwPM8gsHgSG9vb08oFHpHWx8JKrNxtbW17FZGPtrU1NTh9XqvDE/A7n8Zx4PBBAbfKpgKLYM3yfb2U+7D9FJucnKSkUOELOd0OtlTDjQ3N3d4PJ4z3ffmMT67AQWFpdiyxQ6r1Yp0TsZn4rz+FMHZ485dHMdpJLLIRIzZbNZeUVHRcOjQQe+1u/PgNthhsVgQja7g5gUZty7KiMdT+l5OsOL6/Qjcbre3vLy8gXGZgOvkyROnH79ZQDpfSMEBwuEIFEVZDw5bLyxEdVtClfB8KIZjxxpPMy5PnzKHw+HqeTEDs9mmk9nIZDJwNvaD7OAFAdm/AS0rs+HrVBZ7W0tdjMsELMmkgrFpDVurclDVVSwll5FKpdFzw6Gntv16GJywlrDlVIbO5nQ74/KUKuYGNC0LZXkV0WSGniqAFwWdLEkShIKidXfyBo7OJrHG0YxMIMlxPGocwIyiEbFw/bAkCeSWGSYp869acquoKWMLIxNIsttnp6a+j++oFpGIxyAXFsNUsFEHI8uyvP7PkFEVuLaZMD39Y5xxmcA3n8/nP7LHCou4hLQSgSgXQZCKdDJzg60Z1JUo7GYFnvpiDAz4/YzL2Ww2JRaLCoBBunzeU/fsVQBz4ShE8vvBwCwePomTiICFnyMoEcK43eVCf3/fo6Gh934qwC/c38aYCQRGjZRnY/el5lqzKYXo3ARGRgNYivxCXWkCre4SdJ2rg8/3sL+vr8efSqWexmIxzaBHAygQRbGEfPY4nXW7OzuvNtbX76v+r9EwPPwheOfOzacTE2MfqbBeqarKCibNBDiChbCJYBYEwULdV01Ns/n/dqZXLlLUg1RgcVYOhN+E+B8BBgDs34KhINyuSwAAAABJRU5ErkJggg==);cursor:help}
.px_return{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAgtJREFUeNqkU71rFEEUfzs3u5cLnsGcUS5oFb+Cic1cJdhYKSIWKhauhYWugoT9E+y1kFSmsjlIo4UJIimsxEqvMQmoEI1I0HCKya2X/Zqb8b3J3uUiXpoM/PbNm3nf81tLaw27WXz0/ltw+vrAzucNuG0D59zFuzMY3GsbrtXrQMmUUsAYA8uyjM7/E9SVUvrdB2EQ9KyAbdO0dmWa+jcuDAuUQNhoNIzs2UK3c5ok/u1rx0QQKEjjGJSUpuQdZ7Dpu+l81x0XS0shDAxwEwDXu+0F6hoKD+UUSkE6N85x7N+7WRGLi43MUMGls0dE+4FIOg6D6Zn37Vjiyvkx8fTlAnBynrh1WszPr3UypWkL6r8k/AlD2EAkSQqlwQIkUdSxWVldNzpLo+jRw8lXtZGRPSZTs6VhBXtfZQrWCw7E+/ZCa6gEjf4iJBQsw+dEG2kdmpijfl1sxb/unRPVLxLKxRz8eDZX+3dg+PY1/HiYaQrtBentIVZxiPBk8rl/0rsqlpsACQ4xx3mFCNN58y0CeR1C0YVdHoP8qcsAg0dNJYfvuOLb4ypVUNGfXmzN5vuCAdkTKJjVXWLuwCiwExdda/9xw0T5+kFF1T/syINcxsZ+REk3f5bV1ze/dWEoVFHgqI+zy3g+3IWDiCLCoc4RLaqAYGeH+WzPeiQkWhKviWUJ7a3d/s5/BRgACwsSLXcLHWcAAAAASUVORK5CYII=);cursor:pointer}
.px_watch{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAdhJREFUeNrUk01LAlEUhu845QdRUxZBhIIWtFBso2AwRAVNLqKltHCb63b9A/9AixZCELhyYdAmEyYCBcOlNa1CSQoxog/DMY3x9p5B27Zw1YGH8XrO+55759wROOdsmLCwIWNoAwFh/ugfZQKsAQV4gbNf9woqIAeuQHOgGxgIMNix2Wx7iqIsxmKxWU3TxgqFgpWSsix3fT5fK5VKPedyuftOp5OE7oz60hHsYD8UCh3k83k5k8ksGYYx5XK5rK2WzgiIrPQf5aiGakljakVRjKDrZaPR6Oi6zglVVTlFMnnMZXmdK8o2x674IE+1pCHtCFx2w+GwE9u3drtd81yJRAKdDXZ4eGSuFxb87PHxjg3yVEsaNNolg5NSqTTVbDaX7Agq8Hg8TFWLbGVl0xTY7TY2Our5NfhCQPNAWtFisdSr1WqvWCwawWBwRpKkcZyXadoN83qXmSQ50V1jGxurpnGlUqnH4/FzvItTmoo5ApjQNMIOh2MrEon4o9Gov1arzZXL5XHKBwKBT7fbXU+n07fZbPa23W5f4BVd93o9TgYimATTMHHCbB5PN9ZSf0LmrsEHRDWInvB8w/oFvAv920iFDkBzF/64fHTjvoFOxsL//5h+BBgAwjbgRLl5ImwAAAAASUVORK5CYII=);cursor:pointer}
.px_home{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAhJJREFUOMuNUktrE2EUPTPzfdP5Mkk25uFIoNHUCNUSm4hUKFpSX1AQ3KhY7aqLLgRBEEHduHPhwp8hoi1F1JWIivGFNhstbS1NbdpGM3lNZjpjM8m4cSFpk3i2597DOfceoAUGjyWHzl8cu4QOIK2I5cwSkSSmAOAAOK3m+FaExFyS2+OWeV5o62ALSyjlkidOj4xPXLmXOHxkOBDwdy3Mz72zLLOO/0FQCfV/Sn/bVItlp1CqOLMLGWfk7Lnbf6N0jtAdiQ6XqwbVDRO6YWI1l0c4Ej3Z6l7NApxlmfVcvgDDNLFhWsipRRjmprxd3C0CvCCIQ8njo15JgK5VYOgaZJHH3ki4L7Jv/6mOAkqo++iTxw8SXkYxOTWF69euIrjDi+fTj6hA6B2AE9sK6FpF8wcVk1IKxlxgjIEIAhhzgeP5CuAIbd/42zILhNCsEo6e2RX0I9YfR/rrPHjRnX3xdHK00WisN5eq+bKWqv56H+vrRTikoEukqNVqeDj9rGrbtUUAjbYRJObi4vFDB4vlKmy7Dp7nUKpUwRHJv7sneqBtEwVC+Atj4/dv3Lx1d2fAx8myjLrDYV0twe/zuRIDg5fXcj9X134spbd1ULdt8iH1+vvLV28yVX0DgAOREjBJQlnTnFTq7ezy4ly52XVzPSUAoT2RnoF4PBHzeD3ulZVsYebL548FNT8DIAeg9u/CHw3cvN/OkfEDAAAAAElFTkSuQmCC)}
[data-beforeAddContent]:before{
	content:attr(data-beforeAddContent);
	display:block;
	color:red;
	width:100px;
	height:16px;
	border:10px solid black;
}


Для Ruby on Rails есть примочка Jammit, которая упаковывает изображения в CSS, а так же делает кучу других плюшек (спасибо vitosik).
Алексей Хорев @coon88
карма
70,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (129)

  • +15
    Насколько я знаю, чужие посты публиковать нельзя.
  • +1
    Было бы хорошо, если бы вы написали точно, работает ли это в IE6/7; в противном случае использование этого приема сильно ограничено.

    Еще интересно, не падает ли скорость загрузки страницы при повсеместном использовании этого приема. Ведь обычные картинки браузер кеширует, а сохраненные в css — вряд ли.
    • +12
      Так весь CSS кешируется.
  • +2
    К сожалению, в IE6-7 работать не будет, понадобится бубен.
    • 0
      или так duris.ru
    • +1
      Проверил — в 5, 6 и 7 действительно не работает, добавил костыль в топик. Спасибо.
      • +6
        Зачем пятый то? :)
        • +4
          Что бы список больше был :)
          • +6
            Но если это и в пятом заработало после костыля — вы «злобный гений» верстки :)
        • +4
          Всмысле скорее «зачем шестой» :) Да и седьмой уже с приятной периодичностью сдает позиции.
          • +3
            С шестеркой столько воспоминаний *умиленно*
    • 0
      Я правда написал инже в каментах, но еще и здесь продублирую, для ie7 можно использовать mhtml — у него с ним проблем не будет.
  • 0
    Универсальнее хранить одной картинкой и смещать бэкграунд, как в JQueryUI.
    • 0
      К сожалению, не всегда такое возможно :(
      • 0
        Можно пример картинки, который нельзя засунуть в спрайт?
        • +4
          тянущиеся бекграунды?
          • 0
            А какие с ними проблемы? Я засовывал тянущиеся в спрайты.
            • 0
              Про Clip написали ниже — не везде работает, что плохо.
              • 0
                Я не про clip. Просто частенько элементы для которых используется бэкграунд с repeat-x, ограничены по высоте. В таком случае можно сложить в пачку несколько таких бэкграундов, в один спрайт, в который к тому же можно вставить и другие изображения.
            • 0
              Это вам не border-radius, которым как правило можно принебречь в IE.
              • 0
                А какие проблемы со спрайтами в IE?
              • +1
                PIE легко обеспечит border-radius в IE.
        • +1
          Бекграунд 20х20 пикселей, repeat-x bottom для контейнера 100x100 пикселей. И таких несколько разных. Можно конечно использовать CSS свойство clip, но Internet Explorer такой Internet Explorer…
          • +1
            Согласен с Вами и Psih'ом. Действительно не случай для спрайтов
          • 0
            Какая проблема? Ставим бэкграунд в самый верх спрайта, задаём положение отступом.

            Не, я не спорю, что такие варианты бывают, но они очень редки.
            • 0
              У меня 5 разных бэкграундов (3 тени и 2 bottom фона, все repeat-x). Что делать?
              • +1
                Панацея со вкусом Firefox'а :)
              • 0
                Самый главный вопрос в максимальной высоте элементов, к которым применяются эти фоны. Если это нечто невысокое (типа заголовков и других элементов), то вполне можно упаковать в спрайт.
          • 0
            И какие проблемы c clip? в IE он прекрасно работает, просто с маленькой особеностью. Для пнг (с фильтрами) часто использую. А проблема в запятых — уберите запятые, во всех браузерах не сломается а в IE заработает
    • 0
      Это назвается спрайты и это действительно на данный момент очень Хороший способ!
    • 0
      Не подходит для анимированных гифов.
  • 0
    так вроде же говорится о
    мелких картинках, которые нельзя засунуть в спрайты
    • –1
      На сколько мелких? В спрайтах позиционирование с точностью в 1px.
      • 0
        Дело не в позиционировании. Я выше уже ответил.
        • 0
          Выше Вы все правильно написали.
  • 0
    Хз, насколько это целесообразно. Время на разработку увеличивается (время = деньги), а эффекта почти нет. Но прикольно:)
    • +1
      Вам явно слово «оптимизация» не знакомо. Экономия запросов к серверу это святое. Мы например в продакшен версиях всегда спецальными самописными скриптами собираем минимизированную версию из девелоперской. В итоге если открыть исходный код, то там в секции голова будут все стили в разделе, все скрипты в разделе и дальше тело с ногами, всё без переносов строк, выглядит стрёмно, но работает быстро. Запросы делаются только на необходимые картинки непосредственно в теле, которые нет смысла кодировать в base64, хотя будь моя воля я бы к одному запросу на сервер всё сводил.
    • 0
      Грандиозность положительного эффекта растет пропорционально количеству мелких изображений.
      • +1
        Очень зря, что автор не привел реальный пример, чтобы все увидели, что пользоваться таким способом нужно очень осторожно.

        Даже на маленькую картинку вы полчите кода в несколько метров, сильно сомневаюьс, что это украсит Ваш css файл.
        • +12
          • –2
            Я про код писал! А не про конечный результат.
            • +1
              Насчет «нескольких метров» для маленькой картинки вы сильно преувеличиваете, посмотрите в примерах, что я скинул, а скорость загрузки сильно выше + gzip в помощь
              • –1
                > Насчет «нескольких метров» для маленькой картинки вы сильно преувеличиваете

                Специально замерил, для картинки телефончика, что ниже при размере шрифта 11 pt нужно: почти 6 метром кода

                Преувеличил?
                • 0
                  Ок, согласен насчет осторожности при использовании такого метода, но в приведенных мною примеров гигантского размера я не увидел.
                  • –1
                    А Вы код смотрели? Первая же галочка тянет на:
                    2,5 метра кода
                    При тех же 11pt.

                    Остальные примерно также или больше.
                  • 0
                    А теперь представьте у нас 10 картинок и в итоге это выльется в 30 метров кода и что это хранить вместе с нашим основным CSS кодом? Но, постойте CSS отвечает за стили и хранить в нем 30 метров абракадабр как то не правильно.

                    Конечно, можно выделить отдельный файл images.css, чтобы убрать всю эту «красоту» в отдельный файл, но тогда на чем мы выигрываем?
                    2 CSS файла VS 1 CSS и 1 спрайт.
                    • 0
                      Специально для этого есть решения, позволяющие упаковывать ваши картинки в цсс при деплое на прод. Не вижу в этом проблем.
                      • –2
                        В том то и проблема, что Вы не видите.

                        Сервисы по упаковке, хорошо, а если он недоступен?

                        PHP скрипт с регуляркой, а Вы учитвали, что при этом возрастет нагрузка на web-сервер?

                        Вы не провели достаточное исследование.
                        • +2
                          Я не использую сервисы, в моем случае (это рельсы), есть такой инструмент ка jammit github.com/documentcloud/jammit, который как раз пакует картинки в цсс, помимо множества других плюшек.

                          Возможно для php есть что-то подобное, не берусь утверждать…

                          • +2
                            И пакует он это все перед деплоем на прод.
                        • 0
                          Вы предлагаете упаковывать при каждом клиентсокм запросе?
                          • 0
                            Нет, я предлагаю сделать настаящие исследование, чтобы действительно убедить людей использовать именно такой способ.
                          • 0
                            Какой же вы тупой.
                • 0
                  Извините, я что-то не понял. Можете пояснить, где там 6 метров?
                  • –1
                    Перейдите по ссылке ниже!
                    • 0
                      Там одна страница текста. Где 6 метров?
                      • +1
                        Ответ: 32 строки * 18 см = 576 см, что примерно 6 метров.
                        • +1
                          Очень неожиданно, если честно )

                          Я просто не мог проверить до сего момента, то, что вы указывали в примерах и был крайне удивлен, результирующим кодом в 6 kb, а вы оказывается про длину говорили…
                          • +1
                            не kb, а mb — метрах, очепятка
                        • +1
                          Строчка в 18 см?!

                          Надо было хотя бы раз вставить тег irony…
                          • 0
                            Неужели только мне нравится, когда код красивый (это ведь все таки стили)? И в нем нету сотен строк абракадабр?
                            • +1
                              Если оно делается в автомате при deploy, то кому какая разница?
                        • 0
                          А у нас тут ещё 31 марта…
                          Спасибо, за поднятое настроение :)))
          • 0
            Вот посмотрите как будет выглядить код, для маленькой картинки:Посмотреть
          • 0
            А вот сама картинка:
            image
            • 0
              Для цссок скорее подойдет большое количество маленьких изображений <= 1 kb, ну а потолок 32kb, поскольку восьмой ie их не переваривает.
      • 0
        в использовании dataURL есть минусы, один из них показан на этом видео video.yandex.ua/users/banzalik/view/5/#hq
    • 0
      Эффект как раз есть. И вполне материальный:
      — увеличивается время загрузки страницы
      — поступает команда: «Сделать быстрее, чтоб всё было ОК»
      — картинки прячутся в CSS, а его, в свою очередь, забирает к себе CDN и отдаёт быстро-быстро много-много

      Имеем — довольных посетителей, довольных заказчиков, премии и т.п. за один день работы
      • +1
        Если какой-нибудь портал при этом станет грузиться на 5-10 секунд быстрее, то это, конечно, круто, полезно и нужно:) А если речь идет о миллисекундах, то ситуация совсем уже другая.
        • 0
          У некоторых пользователей одно HTTP-соединение может открываться порядка секунды. При плохих пингах до пользователя, но вменяемых скоростях соединения профит от вписанных картинок очевиден.
    • 0
      Очень сложный вопрос. Дело в том, что Base64 код вполне может весить больше, чем картинка в web-форматах.
      • +1
        gzip нивелирует эту разницу
      • –1
        Как показывает практика, PNG8 больше 30х30 чаще всего даже уменьшается в base64.
        • 0
          Это зависит от конкретной картинки!
  • +1
    Храните картинки на разных доменах и разных железках, это полезнее будет.
    • 0
      Уменьшение http запросов это не только серверная оптимизация, это еще и клиентская. Даже, пожалуй, больше клиентская. Больше элементов на странице, больше запросов, больше памяти, больше файлов в кеше.
      А грамотно собранную статику можно держать на той же железке, что и фронтэнд.
  • +2
    Не знаю в который раз уже пишут о Data Uri (очень много...), но можно же было хоть в ~ 100500-ый раз написать, что собирать изображение в строку нужно автоматически, а не руками. Следовательно проблем со сложностью обновления изображений быть не должно. Да и sprit'ы можно тоже в Data Uri засовывать…
  • 0
    Для ie7 можно использовать mhtml en.wikipedia.org/wiki/MHTML
  • 0
    Я правильно понимаю, что для 5-7 IE мы добавляем костыль в виде скрипта, и количество запросов становится тем же?)
    • –1
      Доля IE 5..7 стремительно падает, а восьмая версия уже поддерживает алгоритм base64. Для небольшого процента клиентов можно отдавать и другой CSS, где эти изображения отдаются статикой, что бы не пулять лишний раз запросы.
    • 0
      Для ie7 есть вполне «нормально» решение.
  • +1
    иногда уменьшение результативного объема изображения на больших файлах.

    Интересно как, если мне не изменяет память base64 увеличивает объем процентов на 30
    • +1
      Ага. Из каждых 3х байтов получаются 4.
    • 0
      В сыром http-запросе помимо всего прочего идет куча всякой фигни. За счет этого и получается экономия, но только для небольших файлов (навскидку, < 1 KiB).
  • +5
    Это обсуждалось столько раз и base64 и спрайты — и то и другое давно успешно применяется.
    Что нового Вы открыли миру хабру?
    • 0
      Автор ничего не открыл. И более того, не достаточно хорошо изучил вопрос. Изначально не привел никаких сведений о реальном изменении размера изображений до кодирования и после него, о замере времени реальной загрузки и т.д.
      • –1
        Топик постоянно обновляется, добавляется новый материал по теме из запросов читателей.
        • +1
          Тогда удовлетворите наше любопытство и сделайте настоящее исследование расставив хоть какие-то точки над и. Например, вот так:
          • Необходимо будет решить вопрос с размером картинок. Во первых изучить алгоритм Base64. Пережать, скажем сотню картинок. Выявить закономерности (Например, если в картинке есть градиент, то она скорее всего увеличится). Оформить графики. Сделать Выводы.
          • Отобрать набор тестовых картинок (желательно разнотипных, типы должны появится из первого эксперемента). Загружать сайты с картинками с различных Web-серверов, машин, браузеров, в разное время суток в виде отдельных картинок, спрайтов, css. Оформить графики. Сделать Выводы.
          • Изучить нагрузку на Web-сервер без перекодирования и с кодирование картинок в Base64. Сделать Выводы.
          • Подвести общие итоги. Выписать плюсы и минусы. Дать конкретные рекомендации к каким картинкам и в каких случаях лучше применять этот метод, а в каких не стоит

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

          Вот это было бы интересно.
          • 0
            Спасибо за ответ, внес в планы.
          • 0
            Base64 не занимается сжатием. Он просто перегруппировывает набор битов из групп по 8 в группы по 7 битов (очень упрощенно выражаясь), которые потом представляются в виде букв, цифр и пары спецсимволов. Таким образом, размера полученной последовательности можно прбилизительно оценить как originalSize*8/7.

            Так что первые 2 пункта вроде как не нужны. Нагрузка на веб-сервер — это уже интереснее, хотя тут все-таки слишком много вариантов, но опять-таки все уже давно обсудили и даже тут на хабре =)
      • +1
        Реальная загрузка хороша видна невооруженным глазом на примере из комментов.

        До оптимизации ~ 5 сек.
        После оптимизации ~ 0.5 сек.
        • +1
          Вот реальные графики (Google Chrome, ~60 Мбит/сек):
          До (102 запроса, 73,23 КБ передано, 3.41 сек):
          image

          После (2 запроса, 153,88 КБ передано, 0,94 сек):
          image

          Повторюсь: в современном интернете проще передать 1 файл в 1 МБ, чем 10 файлов по 100 КБ.

          Так метровый файл начнет качаться, разгонится до предела и пойдет жара, а десятикилобайтные и разогнаться не успеют, да и времени на открытие соединения (пусть условно будет 1 секунда) будет тратится 1 секунда, против 10.

          Ну и запросов к вебсерверву в 10 раз меньше, а это в 10 раз меньше строчек в лог файле.
          • 0
            Хорошо начало положено, только вот а где спрайты?
          • 0
            Все это должно быть в топике, а не в комментах. И блог выбрали правильно, так предшественников почитайте. И основоположника клиентской оптимизации на хабре sunnybear к примеру — его сайт www.webo.in
            • 0
              Да, только не в таком виде. На webo.in и небольшой видеокурс есть по клиентской оптимизации. Автору можно и его рекомендовать.
  • 0
    Для мобильных браузеров с отключенными картинками этот вариант плох: придется качать весь css файл
    • –1
      Для мобильных браузеров принято делать отдельный стиль или даже сайт.
      • 0
        Поговорим по этому поводу через пять лет, ок? Занесите в календарь напоминалку.
        • 0
          Еще год остался.
          • 0
            Полагаю, вопрос уже исчерпан. Даю новый прогноз. Еще пять лет и десктопы останутся только в памяти большой цивилизации. Интернет есть всё и интернет есть везде.
            • 0
              И на чём Вы будете кодить?
    • 0
      а так не приходится качать?
  • 0
    Сравниваю 2 диаграмы загрузки ресурсов и не могу понять, как на второй base64 изображения начали грузиться одновременно со страницей. И как вообще в таком случае определено понятие «загрузки» изображений, если они — часть css?
    • –1
      Это Chrome Developer Tools так отрисовывает графики, для движка HTML картинки как бы скачиваются, на самом деле они просто распаковываются, причем очень быстро. а главное — экономия http запросов.
  • +1
    Я вижу еще значительные недостатки, которые не указаны в статье:
    1. Чтобы не потерять в удобстве расширения и изменения макета/стилей нужно писать некий скрипт, который бы парсил CSS-ы и подменял URI фоновых картинок на их base64 эквиваленты, а потом заменял подключение developer-friendly CSS-ов на сгенерированные.
    2. Если одно изображение используется несколько раз возникает значительная избыточность.
    3. Если рассматривать подход без использования base64, то сначала загружается HTML — рендерится разметка, следом CSS — применяются стили разметки (размеры, колонки, шрифты, бла-бла), а потом уже загружаются фоновые изображения, дополняя страницу деталями. В данном случае зачастую первых двух действий относительно достаточно для взаимодействия пользователя со страницей.
    В случае с base64 значительно увеличивается размер CSS файла, замедляя загрузку стилей разметки, замедляя тем самым рендеринг макета и изменяя логичный (по моему мнению) ход вещей.
    • –1
      На современных скоростях интернет соединений гораздо быстрее скачать 1 файл в 1 024 байта, чем 10 файлов по 100 байт. Посмотрите в Developer Tools, сколько времени тратится на установку соединения с сервером.
      • 0
        Гораздо, это во сколько?
        Вам же написали, логика немного страдает. Сначала разметка, затем стили. Все правильно и логично, достаточно для того, чтобы клацнуть по рубрикатору или «на главную». Затем картинки.
        В случае картинок в css, стройная система слегка смещается.
        Да и почему Вы почему так напуганы соединениями?
        • 0
          > Да и почему Вы почему так напуганы соединениями?

          Соединение с сервером одна из самых затратных операций. Чем меньше соединений, тем быстрее грузится сайт. Да и на сервер нагрузка меньше.
    • –1
      А избыточность исправляется созданием отдельного стиля с изображением и подключением его к нескольким элементам.
  • +1
    А как отключить картинки? В смысле теперь при отключении картинок трафик не экономится.
    • +2
      Кстати, да, любопытный вопрос. Имею большой опыт сидения на дорогом жпрс-е.

      Поразмышлял — выходит даже плюс. Ясно же, что в CSS имеет смысл засовывать мелкие картинки: значки, кнопки, пиктограммки, скругленные уголки и т.п. Они много не весят и вполне посильны даже для мобильной связи. И самое главное, зачастую без них макет выглядит неполноценно — непонятно куда можно кликать, теряются иконки статусов и т.д. (хотя отчасти это вопрос аккуратности разработчика). Зачастую хочется как раз эту копеечную мелочь врубить, оставив отключенными большие картинки основного контента.

      Но дело в том, что если обычную картинку (тег IMG) можно легко посмотреть через команду контекстного меню, то изображение, подстеленное через css::background, отдельно просмотреть невозможно! Только включив вообще все картинки. Ну если не рассматривать варианты с файрбагом и копание в исходниках.
  • +1
    Давно пользуюсь data:url и могу сказать что все описанные недостатки нивелируются достоинствами этого метода оптимизации при его правильном использовании. Я имею в виду использование «быстрых» css селекторов, группировку селекторов при подключении одного изображения в разных местах, gzip сжатие. Время до показа страницы может немного и увеличивается, но незначительно и в большинстве случаев после этого человек получает уже практически полностью загруженную страницу и общее впечатление остается лучше чем когда страница грузится постепенно.

    А на счет большого времени при изменении дизайна я категорически не соглашусь. Если сравнить время на изменения в дизайне при использовании data:url и его аналога css-спрайтов. То тут и обсуждать нечего data:url быстрее и удобнее. И это если еще не брать во внимание ограничения которые накладывает использование css-спрайтов. Я до сих пор с ужасом вспоминаю случаи когда заказчик просил внести большие изменения в спрайт из 40+ изображений.
  • 0
    А как в случае с IE < 8 происходит работа? Там же ведь по сути не css, а значит надо будет писать еще один css, в котором картинки подключаются обычным образом. И кстати картинки, то в таком случае не станут дергаться с сервера?
    • 0
      В таком случае можно юзать MHTML.
  • 0
    иногда уменьшение результативного объема изображения на больших файлах.
    это если изначально файл плохо сжат
    подозреваю, они заодно оптимизируют
    а так нет, этого не может быть, потому что не может быть никогда
  • 0
    До / после
    Увеличил объём данных в 2 раза, зато уменьшили число запросов в 50 раз.
    Понятно, что станет лучше.

    Вообще, у меня есть идея как оценивать такие штуки чисто теоретически.
    Смотрим цены на запросы и трафик, например, на Amazon S3 и считаем, что выгодней по деньгам. Где по деньгам выгодней — там и нагрузка будет меньше, скорей всего.
    • –1
      Не все нужно совать в data:uri, туда только то, что действительно необходимо (реально маленькие файлы), если есть вариант использовать CSS спрайты — лучше юзать их, потому что data:image из base64 распаковывается дольше, чем простая картинка, но грузится быстрее.
      • 0
        Я и не говорил, что всё. Но с такими соотношениями для 99% сайтов data/uri будет точно выгодней. Хотя совсем не исключено, что спрайты будут еще выгодней.
  • 0
    > Кодируем изображение в base64 с помощью онлайн сервисов

    Вот этого не надо IMHO советовать. Мало ли какой эксплойт они там подсунут/подмешают.

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

    Про скорость рендеринга таких картинок: data:URI и производительность, или как замедлить Firefox в 10 (десять) раз
    И еще вот: Кроссбраузерное использование data:URL
  • 0
    Спасибо, у меня в текущем проекте как раз много мелких иконок.
    Написал себе python-скрипт для конвертации url("../path") в url(data:image/png;base64, data)
  • 0
    а что значит «картинки нельзя засунуть в спрайты»?
  • 0
    OK, а как тогда определённый слой SVG таким образом использовать?
    Допустим, мы упаковали SVG в base64, прописали правильный mime (image/svg+xml), а как слой тогда указать (было, например, filters.svg#superslice).
  • 0
    Вот монстры интернета, например, Google и Apple на своих сайтах используют спрайты. Думаю лучше использовать именно их. Еще и редактировать удобно (в какой-то мере) — открыл один файл и правишь львиную часть дизайна. Удобно.
  • 0
    Круть — анимированный гиф тоже поддерживается севрисом www.dailycoding.com/Utils/Converter/ImageToBase64.aspx
  • 0
    Emmet, который есть почти для всех популярных редакторов, кроме чудесного Zen coding в том числе умеет по шорткату конвертировать изображения в base64. В Coda 2 — курсор в любое место URL с изображением, Ctrl+I и готово.

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