[emptysea]

What I’ve seen instagram and slack do is create a really small jpg and inline that in the API response. They then render it in the page and blur it while the full size image loads.

Placeholder image ends up being about 1KB vs the handful of bytes here but it looks pretty nice

Everything is a trade off of course, if you’re looking to keep data size to a minimum then blurhash or thumbhash are the way to go

[codetrotter]

Yep. I also remember a blog post from a few years ago about how fb removed some of the bytes in the JPEG thumbnails, because those bytes would always be the same in the thumbnails they created, so they kept those bytes separate and just added them back in on the client side before rendering the thumbnails

[jws]

As you get to small image sizes, the relative size of the quantization table and the Huffman encoding table becomes significant. You can easily just pick a standard version of these, leave them out of the image (which is no longer a valid JPEG), and then put them in at the destination to make a valid JPEG again.

I'm not finding a source, but I think I remember the tables being in the 1-2kB range.

Cheap MJPEG USB cameras do this. Their streaming data is like JPEG but without the tables since it would take up too much bandwidth.

[canucker2016]

Mentioned the FB blog post in my comment to this post. I didn't see any mention of the size of the fixed tables.

see https://news.ycombinator.com/item?id=35268708

[georges_gomes]

This technic is very interesting. I imagine quite effective and very small JavaScript decoded.

[degenerate]

I both love this level of optimization (for the novelty) and hate it (knowing all the work involved is being done with JS, on my machine, costing more CPU time than the bandwidth saved)

[explaininjs]

The claim being that the act of concatenating some bytestrings together is a massive time sink?

[8n4vidtmkvmk]

Decode from base64 json, concat, convert to a Blob, createObjectURL and feed back into an img? That's about the simplest way I can think to do it. Either that or blip it onto a canvas. Or convert it back to base64 in the form of a data-URI.

[eyelidlessness]

I just recently did some work in a much less sophisticated area of this. For folks who want to efficiently juggle image data into and out of canvas, ImageBitmap is a little known web API that does it very well. Unlike most web APIs dealing with binary data that interfaces with user interaction, you can use it synchronously, and it’s vastly more efficient than juggling base64-blobs-URLs.

[8n4vidtmkvmk]

That was the 'blip it onto the canvas' approach :D I discovered that ImageBitmap type just recently too, it's been very handy for the little project I'm working on. My data still comes as base64 strings in JSON though.

[explaininjs]

No reason to transfer the image data in JSON, just read the response as an ArrayBuffer. Pass over that and write it into a dataURI with the needed modifications in a single go.

[8n4vidtmkvmk]

How are you going to do that? There's other things in the payload. If it was just the image in the response you could read it as binary, but remember we want lots of tiny images coupled with titles and other metadata. You can use something other than JSON but it'll need some kind of structure that needs parsing.

[Doxin]

As far as I know just about any file format other than JPEG is better at this. If I recall correctly you basically want to go with GIF if your thumbnail has less than 255 pixels total.

[emptysea]

just tested this and the jpeg ends up being 690 Bytes while the gif ends up being 2 KB

[Doxin]

That can't possibly be right. What size image are you using here?

[nonethewiser]

> Everything is a trade off of course, if you’re looking to keep data size to a minimum then blurhash or thumbhash are the way to go

Isn’t that optimizing for load speed at the expense of data size?

I mean the data size increase is probably trivial, but it’s the full image size + placeholder size and a fast load vs. full image size and a slower load.