Improving Dropbox Performance: Retrieving Thumbnails

Mostly you shouldn&#x27;t have to hide backend latency by reordering, and if you don&#x27;t reorder, you can just use JPEG image strips&#x2F;sprites, which don&#x27;t need double compression. JPEGs also stream, but in an order determined by the client, not the server.<p>In my experience, Dropbox is quite a bit slower (by 10-20x) than services optimized for serving images - using 1500ms to deliver a 25k file is very slow on the web, but it is very common when requesting files via the Dropbox web API. (I can only speculate about the reasons, but Amazon&#x27;s s3 has big latencies too.)

I don&#x27;t really use Dropbox, but I was randomly browsing through mine looking for a photo the other day and it was a &quot;holy shit&quot; moment. It&#x27;s really fast to scroll through a huge number of photos. I had been scrolling through Flickr a few minutes before and it was a massive difference. Flickr was very much a scroll-and-wait experience.

On the functionality end of things I think dropbox should be stop new feature development until heavy UX is done with large unbiased test groups. The application is simple and it works pretty well but recently I&#x27;ve noticed different barriers to use, notifications that I&#x27;d prefer not to see just getting in the way. It&#x27;s a result of Zawinski&#x27;s law, it&#x27;s happening to gmail where they think adding more bells and whistles is needed but it&#x27;s not, in many case user experience declines, for example playing a youtube clip now blacks out the rest of your gmail page while you watch it. Application developers need to learn that less is more.

What about a sprites-like system?<p>Since you pretty much know which pictures the user will request, just glue the next 100 thumbnails together into one big picture and then take it apart again on the device.

Were you already serving thumbnails over https? Or were they served over http?<p>edit: I was also wondering whether you can skip downloading some thumbnails based on the velocity of the scroll.

Basically, they chunk thumbnails - client asks for the next 10 thumbnails in one request, server sends back 10 thumbnails in the response.

Base64 and then gzip just to make it easier on javascript? Seems hard on dropbox servers.<p>Why not use a multipart binary response?

I think they could still do better without using SPDY. Going to try and make time to test a different approach.

tldr: use SPDY, but until more universal support a similar custom hack is proposed<p>Neat hack though.. frustrating how much perf is lost due to HTTP sometimes

I just see one problem with this solution. You can&#x27;t create Retina images out of base64 strings on any web browsers today.