How do I check connection type (WiFi/LAN/WWAN) using HTML5/JavaScript?

Question

I wish to tailor a particular website to a low bandwidth version if the client is connected via WWAN (metered) connection or otherwise.

The connection type is important for the site to know if it should provide a rich experience or a bandwidth efficient experience. My desktop runs on a metered connection and in the future, more desktops will be connected via metered cellular networks (including Windows 8 tablet PCs), efficient web-apps should respect that a user might not require high detail assets on a pay-per-byte-connection.

How do I check if the client is connected via WiFi/LAN/WWAN using HTML5/JavaScript?

NOTE : I do not wish to explicitly check for browser headers (which is not really a solution for desktop browsers that can connect to the internet via multiple methods).

Verbenia

Why would anyone allow its browser to expose such data? – Cauthen

Updated question to state reason for exposing such data. – Verbenia

“in the future, more desktops will be connected via metered cellular networks” — maybe cellular network data connections won’t be metered in the future. Mine isn’t today. – Belch

Answer 1

See navigator.connection (prefixed). This API exposes information about the bandwidth of the client.

Guimar

It does say its experimental and not supported in IE or Safari :/ – Functionalism

Its on the bleeding edge, but this looks promising. – Verbenia

does not work on latest chrome and firefox browsers (oct '13) – Wakerly

is this applicable only to mobile browsers? – Wakerly

@Raul: I don’t think it’s applicable to any browsers any more. Work on the specification was abandoned (w3.org/TR/netinfo-api), and at least in Chrome 4 on my Mac, navigator.connection isn’t present. – Belch

@PaulD.Waite w3c.github.io/netinfo is the active version of the spec, and still actively maintained. At least in Chrome, the APIs appear to be restricted to mobile platforms only. You can find more info at the status dashboard (not specific to Chrome): chromestatus.com/features/6338383617982464 – Guimar

@RobW: gotcha, nice one. (And just for the record, I meant Chrome 40 on my Mac, not Chrome 4.) – Belch

Don't use navigator.connection. It doesn't work for Mac computers and phones which makes it virtually useless imo. – Lido

@mehulmpt According to the chromestatus link above, it's going to ship in 61. Here is also an intent to ship to desktop: groups.google.com/a/chromium.org/d/msgid/blink-dev/… – Guimar

This works for me on Chrome 76. But the fact that it doesn't work on iOS Safari makes it virtually useless if you're trying to save your customers some money on mobile data. Then again, customers might not be that interested in saving money if they're using iPhones anyway. – Trudge

Answer 2

You can't. The information on how a client is connected (i.e., which technologies it uses, if it is pay-per-byte or a flatrate) to a server is not public. You might be able to get a trace route (with all problems that are connected to tracing), if that helps you, but that information won't be accessible JavaScript.

What can do with JS is simple bandwith testing. Download a file of known size via XHR, and measure the time that needs.

The pay model of a connection is absolute private data. Neither will it be sent along to servers on the internet, nor is it available to a loaded website. If you need this information to offer the client a custom app, ask the user directly. He will tell you if he wants.

---

Yet, wait. Latest Chrome and Firefox can be set (user preference) to provide that data on the experimental navigator.connection object.

Also, for developing Metro apps, Windows offeres such information on the Windows.Networking.Connectivity API, see this tutorial.

Cauthen

If this is true, which I have no reason to believe it is not - given your reputation, then is this not a hole in the spec? Linux/Windows/OSX/Android/Windows Phone 7+/iOS all support connected type interrogation, for good reason ; it saves money. If this answer is correct then HTML5 is the only modern platform that does not support connection type interrogation. – Verbenia

HTML5 is not a platform, and what information the browser sends to the server has nothing to do with HTML. – Tinaret

+Bergi To follow up your second paragraph: Bandwidth testing via JavaScript to determine connection type doesn't really work for the required intent. Lots of WWAN connections are faster than broadband connections or poor WiFi connection points. Plus testing bandwidth just uses up more quota. If no-one can offer a solution (I would assume not), I'll mark this as the accepted answer tomorrow. – Verbenia

OK, I've asked google a bit more specific, and it comes out there actually is such an API. – Cauthen

2020: I guess not that private anymore navigator.connection – Reyna

Answer 3

Maybe you are approaching it in the wrong way. Have a look at the Gmail model. They have a rich client that the user can opt out of if the page is taking a long time to load. The standard client is much lighter and uses a more "traditional" web design.
Trying to automatically detect things that are not meant to be can take you down a very deep rabbit hole.

Functionalism

With respect, I understand your point, but I disagree. Mobile platforms check connection types and tailor their experience to the connection type. With the prevelance of WWAN dongles and ultrabooks with 3G connectivity, apps would be out of order to consume bandwidth as if it is infinite. The GMail model is kind of broken too, it first tries to consume the bandwidth then if its slow it offers something more optimized. My WWAN connection is 21Mbits. Not slow - just expensive if I go over my quota. – Verbenia

Ok, thats cool. So to accomodate you can allow the user to choose the lower bandwidth and stick with that then they dont incur the extra cost. Another method could be to make some assumptions based on the browser type, mobile, tablet, desktop etc. Normally they say its a no no test the user agent but you are not going after a specific feature in this case – Functionalism

As stated in the initial question, it is no longer possible to assume a particular connection type from the browser type header. My mobile phone is connected using unmetered wifi half the time, but my Windows 7 machine is always connected via 3G. In the near future, Windows 8 and future versions of Chrome will let users interrogate which Web Apps are hogging the metered bandwidth. It is not the job of a customer to constantly be thinking about their connection type. It is my opinion that it is the job of an application to be efficient on the user/customers behalf. – Verbenia

Answer 4

Old question, but in searching for my own purposes, I found this -- I have yet to try it and so therefore YMMV: https://github.com/ashanbh/detectClientSpeed.

The underlying notion of measuring time to download an asset to derive bandwidth information is subjective and not necessarily consistent, but short of native platform API for iOS/Android, this is not a bad option. A lighter alternative may be to measure ping times to something like google.com.

Ustkamenogorsk

ashanbh's own example doesn't work for me (ashanbh.github.io/detectClientSpeed/example1.html). Have you had any luck? – Lido

Hey man, why do you think pinging will give you any indication about network type? If you're implying cellular data will have lower response times than WiFi, that's absolutely incorrect. – Yarmouth