Lots has happened in the world of Responsive Images since I wrote Mo’ Pixels, Mo’ Problems. And by lots, I mean nothing at all. It’s been over a year since The Great WHATWG Responsive Image Debacle and we’re still at square one.

Browsers want to implement srcset because “it’s easy”, but lots of developers (myself included) would feel great about using <picture> because it looks like every other new media syntax (audio & video) as well as a plethora of other reasons too. There have been a few more creative hacks (Compressive Images, Clown Car, etc) but no gold standard has arisen.

Here are some other developments you should care about:

So, as if the world of image formats and performance wasn’t complex enough, here’s some additional things I’ve been mulling on…

Are @1x images for “mobile” even a thing anymore?

I’m starting to believe that @1x for “mobile” screens might be a thing of the past. Using the handy screensiz.es, I’ll explain my thinking:

  • 92.8% of all “mobile” screens are @1.5x or higher.
  • That’s a lowest common denominator of 480px (320px * 1.5).
  • The Galaxy S is 480px wide, @1.5x the size of a non-retina iPhone.
  • Only non-retina iPhones (3.2% of devices) would receive the wrong image size.

To me @1.5x (I dunno, 480px?) baseline for “mobile” images seems like a reasonable average. Unfortunately, tiny devices with expensive screens are at odds with their low bandwidth.

Choosing image breakpoints is still difficult.

Jason Grigsby has some thoughtful posts on choosing breakpoints by jumps in filesize, but the answer is usually “depends on your situation”.

I’ve been mulling the idea that 512px, 1024px, 2048px, (and 3072px?) are a convenient baseline. This methodology, though a bit random, seems to suit my no-@1x theories as well as my need for simplicity:

  • Base2 numbers, but not device specific.
  • Suited for @2x situations, but not device specific.
  • Reflect common device widths, but not device specific.
  • I love reducing complexity in my job, this couldn’t be easier.

Alas, like most developers, I get too stressed out about all the options and breakpoints and end up not committing to anything.

The rent is too damn high.

I gave a talk on “Mo’ Pixels, Mo’ Problems” at Artifact Conf. I enjoyed giving the talk, but I think it’s crazy that “Images on Websites” is a topic anyone can talk about for over an hour. It’s mind-boggling.

The problem is so damn complex, it’s no wonder people are throwing in the towel on images, but for me it keeps coming down to one core thing. According to Paul Irish’s talk at Breaking Development, the Mobile Web is in trouble:

“There’s a common perception that mobile Web experiences are inferior to native mobile experiences. Many companies are building native experiences instead of Web experiences.” – Paul Irish transcribed by LukeW

If the web cannot keep pace with a native experience in speed (rendering in under 1000ms), we’re all going to be out of the job. An uptick in native app usage means budget dollars would follow the trend and be poured into native apps. Meanwhile public facing websites will be left to rot because no one cared and we littered the web with bullshit. Native wins, the web dies, Zeldman hangs up his beanie, and Sir Tim Berners-Lee cries a single tear. That’s not the future I desire. I want an open, accessible, usable, free web available to anyone no matter the creed of their device.

Find the lowest hanging fruit.

Images are probably the fattest, lowest hanging fruit, so yeah… don’t give up. Do something, anything! Try to shave off 500ms and increase revenue 20%. Make your client rich. Sell them the fastest website ever. Crack open Developer Tools and test rigorously. Find weaknesses.

And, for the love of god, please test your website/project/app on an actual mobile device. In the year 2013, it’s incredible that so many people skip this step.

  1. Source: http://httparchive.org ↩