Load times & responsive images

Tuesday, June 28th, 2011 at 9:21

Does a responsive design loaded at 320px load the assets for the desktop version? Unfortunately it does. Every background image specified in your CSS for higher resolutions is loaded (see comments); every element that you hid with display: none; too.

Some think loading the site at 320px effectively prevents the CSS rules for 960px to execute. This is a common misconception about media queries usage. If your visitors are on a slow mobile connection, your site will load as slow as the desktop version does, even if it’s a responsive design.

City Crawlers Berlin kills that big image carousel at the top by using display:none, serving 1.8 MB of invisible images to mobile users. Crazy. A Different Design does the same thing with their content. This is easy to implement, but ultimately not a solution. Many other responsive sites display full res images to the desktop, only to squeeze them down on the client side when displayed on mobile.

The post that triggered writing this was Aaron’s post (quoted above) and some discussions I had at Fronteers. This is not a plea against responsive design — in fact, I’m all for it — but merely me trying to raise the general knowledge about when to choose for a separate mobile website and when a responsive design is sufficient.

One possible solution is to have the assets in different sizes, grabbing the viewport width with Javascript and then loading correctly sized images. Scott Jehl (of respond.js fame) wrote about his responsive images code in this post. I haven’t played with this yet: the chances that the content of a website I make stays the same are pretty close to zero.

Alternatively, a simpler technique would be to not load certain content by default but adding it to the desktop versions through Javascript (e.g. loading that bigass background with an AJAX call after checking the viewport width). However, this brings up the discussion how much the websites can differ from each other: if we’re talking purely about a decorative background image it’s okay; but a slideshow on the homepage? That’s content.

If you’re interested in responsive webdesign, check out the presentation I gave saturday at Barcamp Ghent 4: back to the lab again (in Dutch).

6 comments to “Load times & responsive images”

  • > Every background image specified in your CSS for higher resolutions is loaded; every element that you hid with display: none; too.

    I’ve tested this myself and I’ve found that that assets specified as background images within a media query block are only downloaded if the media query matches.

  • I tested it with Firebug and http://nerd.vasilis.nl/adaptive/zengarden.html and you are correct, sir. I will strike through part of the original post. Thank you.

  • Been thinking about this myself too. There’s several possible (future) solutions:
    - Using Javascript to load the appropriate assets – either directly as Scott Jehl demonstrated or via cookies. Clever, but still somewhat cumbersome and depending on JS.
    - Some kind of CSS property/HTML attribute to defer loading of assets. Would be cool but since it doesn’t exist yet, it would take years.
    - A new sort of container format for bitmap images that would allow the browser to download the best matching size. Not gonna happen (at least not soon).
    - Broader support for (compressed) SVG. Personally I look forward to using SVG more. With all current browsers supporting SVG, I think it’s the way to go for all vector based source material.
    - …?

    @chas s Do you have this test online somewhere?

  • For sleepstreet.be we used the responsive images code from Scott Jehl. I found it to be very robust and will most likely use it in my next projects as well.

    As for SVG, I used it for the sleepstreet.be logo. It was honestly a pain in the ass to implement.

  • I once tried to implement the Wolf’s Little Store logo as SVG but that didn’t work out so well. It’s a bit complicated and the Illustrator export code is a mess.

  • Maybe it’s new in Illustrator CS5, but I have a simple SVG option in the Save For Web dialog, that works pretty much out of the box.

Comments are closed: It's not possible anymore to comment to this post. After publication you can comment for 2 weeks. If you still want to comment personally, find my contact details at the contact page or send me an e-mail.