Sirens

January 13, 2012 —

There seems to be a widely held belief that using media queries to overwrite css properties results in compounding load times (in the case of replacement assets being declared) or unnecessary load times (in the case of display properties being set to none). More likely it’s simply an uncertainty that, lacking time or reason, few have bothered to test themselves. That uncertainty gives rise to arguments against using responsive web design to handle mobile experience due to bandwidth concerns.

I’ve never found this to be the case.

In fact, the manner in which mobile browsers handle assets is one of the reasons I think responsive web design is so practical. Designing for smaller viewports typically has the added benefit of lightening page load rather than the reverse. Don’t take my word on it, though. Not yet.

It typically takes specific project requirements to get me to set up test cases, so my testing has focused heavily on iOS devices. Over time I’ve tested on iPhone 3, 3g, and 4, iPod Touch Gen 2, 3 and 4, iPad 1 and 2, and a token Nexus One. I realize that leaves the behavior of a lot of browsers in question. Caveat emptor.

Last night, I recreated the test scenarios detailed below using Mobile Safari 5 on an iPhone 4 and Mobile Safari 3.1 on an iPod Touch. I mentioned that I’ve tested on a number of devices/browsers, but given the rate of change in mobile browsers, please do not extrapolate beyond these two browsers.

Test 1

A background image is declared in css, but the parent’s element is set to display:none inside a simple media query targeting an iPhone.


.sidebar div {
  background:url(/img/huge.png);
}

@media only screen and (max-device-width: 480px) {
  .sidebar {
    display:none;
  }
}

In this case, the browser recognizes the display property and does not request/download /img/huge.png. As you’d hope.

Test 2

A background image is declared in css but then overwritten inside a simple media query targeting an iPhone.


.sidebar div {
  background:url(/img/huge.png);
}

@media only screen and (max-device-width: 480px) {
  .sidebar div {
    background:url(/img/small.png);
  }
}

In this case, the browser requests /img/small.png but not /img/huge.png. As you’d hope. UPDATE: Mobile Safari 4 may have had a bug causing both files to be downloaded (as you would not hope). I’ll add some test devices for follow up testing.

Test 3

A hybrid of Test 1 and 2 except we want a background-image to appear on orientation change.


.sidebar div {
  background:url(/img/huge.png);
}

@media only screen and (max-device-width: 480px) {
  .sidebar {
    display:none
  }
}

@media only screen and (max-device-width: 480px) and (orientation: landscape) {
  .sidebar {
    display:block;
    }
    .sidebar div {
      background:url(/img/small.png);
    }
}

In this case, the browser does not request /img/small.png unless you start in or change to landscape orientation. As you’d hope.

In short, mobile browsers are smart. The results you’ll encounter will tend to make sense.

It’s worth noting that the behavior noted above does not cover images requested via tags. If your plan was simply to hide those banner images on smaller devices, you’re going to need a better solution. Those assets are still going to be served.

UPDATE: I also need to be clear that the first test case Test 1 only works if the parent element is set to display:none. Setting the element itself to display:none will not work. The example code I used when writing this post was slightly different than my actual test files and may have been misleading.

If I was only allowed to make one point, it would be this: don’t believe any test a person uses to support a claim for or against a development practice until you’ve performed it yourself. I personally consider responsive web design to be an extremely practical way to improve mobile interface without sacrificing experience due to load time. Each of you can perform your own tests.

8 Responses to “Sirens”

  1. Jason Grigsby

    A few random thoughts:

    * Results of tests change over time as browsers change. CSS asset downloading was considered a bug by the webkit developers and addressed. See https://github.com/h5bp/html5-boilerplate/issues/816#issuecomment-2500648 and https://bugs.webkit.org/show_bug.cgi?id=24223. So the tests I ran in August of 2010 will differ substantially from ones run in January 2012.

    * Some percentage of devices will continue to use older rendering engines for some time. This is a major advantage of starting with mobile styles first and overriding them for desktop. Desktop browsers are easy to account for than the variety of mobile devices and if something goes wrong, the desktop will simply get the small page versus a mobile user getting the full desktop page

    * When testing mobile, you really need to do what Aaron did–watch the server logs–or run a proxy server to get true results. Blaze.io’s mobile test is great, but it suffers from problems related to the reported viewport width on Android. YSlow finally works on mobile via a bookmarklet, but invoking it changes the page width and causes assets to download. This is why I love Charles Proxy and hate the fact Android doesn’t have good proxy server support.

    * The primary issue is with people building bloated web pages regardless of the device. Unfortunately, it has been my experience that web developers will look for any excuse they can find to avoid doing the performance work. I don’t understand why, but I’ve seen the behavior for years now. To my mind, focusing on bad performance on mobile is a tactic to get people to pay attention to performance overall. It is much harder to dismiss a bloated page on a mobile than it is to do so on a desktop experience.

  2. Aaron Mentele

    Hey Jason. Thanks for comments. I saw Paul’s note regarding that bug in WebKit as well, but I never encountered it using Mobile Safari. Regardless, I definitely agree about tests from 2010 potentially yielding different results. Browsers change. We all need to continue to test.

  3. Keyamoon

    Very good to know about your test results. So image tags always send their request? Even if their parent elements are set to display: none? That would be disappointing.

  4. Aaron Mentele

    @Keyamoon – yes. As of today, assets requested in [img] tags are being served even if their parent is hidden with display:none. I’m told the behavior is different in Opera Mobile (it’s handled the way you’d like it to be), but I haven’t confirmed.

  5. Sirens | Aaron Mentele » Web Design

    [...] Sirens | Aaron Mentele [...]

  6. Sebastian Green

    Great tests. I think once the browsers are a few more versions along hopefully they will be able to make simple decisions in terms of not downloading files if not needed.

  7. Web Design Weekly #27 | Web Design Weekly

    [...] Overwriting CSS properties doesn’t result in compounding or unnecessary load times. (aaronmentele.com) [...]

  8. return man 2

    Nice share, thanks.
    return man 2 http://returnman2.blogspot.com/