Is it necessary to pack small images as data:image;base64 in css or how to convince the opponent?

Question

css

Hello,

I recently had a heated argument with a friend about whether icons and small pictures should be packaged in base64. The specifics are that we are writing a phonegap + sencha touch 2 application, but there is also a website.

He argued against this practice:

1) increasing the size of the CSS file
2) increasing the time to load the image (base64 decoding)
3) the inconvenience of working with CSS containing binary data, the inconvenience of replacing the image
4) one image can be used in many places - you have to make a general style for one image and then cascade for individual elements
5) images cache well
6) his familiar layout designers hear about it for the first time

. I'm in refutation:

1) reduce the number of requests
2) get rid of the bug when loading / rendering of several images does not occur simultaneously (although you can group images into sprites)
3) when using sass / compas, we get rid of the need to manually encode and insert images in css
4) accepted practice ( see page speed, how they do it in sencha touch)
5) an article about this on habré

Can someone share their experience and give arguments for or against, or challenge the arguments I have presented?

Answer 1

About the cache: css will be cached in the browser in the same way as a set of images.
Only then they added one small picture (deleted, changed) and the browser, instead of sucking only it, drags css with the whole set.
Well, just tweak the css a little - pump everything out again.

Answer 2

This approach is very relevant when your server is very heavily loaded with connections, in other cases, ordinary pictures are preferable, everything is cached anyway.

Answer 3

Initially, you think in the wrong direction, like many on Habré ... Read about Application Cache - this is a modern solution.

Answer 4

1) increasing the size of the CSS file
It would be better to put pictures in a separate CSS, then it’s not scary
2) increasing the time to load the image (base64 decoding)
Time is negligible, so you can get to the point that bmp instead of jpeg is given
3) inconvenience of working CSS containing binary data, the inconvenience when replacing the
CSS image into a separate file, collecting a script from images, there will be no difficulties. Sprites, in the end, editing is also not very convenient.
4) one image can be used in many places - you will have to make a common style for one image and then cascade for individual elements
. That's good, there will be no code duplication.
5) images cache well
CSS is not worse
6) his familiar typesetters hear about it for the first time
. It happens. But it would be better to keep silent about it and google it.

Answer 5

My experience with this technique has been extremely positive. However, I need to display not icons, but full-fledged images, 10-20 pieces per page, and they are all dynamically generated, so sprites are excluded. The base64 decode time is ridiculous compared to the extra request time.
In the case of small static images, there will not be much difference compared to a single sprite.
The argument “the layout designers did not hear” can be dismissed. Once upon a time, people did not hear about the web.

Answer 6

In general, if you are using Application Cache, then there is really no need to use base64. It's like arguing to add 1 or 2 hp. in a 500 horse engine.
At the same time, getting inconvenience in situations with sprites on several different elements.
When using Application Cache, the browser first requests only the manifest file and, if it is modified, starts sending if-modified-since requests for each file.
Now let's calculate: let's say you have pictures / icons of 20KB * 10 pcs. = 200KB
In base64 the size will increase by 1.37 = 274KB + the weight of the rest of the CSS.
Those. when changing 1 file, you will have to reload 274KB, at least.
Now what happens if you just cache images, overhead on an HTTP request (headers) - 0.15-0.3 KB,
total 10*0.3 = 3KB + 20KB new file = 23KB. But here is an overhead to the network (keep-alive) 1*DNS Lookup + 1*Connect + 10*Send/Receive.
- Although, for example, I like this feint with a decrease in the number of requests - in general, one must really proceed from the tasks - somewhere this is appropriate, and somewhere akin to saving on matches.
en.wikipedia.org/wiki/Data_URI_scheme#Advantages

Answer 7

Such holivars always inspire boredom.
If the solution has no killer pluses or obvious minuses, then you should choose based on your personal convenience.

Answer 8

By itself, this does not give anything in terms of download time (online event even happens later) or download speed.
But in combination, this is a very good method for optimizing the number of requests and the cache.
www.wott.info/wordpress/optimization-in-numbers/

Answer 9

I propose a formula by which you can calculate the relevance of storing images in css.
1) All images that users and site administrators do not change (slider controls, pagination, logo, background ...) should be stored in css. Attach other pictures.
2) Image size less than x bytes also stored in css.

Answer 10

W3C swears at base64.