Detect user's connection speed

I want to detect the user's connection speed to offer an improved website experience. As an example, use 20 records per page pagination, but allow the detection script to change that to higher or lower (as well as other things).

How is the best way to do this, and can someone point me in the right direction?

Thanks.

I don't think there is any accurate way to accomplish this. But, changing the number of records per page will have little performance benefit unless each record has a lot of images displayed with it. One image "normal" sized image will typically be larger than all of the HTML code.

I'm talking about lots of images (image gallery). I certainly wouldn't just tone down a bit of HTML.

If someone is on a cheap Android phone with an average connection (2G or even 3G) then I would probably show 10 images at a time.

If someone was using wi-fi then I would show a lot more.

You'll probably have to use JavaScript for this. Have a function that loads some test data on the first page view, then calculate the approx speed. Set a session cookie with that value, and load the appropriate number of pictures. The bad thing about this approach is that it'll require JS, otherwise it'll only show a minimum number of pictures.

You can enhance the script by adding a server-side selection as well, where you allow the user to manually select the number of pictures to show. This value should be saved in a more permanent cookie, possibly also in a user profile (if you're using a login).

If someone is on a cheap Android phone with an average connection (2G or even 3G) then I would probably show 10 images at a time.

 

If someone was using wi-fi then I would show a lot more.

OK, if you are talking about supporting mobile devices then that aspect alone should be your criteria, IMHO. A mobile device has limited screen real-estate and you should limit the number of photos on that rather than their connection speed. In addition to limiting the number of records per page you can also implement different style sheets for mobile vs. desktop.

I want to detect the user's connection speed to offer an improved website experience. As an example, use 20 records per page pagination, but allow the detection script to change that to higher or lower (as well as other things).

 

How is the best way to do this, and can someone point me in the right direction?

 

Thanks.

Simple, just set it in the middle, have an option in their User control panel to change it to a setting.

Let's say 10 images is average.  Or use a php script to detect what phone they're on or whatever to change it dynamically, google it there's tons of browser detection scripts to detect what kind of phone they're on.

Or like I said, let them change it in the settings.

If you cannot get the test speed, my recommendation is using something to detect what browser they're on, that would = what phone, and you could go from there, not 100% plausible idea, but better then nothing right?

If someone is on a cheap Android phone with an average connection (2G or even 3G) then I would probably show 10 images at a time.

 

If someone was using wi-fi then I would show a lot more.

 

OK, if you are talking about supporting mobile devices then that aspect alone should be your criteria, IMHO. A mobile device has limited screen real-estate and you should limit the number of photos on that rather than their connection speed. In addition to limiting the number of records per page you can also implement different style sheets for mobile vs. desktop.

"Supporting mobile devices?" Do people still ask that? 60% of visits to the London 2012 Olympics website was on a mobile or tablet. People still make an effort to support IE8.

What if someone was using a laptop with a 3G dongle? Large screen and slow connection.

My question is about detecting connection speed, not satisfying a different screen size.

ChristianF has got this right.

I will use settings, but of course people may not bother to change these, so an automatic detection helps as well.

Anyone thinking this is unnecessary should think about HTML5 video. Unlike Flash, HTML5 video has no support for detecting connection speed.

60% of visits to the London 2012 Olympics website was on a mobile or tablet.

High profile websites mostly always serve content relevant to the device they is being accessed through. If I access the website on an iPad I will get a version that will display smaller images, less textual content and no flash. If I access the website on my smartphone there will be less javascript, much smaller images, smaller stylesheets, no flash, etc. If I access the device on a PC then I get the full blown version.

This is how websites are designed to cater for all devices, even including Smart TVs. They are not designed to change based from connection speed (mobile versions are the exception).

My question is about detecting connection speed, not satisfying a different screen size.

Designing mobile friendly sites is not just about the screen resolution. They are designed with the thought that they are being accessed through a mobile network and not a WIFI connection and are scaled down so that the content is served quickly. If a mobile user has a WIFI connection then mobile versions usually have a link that can take them to the full blown website.

I would certainly not go down the route of building a website that serves different content based from an ajax call to determine the users connection speed. There are just too many holes with a solution like this.

There are methods I have read about for mobile devices running Android to get the connection speed but certainly not used for a full blown desktop website.

There are tools to use to detect what devices are accessing your website and serve the appropriate version to them. Look at WURFL http://wurfl.sourceforge.net/

Psycho was correct in his post

neil.johnson,

Thanks, because I know you're trying to help, but I'm not talking about the correct way to build a website.

Everything you say is true, except that I want to detect connection speed IN ADDITION to everything else. Just remember this is a PHP forum, and whilst my solution turned out to require JS and PHP, what you and Psycho are talking about is mainly front-end development, so you are completely off topic. (Of course device detection through the user agent isn't front-end development).

Psycho, like you, is wrong in thinking the question is anything other than what it was.

Psycho is also stuck in the past saying, "OK, if you are talking about supporting mobile devices...". A developer should equally support all recent browsers and recent devices.

My question was:

I want to detect the user's connection speed to offer an improved website experience. As an example, use 20 records per page pagination, but allow the detection script to change that to higher or lower (as well as other things).

ChristianF got it right, and that was where this post should have ended.

I have ended up with this: http://www.page-test.co.uk/c.php - which will return an approximate connection speed. Of course it isn't perfect. Of course I should run it a few times and get an average. Of course there are many, many negative things that can be said about that script, but it gives a very rough idea, and allows a device to be put into one of three categories for connection speed.

I plan to use the script that I have now created (obviously there is more work to do than just the script in the link I posted) to offer an improved website experience when displaying HTML5 video and an image gallery. If JS is off, if the browser doesn't support my Ajax implementation (some mobiles don't), if session storage isn't available (I chose this over cookies) - basically if anything is wrong then the script won't run and default settings will be used (which the user can always override if they want to). If the script does run, and it detects a connection speed, then that data can be used to improve the website experience.

HTML 5 video can't itself detect bandwidth - so this is essential.

Psycho is also stuck in the past saying, "OK, if you are talking about supporting mobile devices...". A developer should equally support all recent browsers and recent devices.

You are totally off base here and completely naive. I work for a multinational company that serves markets worldwide. We offer software and other technology solutions in multiple market segments. In addition to Desktop and browser-based solutions (ironically none of which are PHP) we also have mobile apps. But, you know what, our web sites and browser apps are not "device aware" to support mobile devices. Why? Because it doesn't make good business sense to do so. The types of browser-applications we host and current usage by our customers shows that mobile devices make up a miniscule percentage of our traffic.

To support ALL browser and ALL devices is no trivial task. Just for our mobile apps we have to support a minimum of four different style sheets: android phone, android tablet, iPhone and iPad (and soon we'll be adding support for Win Phone and Tablets). But, even those don't work great for the Galaxy Note (a 7" tablet). The phone style sheet is not big enough and the Tablet style sheet is too big. Add to that the many different idiosyncrasies with mobile operating systems, browsers (especially JS support), connection speeds, number of cores, etc. etc. In fact, I had a meeting last week with a vendor regarding testing of our mobile apps. They had labs with over 1,400 devices!

I never stated that one should not support mobile devices, but the extent to which you will support them is wholly dependent upon your user base and how they will use the application. The extent that you will support them is a business decision that needs to be made in order to know how much resources to invest in those solution. To simply state that you will support all of them is foolish.

Psycho,

I believe your methods are completely wrong.

(1) Maybe the reason that mobile devices makes up a "miniscule percentage of our traffic" is because your sites don't support them. If 60% of visits to the London 2012 Olympics website were on a mobile or tablet, then that is saying something. If the 2012 website didn't support a mobile device then I can tell you for certain that they also would have very few visitors on a mobile device (and less visits overall no doubt as well).

Of course every site should cater for a different amount of support, and the 2012 website would be a perfect example of one that should be created to support all and every (recent) device, but I can't think of one site that shouldn't support at least an iPhone and iPad.

(2) You don't need a different stylesheet for each OS. Why would you need that? Why does Android need a different stylesheet to iOS? Use a responsive layout, and that is all you need in terms of CSS. it makes good business sense to create one stylesheet than to create many different ones.

(3) You also say "soon we'll be adding support for Win Phone and Tablets". You don't need to "add support for tablets" if you code it right. That's like saying "soon we'll be adding support for people with monitors wider than 1200px".

If a site works on an iPhone and is responsive, then it will automatically work on an iPad (both screen resolutions). Of course you should test it and decide if you are happy with the overall look on an iPad, but it won't need another stylesheet like you suggest.

It appears that you have a problem creating a site which supports all these devices (listing all your problems with them). Don't let that make you not want to support them.

(4) Testing doesn't have to be 1,400 devices. You can test on these OS:

(some OS listed below are due to be released soon of course)

- iPad (iOS 5 and iOS 6)

- iPhone (iOS 5 and iOS 6)

- Blackberry 5 and 7

- Blackberry Tablet OS 2.1

- Blackberry 10

- Windows Phone 7.5 (and 8 when available)

- Android ICS 4 / 4.1

- Android 3.x

- Andorid 2.3

- Nokia browser

// these are browsers available on various OS that should be tested

- Opera Mini

- Opera Mobile

- UC Browser

- Google Chrome

- Firefox Mobile

There are various others, but overall they make up about 1% of all web traffic.

The list above isn't that much. if you own the devices (I'm sure your company could afford them) then testing is easy.

You're right. Myself and all the professionals I work with don't have a clue.

You're right. Myself and all the professionals I work with don't have a clue.

This is a poor attitude to have in a discussion forum. People won't always agree, and that is what makes debate in these forums so interesting and often educational.

You decision to respond to my advice in this way is detrimental to any forum community. If you don't agree then say so, but responding like this helps nobody.

@ OP : who is going to want to help you when you are constantly telling everyone they are wrong?

anyhow sounds like you need to use a system outfitted for using mobile phones. should checkout jquery mobile most of the browsers and OS's are compatible with there  stuff.

http://jquerymobile.com/

@ OP : who is going to want to help you when you are constantly telling everyone they are wrong?

 

 

anyhow sounds like you need to use a system outfitted for using mobile phones. should checkout jquery mobile most of the browsers and OS's are compatible with there  stuff.

 

 

http://jquerymobile.com/

jQuery mobile is very good, thanks. I personally prefer a solution that supports all devices, including desktops, in the same code base, but jQuery Mob does provide excellent support for older mobile devices.

In fact, this link: http://jquerymobile.com/gbs/ is a very good list to use to check which devices you should support (e.g. if not developing in jQuery Mobile) - even more detailed than my list a few posts above.

Many experienced and strong developers disagree with you. It's nice that you have your opinions, but the ones that contradict them are based on real experience.

You've got your solution - use an AJAX call to try and determine bandwidth. You also have many industry professionals telling you that it's not the right way to go. If you think these conclusions are based on anything other than experience, you're incorrect. Disagreeing in theory isn't good discussion.

Make this one client-side library to rule them all, and we'll congratulate you. Considering even jQuery has a different code base for mobile devices, all I can say is best of luck and Godspeed.

Many experienced and strong developers disagree with you. It's nice that you have your opinions, but the ones that contradict them are based on real experience.

 

You've got your solution - use an AJAX call to try and determine bandwidth. You also have many industry professionals telling you that it's not the right way to go. If you think these conclusions are based on anything other than experience, you're incorrect. Disagreeing in theory isn't good discussion.

Only one person has commented on here about me using an Ajax call to determine bandwidth. That was ChristianF, who gave me the idea, and he seems to know what he is talking about. If nobody says otherwise then what else can I do? Nobody has told me not to do it, so what do you mean?

Make this one client-side library to rule them all, and we'll congratulate you. Considering even jQuery has a different code base for mobile devices, all I can say is best of luck and Godspeed.

I am currently working on something actually. It's a combination of the different scripts that are out there. It's not perfect, but I'm happy so far. I'm regularly getting feedback and advice from people in the know, so it's looking positive so far.

I think we all can agree that we don't really know what the best solution for this particular project is, seeing as we don't know any of the details. All we can do is to make (educated) guesses based upon our own experience, and our assumptions on how the system and its requirements are. Since the John Smith seems to have given this a great deal of thought, and is using it in conjunction with other systems (and only to improve the experience), I must admit that I'm looking forward to seeing how the total solution works.

Other than that I'll reserve my judgment about it being The Right Way, or not, until after I've had a chance to investigate the finished product.

There's no single way to properly determine bandwidth over all platforms.

Even if possible, it'll take at the very least several seconds to get a good idea of the bandwidth - on each 'new' visit? Seems annoying to me.

The AJAX call is flawed. What happens if one of the nodes takes a random extra half-second to respond? What happens when any sort of network hiccup delays the connection?

Most browsers do a good job of letting you know what platform they're using to connect, and identify themselves (this can be spoofed, yes, but we're talking about average users here). Forcing a certain layout upon them based on some arbitrary test that may or may not actually provide accurate results is just silly. Provide them with the best template you can based on how they've IDENTIFIED themselves, and allow them to change this (perhaps with a cookie to remember) somewhere in your footer or navigation.

Only one person has commented on here about me using an Ajax call to determine bandwidth. That was ChristianF, who gave me the idea, and he seems to know what he is talking about. If nobody says otherwise then what else can I do? Nobody has told me not to do it, so what do you mean?

If you can't find where others have suggested against your path of choice, then I suppose you can't be helped.

There's no single way to properly determine bandwidth over all platforms.

 

Even if possible, it'll take at the very least several seconds to get a good idea of the bandwidth - on each 'new' visit? Seems annoying to me.

 

The AJAX call is flawed. What happens if one of the nodes takes a random extra half-second to respond? What happens when any sort of network hiccup delays the connection?

All above was mentioned in my posts.

Most browsers do a good job of letting you know what platform they're using to connect, and identify themselves (this can be spoofed, yes, but we're talking about average users here).

