How much faster is it to use inline/base64 images for a web site than just linking to the hard file?

Question

How much faster is it to use a base64/line to display images than opposed to simply linking to the hard file on the server?

url(data:image/png;base64,.......)

I haven't been able to find any type of performance metrics on this.

I have a few concerns:

• You no longer gain the benefit of caching
• Isn't a base64 A LOT larger in size than what a PNG/JPEG file size?

Let's define "faster" as in: the time it takes for a user to see a full rendered HTML web page

Entertaining

Answer 1

'Faster' is a hard thing to answer because there are many possible interpretations and situations:

Base64 encoding will expand the image by a third, which will increase bandwidth utilization. On the other hand, including it in the file will remove another GET round trip to the server. So, a pipe with great throughput but poor latency (such as a satellite internet connection) will likely load a page with inlined images faster than if you were using distinct image files. Even on my (rural, slow) DSL line, sites that require many round trips take a lot longer to load than those that are just relatively large but require only a few GETs.

If you do the base64 encoding from the source files with each request, you'll be using up more CPU, thrashing your data caches, etc, which might hurt your servers response time. (Of course you can always use memcached or such to resolve that problem).

Doing this will of course prevent most forms of caching, which could hurt a lot if the image is viewed often - say, a logo that is displayed on every page, which could normally be cached by the browser (or a proxy cache like squid or whatever) and requested once a month. It will also prevent the many many optimizations web servers have for serving static files using kernel APIs like sendfile(2).

Basically, doing this will help in certain situations, and hurt in others. You need to identify which situations are important to you before you can really figure out if this is a worthwhile trick for you.

Observation

Let's define "faster" as in: the time it takes for a user to see a full rendered HTML web page – Entertaining

Caching/perf on server end may not be so problematic. You could still cache your pages into files partially, so there's no need to repeatedly convert images into base64. If your page doesn't change very often, you could also tell the browser to cache the html file itself. – Dactylography

well said. in smaller server, it's much better to load images from a separate file server – Beta

'Let's define "faster" as' What user? What is their pipe like. How often do they hit your page(s)? What caching strategiesa re used? The point is that there is no single "faster" metric, and no single answer. – Hobo

Answer 2

I have done a comparison between two HTML pages containing 1800 one-pixel images.

The first page declares the images inline:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">

In the second one, images reference an external file:

<img src="img/one-gray-px.png">

I found that when loading multiple times the same image, if it is declared inline, the browser performs a request for each image (I suppose it base64-decodes it one time per image), whereas in the other scenario, the image is requested once per document (see the comparison image below).

The document with inline images loads in about 250ms and the document with linked images does it in 30ms.

(Tested with Chromium 34)

The scenario of an HTML document with multiple instances of the same inline image doesn't make much sense a priori. However, I found that the plugin jquery lazyload defines an inline placeholder by default for all the "lazy" images, whose src attribute will be set to it. Then, if the document contains lots of lazy images, a situation like the one described above can happen.

Beatific

Do you caching enabled? – Michaelmas

If you put your base64 image to CSS class instead of img tag, it'll be lightning fast, and you control cache and lifecycle. – Pisolite

If I use base64 image as a background-image in CSS does this affect my page speed? (Does this make a request on the server to find an image?) – Lesser

It seems like the advantage of using base64 img is with tiny image, not big one. So a test with tiny images would be more interesting – Saccharate

Answer 3

You no longer gain the benefit of caching

Whether that matters would vary according to how much you depend on caching.

The other (perhaps more important) thing is that if there are many images, the browser won't get them simultaneously (i.e. in parallel), but only a few at a time -- so the protocol ends up being chatty. If there's some network end-to-end delay, then many images divided by a few images at a time multiplied by the end-to-end delay per image results in a noticeable time before the last image is loaded.

Isn't a base64 A LOT larger in size than what a PNG/JPEG file size?

The file format / image compression algorithm is the same, I take it, i.e. it's PNG.

Using Base-64, each 8-bit character represents 6-bits: therefore binary data is being decompressed by a ratio of 8-to-6, i.e. only about 35%.

Thomasinathomasine

If your server is serving with gzip or deflate (most do), it's almost a wash, as the base64 compresses and images typically don't. A random test with a image that was 214312 bytes was 213879 gzipped and the base64 was 285752 which gipped to 215779. So if you figure the header overhead of multiple requests it's really about the same. – Pollinate

Answer 4

How much faster is it

Define 'faster'. Do you mean HTTP performance (see below) or rendering performance?

You no longer gain the benefit of caching

Actually, if you're doing this in a CSS file it will still be cached. Of course, any changes to the CSS will invalidate the cache.

In some situations this could be used as a huge performance boost over many HTTP connections. I say some situations because you can likely take advantage of techniques like image sprites for most stuff, but it's always good to have another tool in your arsenal!

Catchweight

You'll benefit greatly from the reduced number of HTTP requests, too. – Laborer

Let's define "faster" as in: the time it takes for a user to see a full rendered HTML web page – Entertaining