Avoiding inefficiency in multi-platform product web serving

In the previous blog post, we described a house picker test project. The program shows a list of houses you might want to buy around the world. When you are talking about a dynamic list of houses, one can assume that the list is kept on a server in the cloud, and that the client is downloading the house descriptions and photos from the server. But each client has a different resolution screen size, and that means the photos if they are served at one single size, will need to be resized at the client side. This will result in blurred images, as the browsers don't do a good job of image resizing. So the burning question is, what resolution graphics do you store on the server? If you put nice big images on the server, and the client happens to be a tiny mobile phone, you are downloading much larger images than you need. Some people will choose to store smaller images on the server, which looks bad on big screen clients, to make the mobile clients run faster. 

As an experiment, i made a CGI-BIN program that lets the client program ask for exactly the size image they need, and resizes the image on the server side, storing it in a cache, so that repeated requests for that same size don't need to perform the image processing again. It is a small program, and results in the perfect size image downloaded, with zero waste in bandwidth. It turns out web browsers cache CGI-BIN requests the same as plain old images, so the browser still works great. I calculated that it cut down the number of bytes downloaded by over 50% on a mobile client, because you don't need the full resolution of the graphic. It makes you wonder how much resizing is going on at the client side, and how much of the total traffic of the internet is wasted because graphics are the wrong size. Hard drive space is incredibly cheap nowadays, and bandwidth and server time is much more expensive. Downloading a graphic that is twice the size it needs to be, not only chews up bandwidth, but your server capacity is directly proportional to the number of clients you are capable of serving at one moment, and when your server is pushing down to a client something twice as big as it needs to be, you are tying up the server for twice the time period.

Not every website serves up images, but those applications that are image-centric would greatly benefit from this optimization of download. 

It is also true that there is a lot of plain ASCII JSON encoding being used in clients, and Joe Armstrong got very heated about that in a talk a while back, where he noted that Ericsson sweated hard to save every bit in their overhead, and how infuriating it was to see bloated JSON encodings in packets. Unfortunately most programming languages are very clumsy at binary packing, and encoding things into a tight binary packing can be lot of extra work in many languages. Luckily in Beads, there is the concept of a binary bit array, and you can encode variable length numbers on bit boundaries with trivial effort. Tight packing of packets can make your online service be a lot zippier, and not require such big server resources.