Yes, I do that, as mentioned in my posts. Have you ready them?

Forcing a certain layout upon them based on some arbitrary test that may or may not actually provide accurate results is just silly.

I don't do that, as mentioned in my posts. Have you read them?

Quote from: johnsmith153 on Today at 01:41:07 am

Only one person has commented on here about me using an Ajax call to determine bandwidth. That was ChristianF, who gave me the idea, and he seems to know what he is talking about. If nobody says otherwise then what else can I do? Nobody has told me not to do it, so what do you mean?

 

If you can't find where others have suggested against your path of choice, then I suppose you can't be helped.

No, I can't find it. I have posted this question on another forum as well, and more people have said it is a good idea. More than who have said it is bad.

As you obviously haven't read enough of the posts on here to understand what is going on, I will repeat it:

I am doing this IN ADDITION to everything else (device detection etc.) ChristianF is the only one who understands this:

...and is using it in conjunction with other systems (and only to improve the experience),

The site will run perfectly without this script. The site will run perfectly without JavaScript. The detection script will be used to provide an improved HTML5 video and image gallery experience ONLY.

What a waste of bandwidth. If you've got users with limited and/or slow connections, I'm sure they'd be thrilled that you're trying to perform miniature stress tests on their connection. Why not save that bandwidth and waiting time for actually loading content they want? Just lazy load the images. Problem solved.

