Comments (7)
For reference, current thresholds in the spec are:
The above round-trip and bandwidth values are based on real user measurement observations:
- slow-2g is the 66.6th percentile of 2G observations
- 2g is the 50th percentile of 2G observations
- 3g is the 50th percentile of 3G observations
Some questions that come to mind...
- based on current telemetry have the thresholds meaningfully changed for above percentiles?
- what is the rough global split between 2G / 3G / 4G usage in the telemetry?
- This can help inform which labels we should consider collapsing or adding.
from netinfo.
based on current telemetry have the thresholds meaningfully changed for above percentiles?
I do not think 3G RTT of ~300msec is fast enough to support high resolution images. Since the time we did this investigation, I think the page sizes have become larger which means we can't afford to have high resolution images on 300msec RTT network.
what is the rough global split between 2G / 3G / 4G usage in the telemetry?
Slow 2G: 1.5%
2G: 0.8%
3G: 19%
4G: 78%
from netinfo.
Do you think we should consider updating any of the current values in the spec?
If I'm interpreting your point correctly, sounds like current 270ms threshold is still ~reasonable? Should we consider collapsing "Slow 2G" and "2G" into a single bucket?
from netinfo.
I think there are 2 problems:
(i) The distinction between Slow2g and 2G is not very useful
(ii) There is a big jump from 2G to 3G (2.3% to 21.3%).
Ideally, we can have a situation where Slow2G covers bottom X% of slow connections, 2G covers next Y% , 3G covers next Z%, and the jumps between X, Y, Z are not too big. e.g., 5, 10, 15 to get a total coverage of 30%?
from netinfo.
Hmm, I see what you're after, but I think that's a very different signal from what we expose today?
That said, if you have the data handy, what would the above thresholds yield in terms of RTT and Downlink values?
from netinfo.
We'd be interested in revisiting the ECT thresholds from the Chrome UX Report angle. For example, we're seeing an average of ~90% of origins reporting 4G mobile experiences.
Adding desktop users to the mix, the percent of 4G experiences rises to ~95%:
Rather than grouping the vast majority into 4G, it would be useful to have more granularity to identify whether these experiences are on the fast or slow ends of the spectrum.
from netinfo.
Rather than grouping the vast majority into 4G, it would be useful to have more granularity to identify whether these experiences are on the fast or slow ends of the spectrum.
The primary use case and intent for ECT is as an indicator for when the site should (strongly) consider altering what+how it delivers to the user, which in turn is concentrated on very slow connections where the user is likely to fail to load the page or abandon the navigation. As a result, the wide upper bucket is by design and intentional — the explanation column in #68 (comment) captures this well.
That said, NetInfo does provide both downlink and RTT for those that want a high resolution view.
from netinfo.
Related Issues (20)
- IANA section with registrations HOT 2
- Somewhat mangled IDL for NetworkInfomation HOT 2
- Fix indent in EXAMPLE 1
- Support .toJSON() on NetworkInformation interface
- Remove [NoInterfaceObject] HOT 2
- Include a separate “metered network” property in addition to “save data” HOT 1
- Netinfo status
- Should we archive this? HOT 21
- Can we just do metered? HOT 3
- Should `effectiveConnectionType` be a fixed set of values? HOT 15
- Revise use cases
- Privacy review and standards track plan HOT 1
- Should ontypechange be added again?
- compatibilité d'affichage mobile HOT 1
- Update repo and spec to show this is no longer being actively incubated HOT 6
- [tomayac/netinfo 🍴] `isMetered` should be `metered` HOT 1
- [tomayac/netinfo 🍴] Remove typedef HOT 1
- [tomayac/netinfo 🍴] Need to document why `sustainedSpeed` can be `Infinity` HOT 1
- Client Hints should get Sec-CH- prefixes HOT 1
- Normative references to discontinued specs in Network Information API
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from netinfo.