4 ms·

Don’t use JavaScript for Retinafying

15 points by cleverjake 14y ago

madrobby 14y ago
Of course, exceptions prove the rule. Sometimes CSS and HTML are not good enough and you'll have to resort to use JavaScript. But you shouldn't make it the default go-to.
mddw 14y ago
Don't retinafy at all. You should not assume your user has LTE speeds on his shiny iPad. As long as webdevs won't have a better navigator.connection, retinafying should be avoided. On the web, loading times trump beauty.
- madrobby 14y ago
  Larger image dimensions don't mean larger file sizes, see http://mir.aculo.us/2012/08/06/high-resolution-images-and-file-size/ http://mir.aculo.us/2012/08/06/high-resolution-images-and-fi... for an explanation.
  - mddw 14y ago
    Yes, it does. Not linear larger files, but larger files at constant quality. His examples are conveniently chosen to sell his book. 20% bigger is 20% too much for a non essential asset.
  - cheald 14y ago
    Double image dimensions don't mean double file sizes, but they do mean larger file sizes. If you've figured out how to display the same non-vector images at full quality at arbitrary file dimensions with the same filesize, then you're going to be very, very rich.
sratner 14y ago
> for bitmapped images, go high-resolution and let the browser scale down Wait, I should use more bandwidth than I need, and impose a client-side performance hit? What is wrong with a little CSS to serve the right assets to 1x, 1.5x and 2x pixel ratio devices?
cheald 14y ago
This is a horrible suggestion. Stop being careless with your users' bandwidth. Assuming that every client should get the highest-resolution (and thus highest-bandwidth and highest-memory-cost) assets is just lazy. Use Javascript. Something like https://github.com/scottjehl/picturefill https://github.com/scottjehl/picturefill works beautifully and results in only one request per asset, with a noscript fallback. It's more markup, which is kind of a pain in the ass, but it means that the right clients get the right assets and you don't end up destroying your poor EDGE and 3G customers because you decided they needed a 2400x1200 splash image. Let's not forget that a "retina" image imposes a 4x memory cost on the client - image data has to be decompressed to be displayed. So, your user on their mobile phone with 512mb of RAM is going to have a terrible experience when your website is using 4x more of their precious RAM on images that don't actually provide them with any visual benefit. Double-pixel displays are still, by a massive margin, the exception. Unless you're specifically serving a Retina Macbook-targeted audience, you're going to incur a lot of overhead for no appreciable benefit for the majority of your audience.
- basicxman 14y ago
  Not to mention, using high resolution graphics when only displaying at a lower resolution increases battery usage and lowers performance of the webpage.
kaolinite 14y ago
Why not use a rewrite for Apache or Nginx? More info: http://undefinedbehavior.net/2012/03/27/retina-rewrite/ http://undefinedbehavior.net/2012/03/27/retina-rewrite/

15 points by cleverjake 14y ago

Of course, exceptions prove the rule. Sometimes CSS and HTML are not good enough and you'll have to resort to use JavaScript. But you shouldn't make it the default go-to.

mddw 14y ago

Don't retinafy at all. You should not assume your user has LTE speeds on his shiny iPad. As long as webdevs won't have a better navigator.connection, retinafying should be avoided. On the web, loading times trump beauty.

madrobby 14y ago
Larger image dimensions don't mean larger file sizes, see http://mir.aculo.us/2012/08/06/high-resolution-images-and-file-size/ http://mir.aculo.us/2012/08/06/high-resolution-images-and-fi... for an explanation.
- mddw 14y ago
  Yes, it does. Not linear larger files, but larger files at constant quality. His examples are conveniently chosen to sell his book. 20% bigger is 20% too much for a non essential asset.
- cheald 14y ago
  Double image dimensions don't mean double file sizes, but they do mean larger file sizes. If you've figured out how to display the same non-vector images at full quality at arbitrary file dimensions with the same filesize, then you're going to be very, very rich.

sratner 14y ago

> for bitmapped images, go high-resolution and let the browser scale down Wait, I should use more bandwidth than I need, and impose a client-side performance hit? What is wrong with a little CSS to serve the right assets to 1x, 1.5x and 2x pixel ratio devices?

cheald 14y ago

This is a horrible suggestion. Stop being careless with your users' bandwidth. Assuming that every client should get the highest-resolution (and thus highest-bandwidth and highest-memory-cost) assets is just lazy. Use Javascript. Something like https://github.com/scottjehl/picturefill https://github.com/scottjehl/picturefill works beautifully and results in only one request per asset, with a noscript fallback. It's more markup, which is kind of a pain in the ass, but it means that the right clients get the right assets and you don't end up destroying your poor EDGE and 3G customers because you decided they needed a 2400x1200 splash image. Let's not forget that a "retina" image imposes a 4x memory cost on the client - image data has to be decompressed to be displayed. So, your user on their mobile phone with 512mb of RAM is going to have a terrible experience when your website is using 4x more of their precious RAM on images that don't actually provide them with any visual benefit. Double-pixel displays are still, by a massive margin, the exception. Unless you're specifically serving a Retina Macbook-targeted audience, you're going to incur a lot of overhead for no appreciable benefit for the majority of your audience.

basicxman 14y ago
Not to mention, using high resolution graphics when only displaying at a lower resolution increases battery usage and lowers performance of the webpage.

kaolinite 14y ago

Why not use a rewrite for Apache or Nginx? More info: http://undefinedbehavior.net/2012/03/27/retina-rewrite/ http://undefinedbehavior.net/2012/03/27/retina-rewrite/