Using JS to determine the network type and connection status of the implementation code

China's mobile network environment is complex, in order to give users a better access experience, developers want to understand the user's current networking, and then give users a meeting with the current network environment request results.

A method is given to obtain the current network state navigator.connection according to the specification of the working Draft November 2012 Protocol specification we can obtain bandwidth from the interface (bandwidth, m/ s) and metered values of two parameters; A listening method is also provided to monitor the change of the access environment at all times. In reality we found that many browsers did not return bandwidth values, and complied with the working Draft 2011 protocol Return to US type (type, wifi/2g/3g/4g).

We'll take a look at the support of the families.

uc	qq browser	baidu	chrome	opera Mini	maxthon
yes	yes	yes*	yes (New)	no	yes

Note that any browser in the iphone will not be able to get relevant information.

Through the instructions above, we find that we can learn more about the networking of a large number of users through this parameter, and provide them with a better experience.
Next, we will focus on the return of each browser.

Most browsers return an int type, with the exception of the QQ browser, which returns the type name, which corresponds to the following

	qq return value	type
unknown	unknown
ethernet	2	wifi	wifi
2g	cell_2g
3g	cell_3g
5	4g	cell_4g (this value is also present in China, hspa+) /td>
	none	none

The next is a larger exception, this is Firefox, he used the new version of the specification, so the return of the bandwidth; but it is strange that as long as WiFi or 3G he will return 20, if 2G is the return of 0.1953125; every time, no matter what the current network status is. This issue will continue to follow up.
In the demo, the browsers that do not support connection are returned directly to {type:0}, which makes it easy to solve problems that some browsers do not support, and it is also reasonable for browsers that do not support and surf the web to be "unknown".

Many engineers feel that the support is not good, or not to use first, but I think as long as the error can be dealt with, the risk can be controlled, why not give those who are innate excellent customers to provide a more friendly experience.

Today, the students said to let the back-end judge speed, this may be a bit difficult, but it is possible to get the user's approximate speed (the load time and file size are available at the front end) with each asynchronous request, and then be prepared to think more in this direction after providing some selective service.