RE: Bandwidth Media Queries

Florian Eckerstorfer:

First of all, JavaScript is not really a solution for serving different image sizes. Any solution that I currently know of needs at to download at least the smallest version in addition to the appropriate image. A very clever solution which nearly worked is described by Mat Marquis.

As far as I know „Adaptive Images“ serves only one image and is therefore the best solution at the moment. I will try it myself in the near future but couldn’t get around to it, yet.

My problem with bandwidth detection is that it will never be really accurate. In its simplest case the browser would just send the speed of the network the user is currently on. However, I can be on 3G but since I am also currently updating a dozen of iPhone Apps, I don’t really can surf using 3G speed. If the browser wants to detect the real bandwidth I currently have, it would need to download some Megabytes and measure how long it takes.

I would be perfectly happy if I could easily detect if the user is on a mobile network or on wifi. The point for me is not so much to serve a small image if the user has little bandwith left for browsing. I want to serve small images to mobile devices if they are not on wifi so my site doesn’t mess with their data limit.
So I could show a small image on an iPad 3 which is on LTE, but a big double sized image on an iPad which is on wifi.

But I can not see how this is ever going to happen. There is now way a browser can detect it. The solution in my opinion has to be on the other side. The device should send some information which the browser then could detect. Or something like that.

All that could be solved if we had super duper fast internet connection everywhere we go. So no one had to worry. Maybe out grand children can have this luxury.


  1. Adaptive Images requires Cookies to work. It is basically the same technique used in the article I linked from ALA. If the browser supports pre-fetching of images (which is currently becoming popular) this approach will fail. The problems are described pretty good in the ALA article.

    Since I’m an Austrian I’m not really concerned with saving bandwidth. I even synchronize Spotify over 3G. However, I believe that it is not really the job of the web developer to help the user save bandwidth. If you want to cover all possible scenarios, you would have to create 10 or so versions of each image. That seems a bit like an overkill to me.

    1. Gotta agree with Florian. Even if I’m running a mobile device I’d like to at least choose if I can have the higher quality version of an image/movie/flash/whatever on a mobile device. On the other side I’m also always glad if a website is detecting a mobile browser and offering me an optimized, mobile version of the site. Including an option to switch to the original version. Cool with that. Like Florian said, developers shouldn’t care about available bandwidth a user has at the moment the page loads. Just check the bitsize of code, layout material, picture compression to keep the footprint as small as possible. As long as you can account it for the quality you want to achieve. Anyways. At the end half of the users is complaining about the low quality they get cause your site detected a low bandwidth. And the other half is complaining about your website taking so long to load and producing high volume on their 200MB student mobile data contracts. Let users keep some amount of self-responsibility about their data plans and what websites they visit with it.

    1. YouTube displays you the speed you had on previous visits. If you visit YouTube for the first time it will not show you any statistics. Even if your users visit your site regularly it is not easily possible to detect their bandwidth. If you don’t serve large content (like videos) it is not easily possible to detect their speed. You need a file at least some Megabytes big to get decent results.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.