Edit

Not to mention as someone else has said, the results you'd get wouldn't be realistic at all; intermittent connections, going under a bridge, network lags, etc. I dare say devices are also smart enough to realise when something is trying to hammer the connection, and so will throttle it.

This seems like a fairly close way to calculate it. When I did this the console logged about 15MB/s When I went to speedtest.net and did a speed test, it was pretty close to the same thing.

The important parts are between the <script> tags (top and bottom)

<!DOCTYPE HTML>
<html>
<head>
	<script>
		<?php
		echo "var filesize = ".filesize(__FILE__).";\r\n";
		?>
		var d1 = new Date().getTime();
	</script>
</head>
<body>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
	<p>a;dfashdflajhdlkfjhsldkfj</p>
</body>
	<script>
		var d2 = new Date().getTime();
		var millitime = d2 - d1;

		var diffTimeSeconds = millitime / 1000;
		var bits = (filesize * ;
		var kbits = bits / 1024;
		var connectionSpeed = kbits / (diffTimeSeconds);
		console.log(connectionSpeed / 1024);
	</script>
</html>

What a waste of bandwidth. If you've got users with limited and/or slow connections, I'm sure they'd be thrilled that you're trying to perform miniature stress tests on their connection. Why not save that bandwidth and waiting time for actually loading content they want? Just lazy load the images. Problem solved.

 

Edit

 

Not to mention as someone else has said, the results you'd get wouldn't be realistic at all; intermittent connections, going under a bridge, network lags, etc. I dare say devices are also smart enough to realise when something is trying to hammer the connection, and so will throttle it.

Thanks for actually reading enough of the topic to understand it.

Fair point about lazy loading images. There's still no way of telling the script 'how many' images to lazy load, and when to stop, though, but of course there's pros and cons with any method. I am thinking this might be better for image quantity though.

Of course this will help file (image/video) quantity, but not file quality/size decision making.

What about HTML5 video. What do you suggest for this?

I'm not too sure what you got in mind, but if it's something like a ping, then it's completely useless to determine their bandwidth. There are so many different factors that might affect the result. The most important one is that how quickly they respond has absolutely nothing to do with their bandwidth and how fast they are able to load your site even if it's very heavy. Even if ping was enough to determine bandwidth, you would need to keep statistics of the user to determine their bandwidth. I don't think it's a too good idea to keep changing between how the user views the site all the time. It's also very hard to keep track of unless they are members, and if they are members, a better solution is just to allow them to change it themselves instead of you forcing it on them based on a ping.

I'm not too sure what you got in mind, but if it's something like a ping, then it's completely useless to determine their bandwidth. There are so many different factors that might affect the result. The most important one is that how quickly they respond has absolutely nothing to do with their bandwidth and how fast they are able to load your site even if it's very heavy. Even if ping was enough to determine bandwidth, you would need to keep statistics of the user to determine their bandwidth. I don't think it's a too good idea to keep changing between how the user views the site all the time. It's also very hard to keep track of unless they are members, and if they are members, a better solution is just to allow them to change it themselves instead of you forcing it on them based on a ping.

All this has been discussed so far. Unfortunately you need to read the whole topic to understand what is going on.

I'm still surprised nobody's moved this to another of the forums on this site.