Re: [public-respimg] Best Practice Resizing + Asset Re-Downloading / Resp ImageFormat

On 05.07.2013, at 09:47, Tom Maslen <tom.maslen@bbc.co.uk> wrote:
> Is there a hard limit to how much you can get away with scaling the image up/down before its better to just download an alternative image?
> 
> When I made the responsive images solution for m.bbc.co.uk/news we didn't have any data to make a decision about this so I just guessed and made the images scale 100% to fit its containing element, but then get the JS to swap the image out for a better fitted alternative every 30px.
> 
> /t
> 
> Tom Maslen
> Tech Lead
> BBC News Visual Journalism
> 
Tom,

--- First, I changed the subject to a more useful one as <none> doesn't help anyone searching the archives. ---

You're definitely hitting a good point here. I didn't ever researched this in detail unfortunately.
But if you are using a JavaScript which dynamically requests different sizes of images 
depending on the screen size you should be careful loading new assets.

Always keep in mind that people might be on costly network connection and might not want to 
re-download another image that only slightly improves quality.
This is not only on mobile devices but targets users tethering their connection to their notebook or similar.

Therefore I would only re-download an asset if it dramatically changes its content (art-direction use case) 
or quality (say from 320px to ~800px). Every 30px seems to be too much. 
If you only do this once onload and not dynamically onresize your approach is indeed very good 
although 30px is already very granular and means you have to keep a lot of different
sizes of your assets on your servers.

Speaking of resizing performance impacts you there won't be any on such slight resizes. What I was speaking about 
are resized images like 2048px*1536px down to 1024*768px or even larger (panoramic images). There you can clearly 
see the CPU/GPU of the devices is too slow to repaint that in time on cheap mobile phones.

Cheers,
Anselm  |  @helloanselm  |  helloanselm.com

Received on Friday, 5 July 2013 08:14:58 UTC