How to serve high-resolution website images for retina displays (new iPad/iPhone4+)

| 40 replies | Short URL: http://benfra.in/1xs

About

This article covers how to serve high resolution images on your website for users of high resolution ‘retina’ device screens.

If you find this post interesting or useful, you may want to check out my book ‘Responsive web design with HTML5 and CSS3‘ as it covers associated topics and techniques.[End of shameless plug.]

Introduction

Yesterday, Luke Wroblewski shared the following summary of info from Apple’s new iPad launch:

A total of 315 million iOS devices have been sold with 62 million sold the last quarter alone.
76% of Apple’s revenue in Q42011 came from the iOS product lines: iPod, iPhone, and iPad
Apple now has 362 retail stores worldwide.
Over 25 billion app downloads since Apple introduced the App Store.
There are now over 100 million customers on iCloud.
Apple sold 15.5 million iPads last quarter alone. That’s more iPads sold in the last quarter alone than any PC manufacturer sold in their entire line. The iPad is just 2 years old.
200k apps have been custom built for the iPad.

It doesn’t take a genius to appreciate that if you aren’t designing and building websites today with the gamut of available devices (mobile, tablet, laptop, portable game station, desktop etc.) in mind you’re very quickly going to fall behind.

One feature of the newer iOS devices I’m particularly excited about is the ‘Retina’ displays. Whilst the ‘new iPad’ (was 3rd generation, now 4th generation) has a 2048-by–1536-pixel resolution at 264 pixels per inch (ppi) screen, the iPhone 4, iPhone 4S and iPhone 5 have an ever higher resolution screen: that is at least 960-by–640-pixel resolution at 326 ppi. If you have one of these devices you’ll know that images and text look beautiful on them. These digital devices (handheld, desktop, whatever) are now enjoying a level of ppi more akin to print.

When it comes to text, fonts, with their mathematical scalability fare excellently on these higher ppi devices. A good font looks beautiful on a retina display. However, web images, typically exported at 72 dpi (dots per inch, not pixels per inch – I’m not getting into that here), don’t fare quite so well. Here’s how we can fix that.

Media Queries let us target high resolution devices

Understanding how media queries work is essential for serving alternate content on web sites (through CSS) for high resolution screens. Whilst the venerable Dave Hyatt was talking about serving different content to high resolution screens back in 2006, I’ve read lots of material covering the specifics of the issue since. I’d therefore recommend checking out smarter people than me too: Josh Clark, Walt Dickenson to name a couple.

In a nutshell, the super smart W3C people who help bring about and ratify new web standards had the foresight to consider high resolution screens. Therefore, when defining Media Queries, we have the capability to target media based upon device pixel ratio. For example:

@media all and (-webkit-min-device-pixel-ratio : 1.5) {
    .logo a {
        background-image: url('../img/[email protected]');
    }
}

We’ll break that down but first some things to note:

  • It’s important to provide a full vendor-prefix stack to future proof these kind of rules.
  • I’ve named my ‘high-res’ file using the Apple naming convention (adding @2x to the end) – it’s the way it’s done on iOS app development and I’ve adopted the convention here. When designing web sites, it’s just a handy way for me to see which files are high res and which aren’t.
  • As with all media queries, it’s advisable to load/write them after the main styles so that the cascade gives them preferential treatment. If you are using Sass, just use a partial for the media queries and import it at the end of the main style sheet or use Sass 3.2’s ability to inline the media query.

So what’s the media query actually doing? First, we’re telling the user agent (the web browser for all intents and purposes) that we want the rule to apply to ALL media (that’s the ‘@media all’ part). Next, we are stipulating that the rule should apply to all devices with a minimum pixel ratio of 1:1.5 or more – that’s the (-webkit-min-device-pixel-ratio : 1.5) part. Inside we then just stipulate as many CSS rules as we like that should apply to appropriate devices in the normal way.

You can alter this kind of query so that only devices with a pixel ratio of 1:2 are targeted. For example:

@media all and (min-device-pixel-ratio : 2) {
*styles here*
}

