When I was doing the redesign of my site (actually when I was already finished), I realized that the big header image I was using consumes a lot of bandwidth when downloaded by the user. Subsequently, it added to the page loading time and made the site much heavier than the old version. I really did not want to start tweaking the image and maybe trying to create a 1px background that I would be able to repeat across the width of the site. Also: the size of the image would only be a problem for users with a slow Internet connection — broadband users would probably not even notice a speed difference to the old site. So I was thinking: Would there be a way of finding out the connection speed of the user and subsequently serve different content (e.g. in this case, maybe just a plain black background and no image at all) to users with e.g. a dial-up connection? I was thinking JavaScript. Maybe.
Step By Step
I did some digging on the net and some investigation and tried to come up with a concept that makes sense. The steps I was thinking about:
- On page load, a 10kB image gets requested “in the background” (hidden from the user by CSS)
- Via JavaScript, the time it takes to load that image gets recorded and the bandwidth gets calculated
- As soon as this process is done, the image gets removed again from the DOM
- Some sort of bandwidth cookie gets stored on the client, telling the site which content to serve on subsequent calls to the site
I came up with a prototype that demonstrates the bandwidth measuring using JavaScript. It does not take care of Steps 3 and 4 mentioned in the list above, but I think it conveys the idea behind it.
Some things to note about the JavaScript:
- Line 47: I am using onload as an attribute of the element itself, which is bad practice in general, cause behavior should entirely be controlled using JavaScript and Event Handlers should be added e.g. with YUI Event. To not waste execution time and maybe alter the measure of the bandwidth, I used it in this instance. Because of that, I also had to author this document in HTML 4.01 strict, to make sure it validates.
- Line 52: Also, I am using innerHTML to quickly insert the piece of code that constructs the image element. I could have created the image element using document.createElement, but innerHTML works just fine and occurred to me as just more convenient in this case.
Conclusion
Honestly, after I was finished with the prototype, I was not really sure if that whole thing makes sense at all. Cause what it does is it makes an additional request to the server which would make the page even slower to load for people already suffering from a slow connection speed. Also, thinking about the cookie thing, as people tend to be mobile these days, they might have a slow (WiFi) connection when requesting the site, but have a fast broadband connection at home. But with the cookie already written when they visited the site when they were mobile, they would get the low-bandwidth-experience at home as well – which defeats the purpose, kind of.
So especially after writing this blog post about it, I am not really sure if my idea makes sense. So I am asking you guys, what is your opinion on that?
This does make sense. Fact I am researching now for this. We will use it to redirect what bitrate to push to the client. If they have dial up, a audio only stream, if they have 500kbps or higher, then a 400kbps stream etc…
Each time they come back, you just do the check again, why deposit a cookie. If they are on dial up, they are use to slow things, if they are on broadband it will be fast.
AM