Bandwidth media queries

Back in March 2012, Chris Coyier opined that, in addition to other @media queries, what we really needed was bandwidth media queries.

But is screen width the correct metric to use here? Perhaps it is, why would a screen that is 400px wide ever need an image that is larger than 400px wide? Well I think the retina display on certain new devices are answering that question for us. Those devices may respond to certain width media query but really have twice the pixels available and be able to show much sharper images. Yes, we have device-pixel-ratio media queries for that as well, but I still think we’re dancing around the issue.

That issue is: bandwidth. If I’m in a place / on a device that has super slow internet, I’d love to be served a very light web page so browsing is still acceptably fast. If I’m in a place / on a device that has super fast internet, by all means ratchet it up and deliver me more.

This doesn’t mean ignore screen size. That’s obviously relevant when it comes to layout. This extension of media queries would give us a more appropriate tool for media in a world where the size of your device is increasingly unrelated to its bandwidth.

So I wonder: is it possible?

The short answer, as provided by Yoav Weiss writing at Smashing Magazine and interpreted by your humble Devil, is “no, it’s not; and it is not desirable in any case. And even were measuring bandwidth desirable, bandwidth media queries would be entirely the wrong way to approach it”.

The reasons are many-fold, but they start with the fact that not only is effective bandwidth is incredibly difficult to measure but also that, even on a relatively stable connection, the TCP protocol is designed so that bandwidth actually changes all of the time.

And that is without including mobile users, whose rated bandwidth might change as they move between broadcast cells.

TCP is the dominant protocol for the reliable transfer of data on the Internet. The protocol itself has a certain overhead that results in a difference between the theoretical and the effective bandwidth. But another factor is responsible for an even more significant gap between the two. TCP doesn’t always use all of the bandwidth available to it, simply because it doesn’t know the bandwidth’s size.

Sending more data than the available bandwidth can cause network congestion, which has disastrous implications on the network. Therefore, TCP uses a couple of congestion control mechanisms: slow-start and congestion avoidance.

Each TCP connection is created with a very limited bandwidth “allowance,” called a congestion window. The congestion window grows exponentially over time, until the TCP connection sends enough data to “fill the pipe.” That is the slow-start phase, which can take up to several seconds, depending on the network’s delay. Then, TCP periodically tries to send just a little more, to see if it can increase the amount of data it sends without causing congestion. That is the congestion-avoidance phase.

Both of these mechanisms assume that packet loss is always caused by congestion; so, packet loss results in a significant reduction to the congestion window, as well as to the rate at which data is sent. On wireless and mobile networks, this behavior is not always ideal because they can suffer from packet loss for reasons other than congestion (for example, poor reception), which can result in under-utilization of the network.

So, bandwidth, by its very nature—by its very design—is variable over time. But even if the browser could accurately measure the effective bandwidth at any one moment, bandwidth media queries are precisely the wrong way to implement any tests.

As far as the browser is concerned, a media query is a direct order with which the browser must comply. It has no room for optimizations. It cannot avoid obeying it, even when it makes absolutely no sense. Let’s explore what that means for bandwidth media queries.

Let’s assume for a minute that browsers actually do have an accurate way to measure the current bandwidth and that a solution for responsive images is in place and can use a bandwidth media query.

The natural thing to do, then, would be to define a responsive image with multiple sources— a high-resolution image to use when the bandwidth exceeds a certain value, and a low-resolution image when the bandwidth is low. The browser loading the page that contains the image would then download the high-resolution image, since it has good bandwidth conditions.

Let’s say that, after a few seconds, the bandwidth conditions change for some reason. The browser (sharp at detecting bandwidth as it is) will immediately detect that the bandwidth is down. The browser is now obligated to download the lower-resolution image and replace the high-resolution one with it. The result is a useless download of the low-resolution image and a worse user experience, because the quality of the image that the user sees is worse than it could be. Even if this happens to only a low percentage of users, that’s bad news.

Now, you could argue that the browser could optimize and use the version it already has. But the fact of the matter is, it can’t; not with media queries — at least not without changing the whole meaning of them.

So, the quick answer to Chris’s question is: no, bandwidth media queries are not possible. And even if such measurements could be implemented reliably, media queries would be the entirely the wrong way to go about making web pages responsive to bandwidth anyway.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">