Using dynamically resized-images from Google+
As I was saying in this previous post, during the development of interiordelight.ro I've learned a few new tricks that I'd like to share with you here. One of them is the idea of using dynamically resized-images previously posted on Picasa/Google+.
Since interiordelight.ro is mostly a "portfolio website", naturally we have quite a number of high-quality images.
Normally I prefer to use a paid and reliable service like Amazon S3 for image storage, but in this case I've decided to try something different.
Since one of the goals of the new design was to make it mobile-friendly while still being fast and "snappy" and presenting high-quality images, I thought about using images stored on Google+ (the former Picasa, actually) because of an interesting undocumented feature they have: depending on the request URL you're using, you can get the original image in various sizes and their servers will dynamically resize it, crop it, serve it and instruct the browser to cache the result for one day. And all of that incredibly fast (around 100ms).
Which means you can practically use the same source to generate thumbnails and content for various size desktops, tablets and phones without having to do any kind of ImageMagick processing.
Here's an example:
Original image, url ending with /s0/...jpg
:
Resized image, url ending with /w300/...jpg
:
Cropped thumbnail, url ending with /s100-c/...jpg
:
(go ahead, inspect the images above to see what I mean)
Apparently googleusercontent
servers allow for a variety of parameters, but since this feature is not documented anywhere you'll have to experiment for yourself and if you decide to use it you'll do it on your own responsibility and I'd suggest keeping an eye on everything since they might change this behaviour at some point.
Since there's really no way of knowing "a priori" all possible device sizes and I don't want to abuse Google's image processing and caching, I've also decided to employ a little trick in a debounced window.onresize
handler to request only a finite number of possible dimensions. For instance, the code below refers to the "swipeable" fullscreen picture gallery that we have on every project page:
...
# Swiper images
if $('.swiper-container').hasClass 'active'
width = Math.ceil($win.width() / 100) * 100
height = Math.ceil($win.height() / 100) * 100
for item in $('.swiper-img')
$item = $(item)
srcParts = $item.attr('src').split '/'
srcParts[srcParts.length - 2] = "w#{width}-h#{height}"
$item.attr 'src', srcParts.join '/'
...
Basically, what I'm doing is that when the page loads (and later on resize
events), I'm recalculating the image source sizes so that I'm always loading images sized by a multiple of 100px, slightly larger than the current window size; i.e. if window.width = 768px, then load image with width = 800px.
It sounds a bit complicated, but it's not, and we always end up with the user seeing the highest-quality available given the device screen size / orientation, without having to load the largest possible image.
That's it for now, but there are more tips & tricks like this one coming up soon, so, stay tuned!... :-)
Written by Ionut-Cristian Florescu
Related protips
5 Responses
If you liked this tip, you might also be interested in a quick and dirty fix for the infamous Safari blank-page bug.
Just make sure you have a backup plan in case G+ cuts you off :)
@dpashkevich - true :-).
It happened before with Buzz... That's why I said "if you decide to use it you'll do it on your own responsibility and I'd suggest keeping an eye on everything since they might change this behaviour at some point" :-)
On the other hand, Google+ seems to do well and it's still gaining momentum as we speak...
I guess I meant somehow restricting/changing the API you're exploiting, not shutting down the service
@dpashkevich - yes, a change in behaviour is always a possibility. Restricting it, I don't know about that... I don't see why would they do that. Besides, this is exactly how they're using it on Google+ itself.