Implementation code to determine network type and connection status through JS_javascript skills

China’s mobile network environment is complex. In order to provide users with a better access experience, developers hope to understand the user’s current networking method and then provide the user with a request result that matches the current network environment.

The W3C specification provides a method to obtain the current network status navigator.connection; according to the Working Draft 29 November 2012 protocol specification, we can obtain the bandwidth (bandwidth, M/s) and metered parameters from the interface. value; it also provides a monitoring method to monitor changes in the access environment at all times. In reality, we found that many browsers did not return the bandwidth value, and complied with the Working Draft 07 June 2011 protocol and returned us type (type, wifi/2g/3g/4g).

Let’s take a look at each company’s support

Android 2.3 Browser	UC	Dolphin	QQ浏览器	Baidu	Firefox	Chrome	Opera Mini	Maxthon
Yes	No*	Yes	Yes*	Yes	Yes(New)	No	No	Yes

The relevant information cannot be obtained from any browser on iPhone.

Through the above description, we found that we can still understand the Internet connection status of a large number of users through this parameter, and provide them with a better experience.
Next, we focus on the return status of each browser.

Most browsers will return an int type. A special case is QQ browser, which returns the type name. The corresponding relationship is as follows

返回值	QQ返回值	类型
0	unknown	UNKNOWN
1	ethernet	ETHERNET
2	wifi	WIFI
3	2g	CELL_2G
4	3g	CELL_3G
5	4g	CELL_4G（中国现在也会出现这个值，是hspa ）
?	none	NONE

The next is a bigger special case, this is firefox, it uses the new version of the specification, so it returns bandwidth; but what is very strange is that as long as it is wifi or 3G, it returns 20, and if it is 2G, it returns 0.1953125 ; It’s the same every time, no matter what the current network status is. This issue will continue to be followed up.

Provide you with a demo address: http://demo.jb51.net/js/2015/net.html
In the Demo, {type:0} is directly returned to browsers that do not support connection, which conveniently solves the problem that some browsers do not support it. It is also appropriate to treat browsers that do not support connection and can access the Internet as "unknown". Reasonable.

Many engineers feel that the support for this function is not good enough, and it is better not to use it yet; but I think as long as errors can be handled and risks can be controlled, why not provide a more friendly experience to those customers who are inherently good.

Today, my classmate talked about letting the backend judge the speed. This may be a bit difficult; but it is indeed possible to get the approximate speed of the user through each asynchronous request (the loading time and file size can actually be obtained by the frontend), and then select Provide certain services in a sex-oriented manner, and plan to think more in this direction in the future.