For small size image what's (if any) the benefit in loading time using base64 encoded image in a javascript file (or in a plain HTML file)?

$(document).ready(function(){
    var imgsrc = "../images/icon.png";
    var img64  = "P/iaVYUy94mcZxqpf9cfCwtPdXVmBfD49NHxwMraWV/iJErLmNwAGT3//w3NB";

    $('img.icon').attr('src', imgsrc); // Type 1
    $('img.icon').attr('src', 'data:image/png;base64,' + img64); // Type 2 base64
});

For small size image what's (if any) the benefit in loading time using base64 encoded image in a javascript file (or in a plain HTML file)?

$(document).ready(function(){
    var imgsrc = "../images/icon.png";
    var img64  = "P/iaVYUy94mcZxqpf9cfCwtPdXVmBfD49NHxwMraWV/iJErLmNwAGT3//w3NB";

    $('img.icon').attr('src', imgsrc); // Type 1
    $('img.icon').attr('src', 'data:image/png;base64,' + img64); // Type 2 base64
});

• javascript
• html
• css
• image
• base64

• 2 You save one request to the server. For small images, that can help if network latency is greater than the time spent decoding the image. – Frédéric Hamidi Commented Dec 2, 2011 at 15:28
• 1 Note, just to clarify -- it only helps if you include the image in a file that you've already paid the overhead to request. I.e., if you add the BASE64 image to your index.html, then you save a separate hit to icon.png. But if you put the BASE64 image in icon.html and then request that in place of icon.png, you've not accomplished anything. – Alex Howansky Commented Dec 2, 2011 at 15:42

3 Answers 3

The benefit is that you have to make one less HTTP request, since the image is "included" in a file you have made a request for anyway. Quantifying that depends on a whole lot of parameters such as caching, image size, network speed, and latency, so the only way is to measure (and the actual measurement would certainly not apply to everyone everywhere).

I should mention that another common approach to minimizing the number of HTTP requests is by using CSS sprites to put many images into one file. This would arguably be an even more efficient approach, since it also results in less bytes being transferred over (base64 bloats the byte size by a factor of about 1.33).

Of course, you do end up paying a price for this: decreased convenience of modifying your graphics assets.

You need to make multiple server requests, lets say you download a contrived bit of HTML such as:

<img src="bar.jpg" /> 

You already needed to make a request to get that. A TCP/IP socket was created, negotiated, downloaded that HTML, and closed. This happens for every file you download.

So off your browser goes to create a new connection and download that jpg, P/iaVYUy94mcZxqpf9cfCwtPdXVmBfD49NHxwMraWV/iJErLmNwAGT3//w3NB

The time to transfer that tiny bit of text was massive, not because of the file download, but simply because of the negotiation to get to the download part.

That's a lot of work for one image, so you can in-line the image with base64 encoding. This doesn't work with legacy browsers mind you, only modern ones.

The same idea behind base64 inline data is why we've done things like closure compiler (optimizes speed of download against execution time), and CSS Spirtes (get as much data from one request as we can, without being too slow).

There's other uses for base64 inline data, but your question was about performance.

Be careful not to think that the HTTP overhead is so massive and you should only make one request-- that's just silly. You don't want to go overboard and inline all the things, just really trivial bits. It's not something you should be using in a lot of places. Seperation of concerns is good, don't start abusing this because you think your pages will be faster (they'll actually be slower because the download for a single file is massive, and your page won't start pre-rendering till it's done).

It saves you a request to the server.

When you reference an image through the src-property, it'll load the page, and then do the additional request to fetch the image.

When you use the base64 encoded image, it'll save you that delay.