Best practice for inlining images using data:-URLs? - html

Question

I have a simple rails app that stores images created by users in an HTML5 site using canvasContext.toDataURL(). There's an index action, which shows a list of thumbnails, and a show action for each image, showing the image.
I'm being absolutely lazy in the backend here, I just store the base64 encoded data:image/png;base64,... Strings of the original image and a thumbnail, which is also generated in the client. The images are included in the page using <img src="data:"/> URIs.
Now, since this isn't fully supported in IE before v9, I will have to implement some kind of workaround, probably by including the URL of the generated image using a data- attribute and then replacing the source attribute after page load using jQuery.
This brings up the question whether it's good practice to inline rather large images into HTML using data: URLs...
Are there any recommendations or best practices? The images might be up to 500 KiB, and each of them is used only once. The page containing the images will not change once created, so it should be cacheable pretty good, including the image. The index page containing the thumbnails (which are around 60 KiB) uses pagination, so the page will hardly be cacheable. You can assume that the HTML pages will be deflated or gzipped in production.

Answer 1

Best-practice is: Don't.
You'll need a workaround anyway, which will completely duplicate the basic functionality, so you've just another place things can go wrong and more cases to test.
You say the images should be very cacheable, but you're sending them in a way that doesn't allow you to include information about caching. However, with the more common approach of sending images over a separate HTTP request, you can send expires and max-age requests to indicate the image won't change for a year. If you're super-confident that the image won't change you can also set a last-modified and an e-tag (you don't even need any logic to decide on the etag, just send "IMMUTABLE" as the tag) and respond to every conditional GET by sending a 304 without even checking (because again, you only do that if you're super-confident, otherwise though you can still implement a more conventional check for 304).
If the image is just used once, then have the image served by something that creates it and writes it based on some identifying features in the query (just what is specific to what you are doing) and writes it to the stream to the browser. You'll still have nicer separation within your application to have this done in its own place.
Even with gzip, you aren't going to beat this on stream size.

Answer 2

This is not a good idea. I would use normal, separate image resources instead.
By using inline images,
you destroy all cacheability for static images - with inlined images, every time the HTML page changes, all the image data has to be reloaded as well.
gzipping/deflating will take longer, and produce sub-optimal results (because image data is much harder and much less efficient to compress).
the rest of the Internet is geared towards HTML documents and images being separate resources: Prefetchers, caching systems, proxies...
then you have browser compatibility, which as you point out, is abysmal for older IEs.

Answer 3

My advice ? Don't do it.
A real file can be modified more easily with backend libraries, so don't.
And if you want use base64 in your page, you can easily do it with HTML5.
var xhr = new XMLHttpRequest();
xhr.open('GET', 'images/myimage.png', true);
xhr.responseType = 'arraybuffer';
xhr.onload = function(e){
if(this.status == 200){
var bb = new WebKitBlobBuilder(); // Or MozBlobBuilder, MSBlobBuilder, etc.
bb.append(this.response);
var reader = new FileReader();
reader.readAsDataURL(bb.getBlob('image/png'));
reader.onloadend = function(e){
$("#myimage").attr("src", reader.result);
};
}
};
xhr.send();