The Responsive Images Saga

View Github Repository Open presentation in a new window

yoavweiss

See all presentation from yoavweiss

The Responsive Images Saga

0 0

respimg-edge-presentation

A 10 minutes presentation given at EDGE NYC September 2013

On Github yoavweiss / respimg-edge-presentation

The Responsive Images Saga

Yoav Weiss

Edge - NYC, September 2013

yoavweiss.github.io/respimg-edge-presentation

I'm here to talk a little about responsive images. I have to squeeze in over 2 years of discussions into a 10 minutes presentation, so I'm gonna give it a try :)

In the begining - mobile only sites

Mid 2000s, mobile only sites. Very light weight.

iPhone, slightly more content, but still mobile-only

Then - RWD happened

RWD became a thing

One code base to rule them all

Awesome

Followed by BLOAT!!!

Mobile experience became better, but slower

WHY???

72% Serve same resources

guypo.com

Serving the same resources to mobile and desktop hurts performance

On mobile the images are much smaller and some of them are not even displayed

Which resources?

Images - over 60%

httparchive.org

How much can be saved?

Up to™ 72% image data savings

tkadlec.com A small utility I cooked up and Tim Kadlec wrote about showed 72% data savings

Retina only increases these gaps

Devs can choose between HQ and LQ for everybody

Usually pick HQ

Responsive Images Problem

2 major use cases

Resolution switching

Serving different image dimensions to different devices

Image resources only differ in quality. proportions stay the same

DPR switching

Sending retina images only to retina screens

viewport switching

Sending images adapted to their display dimensions For both res switching, browser should be able to serve lower res resources

Art Direction

Getting images to match layout

Fit layout and optimal content without wasting bytes

40% of devs want art direction

Proposed (standard) Solutions

  • srcset attribute
  • <picture> element
  • Client-Hints header
  • Responsive Image Container ???
We've covered the problem. Now let's move to the solutions.

srcset

  • Extends <img> to include multiple resources
  • Addresses mainly resolution switching

The good old img tag, now with extra attributes!!!

Mainly res-switch, because browser can override

Browser can override means "browser can optimize"

Current implementation

DPR switching only

    <img src="cat.1X.jpg"
         srcset="cat.1x.jpg 1x,
                 cat.2x.jpg 2x">

Implemented in WebKit and Blink

Firefox will soon follow

Future implementation

Viewport switching as well

    <img src="cat.1X.jpg"
         srcset="cat.1x.jpg 1x 320w,
                 cat.2x.jpg 2x 320w,
                 cat.2x.jpg 1x 640w,
                 cat.4x.jpg 2x 640w,
                 cat 4x.jpg 1x 1280w">

I have a feeling the viewport switching implementation is not far behind.

"I have a feeling" == "I intend to implement it"

<picture>

  • Targeted at art-direction
  • Specifies resources using <source> and MQs
  • First matching resource downloaded and displayed

Art direction using picture

<picture>
    <source media="screen and (min-width:1600px)"
            srcset="wide1x.jpg 1x, 
                    wide2x.jpg 2x"> 
    <source media="screen and (min-width:800px)"
            srcset="middle1x.jpg 1x, 
                    middle2x.jpg 2x"> 
    <source media="screen and (min-width:400px)"
            srcset="narrow1x.jpg 1x, 
                    narrow2x.jpg 2x"> 
    <source srcset="tiny1x.jpg 1x, 
                    tiny2x.jpg 2x"> 
    <img src="fallback.jpg">
</picture>

Client Hints

  • HTTP based content-negotiation solution
  • Client sends hints/capabilities
  • Server side logic decides on resource

Proposed request headers

    CH-DPR: 2.0
    CH-VW: 2.0
    CH-VH: 2.0
    CH-OtherVar: x.x

Opt-in only

Not sent on first HTML request

Responsive Image Container

  • File format approach
  • A "layer" per resolution
  • Both resolution switching and art-direction

Resolution switching

336x635

Is split into

106x200

211x400

336x635

Art-direction

770x512

Is split into

200x200

400x288

770x512

Advantages

  • Markup left untouched
  • A single file per image
  • Better for post-download dimensions changes

No markup

single file

can download diff

disadvantages

  • Touches many layers. Will take time
  • Decoding performance???
  • Fetching mechanism network performance???

complicated

decoding perf?

Fetching mechanism

Oh... One more thing

Progressive image download

Questions?

Thanks!

Attribution

RWD - http://www.flickr.com/photos/axbom/6263640150/sizes/o/in/photostream/

Bloat - http://www.flickr.com/photos/lorenjavier/5013332959/sizes/l/in/photostream/

CNN - http://mobile.smashingmagazine.com/2010/11/03/how-to-build-a-mobile-website/