There’s been a lot of debate among web professionals about whether or not it makes sense to server “retina” images to website visitors who’s devices support high pixel densities. In order to take full advantage of the sharpness of the new iPad’s screen, website owners would need to prepare their images at four times the number of pixels of normal (“72dpi”) web images.
I ran a few quick tests to see how much all those extra pixels affected overall file size. I used 130 randomly chosen jpeg images (all straight from my DSLR camera), and ran Photoshop and Irfanview batches to crop and scale them to a couple of often-used sizes. I used the same JPEG settings each time, and made sure the only difference between the images would be that the retina ones were four times sharper.
|Image type||resolution||File size||Increase|
|Website headers (130)||960*280px (non-retina)||9.51 MB|
|Website headers (130)||1920*560px (retina)||20.70 MB||218%|
|Content images (130)||320px longest side (non-retina)||5.90 MB|
|Content images (130)||640px longest side (retina)||11.50 MB||194%|
|Icons (46)||250*250px (non-retina)||709 KB|
|Icons (46)||500*500px (retina)||2.30 MB||324%|
My office buddy @geerdesontwerp was kind enough to hook me up with a set of high-quality icons. I used these to run a test where I’d batch convert these to PNG, to get an idea of how efficient PNG handles the extra data in non-photographic images.
What these shows is that yes, you will need extra bandwidth to serve high-density images. But not four times as much. JPEG images seem to average at about twice the file size. The PNG test seems to indicate that PNG does a lot worse, but with only 46 test images, I’d say this warrants further investigation.
Another thing to consider is that you might be able to get away with using significantly more compression on retina images. The whole point is that people won’t see pixels anymore, and the same probably goes for JPEG artifacts.