In that example, I have omitted the vendor prefix (I mention that just in case you cut and pasted and nothing’s happening). Want a full vendor prefix stack to cover all browsers? Take a look at this associated post showing how to produce a full vendor stack to target different pixel densities. If you want cut and paste goodness, this is as future proof as I know how to write a media query targeted at devices with high pixel density (alter values to suit your need) at the time of writing:

/* This one targets high resolution screens
   ========================================================================== */
@media (min-resolution: 192dpi), (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (-o-min-device-pixel-ratio: 2/1), (min-device-pixel-ratio: 2), (min-resolution: 2dppx) {
  /* your styles here */ 
}

Resizing the background image

In my main rule for that image (the non-media query rule that serves all non-retina displays) I already have a declaration for resizing the background image with CSS3: background-size: contain;. You’ll need something like that or explicitly state the background size. For example, if the non-retina image is 200px by 200px but the high-resolution image is 400px by 400px, you could do this:

.logo a {
    background-image: url('../img/logo2.png');
}

So, the background image for non-retina displays will display at 200px x 200px (assuming the containing element is big enough, otherwise is will be cropped). Then the rule specific for high resolution displays:

@media all and (-webkit-min-device-pixel-ratio : 1.5) {
    .logo a {
        background-image: url('../img/[email protected]');
        background-size: 200px 200px;
    }
}

Here, although the high-res ‘retina’ image is actually 400px x 400px, our background-size: property allows us to define the size it should display at.

Considerations for using high resolution images

Some obvious considerations: bigger images typically take longer to download (more on this shortly however) – it’s a dangerous assumption to make but mobile devices may be accessing your content over a cellular service – bigger images will slow the site down. When an image is double the physical size, the KB size is considerably greater* (*again, more on this shortly). For example, consider that this picture of HRH Queen Elizabeth II is 184KB at standard size (direct link to image at 800 x 584px) and the image double the physical size (direct link to image at 1600 x 1168px) is 694KB. That’s over 3 times as much data. If you do this for all the images on your page, regardless of whether or not users actually have an HD/retina display – the page will be slow for most people, with no discernible increase in quality for them.

Important: Be sure to read the section on the ‘Jobsis’ observation below!

Sadly, there are no CSS rules like this we can implement.

@connection all and (min-speed-1mb) and (max-speed-8mb) {
*styles*
} 

At present, it’s arguably necessary to think long and hard about what high res content you want to use in this way.

Want to show high resolution icons for retina displays? Use a font!

We already know that fonts scale brilliantly. If you need to use an icon in your design, don’t use an image, use a font instead. There are a growing number of ‘Icon Fonts’ available that you can implement into a web page using the @font-face rule. Icomoon.io is my favourite.

Icon fonts on a retina/high-res display are beautifully crisp. It can also scale to whatever size you need. Just amend the CSS to suit. For example:

.icon-font {
    color: #ff9900;
    font-size: 3em;
    letter-spacing: 6px;
}

There are other benefits, namely speed – only 1 http request for a raft of icons. If you’re concerned about semantics and don’t want loads of random letters scattered throughout the markup, another option is using the :before or :after pseudo classes. For example, use markup like this:

<span class="navIcon" data-icon="'"></span>

And then, in the CSS do this:

span.navIcon:before {
    content: attr(data-icon); 
    font-family: icons;
        speak: none;
    font-weight: 400;
    font-size: 3em;
}

As span is essentially meaningless from a semantic point of view, it presents the best of both worlds if the icon in question is purely there for aesthetic reasons.

Can’t get your icon font working on Windows Phone 8? Be aware that although Windows 8 phone supports @font-face it can be a little particular. For best results, I’d recommend creating a data-uri of the font. So instead of linking to the file as a resource, do something like this: src: url('data:application/x-font-woff;charset=utf-8;base64,**DATA-URI-HERE***'), Replacing **DATA-URI-HERE** with the relevant DATA-URI – more info on this here.

Providing alternate high resolution inline images for retina devices

The above media query based solution works fine and dandy for background images but what about standard img tags added in markup? Sadly, at present there is no ‘normal’ way to do this purely through markup. There are JavaScript solutions (such as this one at Flowz) that are relatively simple to implement. There’s also a jQuery Retina Display plugin to replace inline images for high res counterparts (should they exist). Modernizr may also be able to help with this kind of solution in the future. There are some merge requests/info on the Moderniz Github that look like they’ll help in future iterations.

For now, there are three solutions that offer the best workaround (in my humble opinion):

Adaptive images

If you are happy to serve high resolution images to all high resolution screens (regardless of whether the user actually wants to see and wait for the high-res images to load or not), you can use adaptive-images.com. That lets you upload a single high-res image and then automatically serves alternate sized versions for other breakpoints/screen sizes. It works well with CMS systems and doesn’t require any changes to markup. Basically fit and forget. For use with high pixel density devices, you’ll need to use the alternate JavaScript snippet:

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script>

You can also take a look at the Adaptive Images GitHub project here

W3C

The W3C also has a responsive images community working group that is trying to establish a way of inserting alternate media sources into code. This may provide the ability to specify different media for different device ranges directly through markup. In the meantime, you can use the proposed picture element using a polyfill…

Picturefill

Scott Jehl produces some cracking work. His Picturefill is a JavaScript polyfill solution that allows you to write img tag markup similar to the markup pattern used in HTML5 video tags. Add the JavaScript file and then include markup like this:

<div data-picture data-alt="Source changes depending upon the media query style expression(s)">
 <div data-src="normal.jpg"></div>
 <div data-src="high-res.jpg" data-media="(min-resolution: 192dpi),(-webkit-min-device-pixel-ratio: 2),(min--moz-device-pixel-ratio: 2),(-o-min-device-pixel-ratio: 2/1),(min-device-pixel-ratio: 2),(min-resolution: 2dppx)"></div>
 <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
 <noscript><img src="normal.jpg" alt="Source changes depending upon the media query style expression(s)"/></noscript>
 </div>

You’ll see in that example that the syntax for the media query expression to target high pixel density devices is a little different.

If a user doesn’t have JavaScript, they get the ‘Mobile’ version of the image (inside the noscript tag, which should be the same as the smallest one that you set first). The benefit of Picturefill is that it allows different images for different resolutions. By different, I don’t just mean different sizes, you can use a completely different image if you want. The downside is that you need to manually make those images and upload them yourself (unless you have some means to automate the process).

Personally, I like ‘lazy’ solutions so tend to opt for Adaptive Images at present but use cases vary. Neither solution is perfect, they are workarounds for the current shortfall in the tools and systems available so choose your poison.

Despite all the ‘hoo-hah’ (technical term) over ‘Responsive images’ in the web community in the last year or so and plenty of developers ranting at the W3C and associated bodies for not implementing the < ;picture>; element, it just hasn’t excited me much. Although the ability to define different images in different situations with < ;picture>; certainly has it’s uses I don’t see it being widely popular even if it was implemented. It’s just too much work for authors to add a bunch of different images in the markup – even if the CMS is doing the heavy lifting for you. Sure, there will be instances but for the average website, I just don’t see it working out (that said, I thought the iPad was a terrible idea when I saw it so don’t listen to me!).

Use SVG? Responsive/High Resolution Images through markup?

Scalable Vector Graphics will (if support is good enough) work great for some situations. Sadly many tools, other than say Illustrator and Sketch (OS X only, sorry), don’t have decent SVG export options (as an example, Fireworks CS5/CS6 can export SVG with an add-on – but it doesn’t export allow exporting the SVG as outlines so any fonts that are included as part of the graphic don’t export well). Plus SVG won’t help with photos and the like. However for simple vector images, it’s hard to beat in terms of file sizes. For example, I’ve also added an SVG version of my logo for browsers that support it, rather than the higher res PNG – it looks equally good on retina displays. File size is considerably less: the PNG is 33KB, whilst the SVG file is only 4KB – that’s some difference! So to provide a PNG/JPG/GIF fallback graphic with an SVGZ for the user agents that understand, assuming you’re using Modernizr:

.logo a {
    background-image: url('../img/[email protected]');
}
.no-svg .logo a {
    background-image: url('../img/logo2.png');
}

The ‘Jobsis’ observation

Section added October 2012

At present, if you’re working with Fireworks or Photoshop, when you export a picture (a JPG say) you look at the preview window and amend the quality slider. I tend to bring it down until I can perceive the image quality deteriorating and then adjust it back up a little. The threshold differs depending upon the image so it’s not advisable to use the same setting each time (although we all do it!).

Daan Jobsis made an intriguing observation. Remember above when we looked at exporting images at a certain size and then scaling them down? The nub of the ‘Jobsis observation’ is that an image exported at greater size looks just as good when scaled down (e.g. a 400x 400px image scaled to a space 200 x 200px) even when the compression of the image is very high (e.g. that quality slider set to something like 20 in Fireworks/Photoshop). It seems that what’s important for perceived quality is the amount of compressed pixels rather then the quality of the compressed pixels.

I highly recommend you check out the ‘Jobsis observation’ and his follow up post (you may need to translate it from Dutch but Google will do that for you). In the meantime, here’s an initial example of what Jobsis has observed:

Here’s my own little test of Daan’s observation:

Her Majesty exported at 250px x 187px, 100% quality set in Fireworks on export. Size is 42.3KB

Her Majesty exported at 1600px x 1186px (displaying at 250px wide), 80% quality set in Fireworks on export. Size is 186.1KB

Her Majesty exported at 1600px x 1186px (displaying at 250px wide), 34% quality set in Fireworks on export. Size is 30.9KB


Taking it to the logical conclusion…

Her Majesty exported at 1600px x 1186px, 1% quality set in Fireworks on export. Size is 15.8KB

Obviously at this extreme things are starting to look noticeably poorer than the alternative but how about that previous example? 34% quality, full size export looks good to me on retina and is still smaller (in KB) than the native at full quality.

I don’t want to steal Daan’s thunder so go have a look at his post for more on this.

The takeaway for me: at this point, this sounds like a viable technique, export a graphic once and have it look good across multiple screen densities. It needs using in anger far more but at this point I’m loving the simplicity of this technique.

One big caveat to this technique though is that if the scaled image is intended to downloaded for use locally (or at native size for any reason) it will likely look like a dog’s dinner.

Testing different devices

Previously, testing multiple devices required, well… multiple devices. There’s still no substitute for that. But, if, like me, you work with responsive designs most of the time, it’s a bit of a chore to test iterations: pressing refresh on 3 or more devices to see what the latest tweaks did. I’d looked at Weinre but never actually set it up. Thankfully, Adobe Labs have released a GUI version of the system called ‘Adobe Edge’. It enables your devices to remain in sync so that when you refresh the browser on one device, it automatically refreshes the page on the other devices too. Furthermore, it enables Firebug/Developer tools style debugging so you can see if the high resolution images are actually working or not.

Your feedback welcomed

I’m hoping this ‘whistle-stop tour’ of providing high resolution images for retina displays was informative. However, I welcome feedback, queries and corrections in the hope of improving this piece in any way.

About The Author

40 Responses to “How to serve high-resolution website images for retina displays (new iPad/iPhone4+)”

  1. Sebastien Gignoux

    I am trying to find how widespread responsive design is for web designer, do you know of any survey or polls?

    Since I haven’t found anything I am trying to do my own poll. You can access it here: http://responsive.wufoo.com/forms/z7x3x5/ and the results are here: https://responsive.wufoo.com/reports/z5p8q2/

    If you could spread the word with a twit or something, that would be great. I think the results will interest everybody in the web design community.

    Thanks in advance for any help

  2. Ben Frain

    Done and done. Little thing – can you make the results link actually a link in the Wufoo form (just saves copying and pasting into the url bar).

  3. Ralph

    Great article. It’s very useful info and I would like to share it, but you don’t make that easy for me. :)

  4. Falco

    Thank you for this article.
    I know little about code but I can understand the principle that you describe above: that based on the platform, a different image will be retrieved.

    My newbie question coming from someone who runs a wordpress blog is:

    Couldn’t I get around this problem on the short-term by using double-sized images resized to my post-width? So if my post-width is 720, I just force a 720px width on a 1440+px? I know it makes the page take longer to load, but at least retina iPad users will be well served.

    Thank you for your help!

  5. Ben Frain

    Hi Falco,

    I just updated the post with this additional info but in case you are just subscribed to the comments…

    Yes, that would work but the problem you have already noted is an important one. When an image is double the physical size, the KB size is considerably greater. For example, consider this page The picture of the HRH Queen Elizabeth II is 184KB at standard size (direct link to image at 800 x 584px) and the image double the physical size (direct link to image at 1600 x 1168px) is 694KB. That’s over 3 times as much data. If you do this for all the images on your page, regardless of whether or not users actually have an HD/retina display – the page will be slow for most people, with no discernible increase in quality for them. If that’s OK for you, then yes, it should work but page speed is a very important factor, for how much people will enjoy your site – probably more important that HD images in my opinion!

    That’s part of the reason I went with the ‘HD toggle’ method on this site – I wanted a way for users to select so they only get what they want or need.

    Did that help?

  6. Falco

    Hi Ben, thanks for your quick answer!
    That definitely clears it up for me, yes.

    First, I think your coded solution is great for a always-present image, like a logo or even for a portfolio, but it’s still pretty impractical for CMS-based publishing projects where your focus should be on putting out interesting material for your readers (not recoding every image link). An agile programmer will likely soon come out with a WordPress plugin (I couldn’t find any in a quick search) and maybe the next version will even feature it baked-in.

    However, in my situation the solution above could still be valid one:

    1. My blog is very heavy on photos and right now the front page is setup to display 6 posts (with an average of 6 photos per post). I am currently in the midst of a theme redesign which will require readers to see each post individually, opening them from a front-page of thumbnails and excerpts. Therefore, I can probably include larger images and still have significantly shorter load times than I currently have.

    2. Because my redesign will force me to re-attach and upload pictures across the majority of my posts, it would be practical to permanently upload a high-res image, even if it will also make the photos easier to steal. I figure that any future plugin or CMS feature will need a large image to start with before downscaling to 72dpi screens and anything sub-retina.

    What do you think?
    Thanks again for opening the topic.

  7. Ben Frain

    Falco, in that case, possible yes. Your users are clicking on a thumbnail and expecting to see a higher res version of the thumbnail so the expectation/delivery equation could be acceptable. If the high-res images are just loading on every page regardless, that would be a problem.

    However, in your situation I think http://adaptive-images.com could help. It’s a one time install and the documentation is good. It works well with CMS systems too. You basically just upload your large image and then that automatically provides other sized versions depending upon the breakpoints you specify. It can also be configured to work with Retina displays too.

    Have you looked at that yet?

  8. Falco

    Adaptive-images fits the bill pretty well.

    I also found that this guy Jorgen Scott has embedded AI within a WordPress plugin and it seems like he is doing a good job of keeping it updated: http://wpresolutions.co/

    My only issue now is if I want to offer up photographs at 1500+px without a watermark.
    Thank you for your advice.

  9. Jay Mathes

    This is seriously the post I’ve been searching for since the new iPad was announced! Happy to finally find what I’ve been looking for!

  10. Danny Englander

    I have a few questions in regard to this.

    1) I don’t understand using a background image as a logo. I was always under the presumption that a logo should be an image as in “img src=”” etc.. and not a background image in order to be semantically correct.

    2) When you say high resolution, do you mean a higher DPI than 72 or simply just a larger size @ 72DPI? (It sounds like you mean the latter but I wanted to clarify).

    Thanks.

  11. Ben Frain

    Hi Danny,

    Easiest thing to do is look how I’ve done my logo here: I just created a div with a class of ‘logo’ – so semantically, it should be easy enough to understand what the div is for. Furthermore, it’s within the header section which has a WAI-ARIA landmark role of “banner” so even screen readers should expect a logo here (if it’s going to be anywhere).

    Regarding DPI (which is a debate all in itself) – I’m not sure if you/I are confusing terminology and the following isn’t meant to sound condescending in any way… For example, imagine 2 images exported at 72dpi from Photoshop, one is 100px x 100px in size and the other is 200px x 200px in size. If I am displaying each of them constrained within a 100px by 100px space, the second image effectively has greater ‘DPI’. That’s a crude example but hopefully explains the technique? It’s easier to forget terminology like DPI as it’s more applicable to print and think in terms of PPI (Pixels Per Inch) instead. I just dug a bit of text out for an article I did recently, it may help:

    DPI and PPI are often used interchangeably to describe resolution but their suitability to do so varies by application. DPI (Dots Per Inch) is a measurement chiefly relevant to print. The greater the DPI of a printer, the more dots of ink are used within each inch of printed material. More dots typically results in a greater tonal subtlety between changes in the image. To exemplify, a magazine might use images specified at 300 DPI whilst a web site, until recently, might only require the same image at an equivalent of 72 DPI. This is because, until high-resolution screens, prints’ resolution capability has always greatly exceeded a comparatively sized screen. Therefore, printed material has always provided a preferable reading and viewing experience.
    However, when dealing with devices, PPI (Pixels Per Inch) is a far more useful way to measure and compare resolution. It’s simply the amount of pixel columns a screen has within an inch of its display. The PPI of common handheld consumer devices varies: a Samsung Galaxy II is 217 PPI, an iPhone 4 is 330 PPI whilst the latest iPad is 264 PPI. A 15.4” 2011 MacBook Pro laptop on the other hand is just 110 PPI. The greater the PPI of a device, the greater the resolution and all other things being equal, the better the viewing experience is likely to be.

  12. Danny Englander

    Hey Ben, perfect, thanks for clarifying all this. I am working on a Drupal site and we have a request to make the logo look better on an iPad 3. It will be interesting to try to make this method work within the framework of the Omega Theme but I think it should be possible. I am not sure yet if we will do this but I’ll take all this into consideration. Thanks again!

  13. Pieter brink

    Reading this article on iPad 3, and your site site images looks nice and crispy! Thanks for the great article Ben – can’t wait to start playing this script on our site!!!

  14. Ben Frain

    Hi Pieter,

    Thanks so much for that. It’s great to know when people have found it useful.

    All the best, Ben

  15. Mauricio Poveda

    Just an excellent Article Ben. A lot of things more clear now.

  16. Peter

    An excellent article but I have an issue with all of the proposed techniques for serving high resolution images.

    The iPhone 4 is a retina display but because of it’s screen size there’s no need to serve high-resolution images because they’re scaled-down anyways.

    To serve high-resolution images on the iPhone 4 is wasteful because it uses bandwidth needlessly.

    When using the newer MacBook Pro’s retina display or the iPad 3s display, serving @2x images makes total sense but not for smaller displays like the iPhone 4.

    I’d like to find a way to exclude the iPhone 4′s or any smaller retina screens from being served these high-resolution images.

    Anyone have any ideas?

  17. Ben Frain

    Hi Peter,

    In understand your sentiment but it’s perhaps a little short sighted. The whole point of picture fill and adaptive images described above is to only serve users the images they need, starting with a ‘mobile first’ mindset (e.g. the smallest image is the default). Those two solutions can actually do what you are describing (and indeed is their primary reason for being – only serving devices what they need). If done properly the iPhone 4 needn’t automatically get high-res version.

    Further than that, if you make use of icon fonts and SVG where possible it’s only actual images that require special attention. I’d hesitate to make assumptions that users neither want nor need retina images based on your own (or indeed anyones) individual whim. Much better to give the user the choice, no?

    However, to answer your question directly, for background images handled in CSS you could easily achieve this by writing a media query that targets devices of a certain pixel density and a certain device width.

    Best, Ben

  18. Leena

    Thanks for great article!

    I’m wondering could this somehow solve the problem of high quality printing as well. Say, I have a site which should look great in low and high res devices AND in print (quite possible scenario, in fact). The same images could be served for retina devices and printers. Do you have any thoughts on that? Media query for print of course works for background images but what about img tags?

  19. Ben Frain

    Hi Leena, interesting thought. My initial thought: not tested it but as the picturefill polyfill effectively uses uses media queries, it may well let you specify particular images if the type is print (by using a print based media query). Give that a whirl and be sure to let us all know if it does!

  20. Leena

    Thanks for your quick answer! I’ll check it out and let you know.

  21. Stuart

    Awesome article! – this is one of the best written and most comprehensive articles on this subject that I have read so far. It acts a great overview to get the concept across, and allows you to form your own opinion about what is right for your situation. Nice one – keep up the good work.

  22. @quickredfox

    If this were on stackoverflow, it would definitely be the best answer for “How do you serve high-resolution website images for retina displays”. Covers wide enough ground for an experienced web developer to comfortably jump into this and explains well enough that newbies following this should have no problem looking like pros.

  23. Nuno

    Hi Ben Frain,
    Thanks for the excellent article.
    However, I wonder if it wouldn’t be better instead having one single website with all the adjustments, having three or four different version when each one is set to a single purpose. I mean, a version for smartphone, another for ipad, desktop, etc.? That solution, certainly will be faster to read and all the work will be around the htaccess to redirect from the main site to the appropriate version.
    What do you think about?

  24. Tendencias en Diseño Web en 2013

    [...] similares e incluso superiores haciendo que los diseñadores concentren sus esfuerzos en crear imágenes para hiperresoluciones, como comenta Ben Frain. Esto tiene algo de cierto; sin embargo, a mayor resolución más pesada [...]

  25. static-article | Bppl Cloud

    [...] An important fact here is that image responsiveness has been focused on size, on looking nice in every device. Now with the appearance of HiDPI devices (carrying the ‘Retina’ moniker on Apple HiDPI products), the obvious result is that competitors attempt to create similar or better technologies and many designers may start thinking that the paradigm should focus, as Ben Frain tells us, on hyper high resolution imaging. [...]

  26. Makis Tracend

    I just had to research this subject again to get the latest info and surprisingly this article offers still one of the best overviews :)

    Personally, we use icon fonts for all website icons and for background images the at2x Less helper (https://github.com/imulus/retinajs/blob/master/src/retina.less)

    For inline images we didn’t have a solution, but now I created this Handlebars helper that we can use both on client and server:
    https://gist.github.com/tracend/5380987

    Cheers

  27. Ugh... NO!

    Can you detect whether that retina device is on fast wifi or slow 3G?

    No? Then don’t be a jerk.

    Sending bigger images across what may be very slow connections is stupid (3G feels like 1990′s modem speed half the time), plus it’s expensive for people with limited data plans.

  28. Ben Frain

    It could also be argued that just because you’re on a 3G connection doesn’t mean you don’t want a retina image either ;) I have plenty of data on my plan so I’d be happy to see retina images – I don’t want a crummy asset just because I’m browsing on 3G. That assumption is as dangerous as assuming people do want a huge jpeg just because they have a HiDPI device.

    However, the whole point of this post is to provide options for serving hi-res images/assets. Many of these (icon fonts/svgs) are smaller than legacy techniques (double size 2x pngs) and give better results anyway. They are win-win techniques. Others such as adpative images, srcset, picture element, SVG clown car technique (need to add the info on that) should be used far more cautiously depending upon what you want to achieve.

    However, the whole point of these techniques is to provide more appropriate assets in different situations depending on what authors need to achieve so I don’t agree with your sentiment I’m afraid.

  29. iLen

    Hi, good article. I mention that I’m learning this for ‘Retina Ready’ and what I have I realize that is just a picture to increase by 200% and save as [email protected] with this as it would be enough to image the retina. Additional downloading a ‘retinajs.js’ to support the entire site to work with retina. I think this would be enough.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

409Days
409 days since this post was last revised. Specific details are likely out of date.
3045 words
MENU